I use 'build’ to indicate the path of the Dockerfile, ‘image’ to assign a custom name to the image I use, ‘container_name’ to assign a name to the container associated with my image downloaded from the internet with the Dockerfile. This practice helps me standardize my application’s installation and update code (see code below).
Installation:
docker ps -a
docker stop container-php-eb
docker rm container-php-eb
docker images
docker rmi image-php-eb:v.1.0
docker ps -a
docker images
docker volume ls
docker-compose up --build
Update:
docker-compose up --force-recreate
When smoke comes out of the computer:
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
docker volume rm $(docker volume ls -q)
docker system prune -y
docker system prune -a -y
I would not use Docker Compose to name the image as if it were an image pulled from a repository. You can, it is your choice, but I don’t think it helps much. You can just let Docker Compose to generate the image name which contains the name of the project and the service it was built for. It is the same with the container name. You set the name to “container-php-eb” Using “container” in the name seems redundant. Of course it is a container. If it is the project name for some reason that the autogenerated name would be similar. I only name the containers manually when I know I need to set its name in an other application’s configuration where I can’t dinamically detect the name.
I don’t see why you want to stop and remove containers and volumes using docker without docker compose. Docker compose could stop your services referring to the service name without knowing the ful name of the containr. You could also remove all the containers and networks using only one command:
docker-compose down --volumes
I also don’t understand why you would stop your containers then remove them (you could do it with one command, but I guess this is not the point), then prune the whole system which willremove everything, including containers.
So honestly I think I don’t understand the question. The commands that you quoted indeed working commands, but I can’t see how those help you or how your compose file helps you to use those commands.
Using docker stop $(...) was what I used some years ago but I don’t actually need it anymore when I want to delete everything. When I want to delete containers conditionally, then it can help.
Yes, using the name ‘container’ in the container is redundant but I don’t mind, it helps me remember what I’m doing when I use ‘docker rm’. In my opinion writing “image: image-php-eb: v.1.0” is useful. If I let Docker name the image how do I remove the image after creating it? I find it inconvenient to let Docker name the image, search for the name Docker gave the image, and then delete the image. Knowing the name of the image is simpler. If it is correct and it is permissible to use “image: image-php-eb: v.1.0” I prefer to leave it. Deleting images in the development stage is useful because I don’t risk using wrong images. I opened the post because I read on another forum that my practice is wrong and prohibited.
I didn’t know about the ‘docker-compose down --volumes’ command.
I don’t understand this sentence, can you write in simpler English?
Because when I create an .yml file it doesn’t work on the first try and I make thousands of changes. To avoid reusing something old, I delete everything I created in the previous step, including images.
I wanted to know if my approach is allowed and you answered me. I would like to avoid using old images and containers during the development phase of the project.
No, I didn’t know these commands. ‘docker container prune’ does not delete my active containers. ‘docker stop $ (docker ps -a -q)’ and ‘docker rm $ (docker ps -a -q)’ on my OS are still indispensable.
I have noticed that I cannot add the “-y” tag on these commands:
docker system prune -y
docker system prune -a -y
How can I correct the above commands without pressing ‘yes’ on the keyboard after typing the following commands?
Easily Since the name of the image is printed out when Docker compose creates it and the naming convention is well-known, so it will be <projectname>_<servicename>. I think it is safe to say, that when you find an underscore (_) character in the name of an image without a slash (/) in the name, that is created by Docker compose unless you decided to create an image with a name like that manually. So you can even search for those images. When I set a name manually either in docker compose or using the docker build, I always start the name with localhost/ so I know it is not something that I can push or update by pulling it from Docker Hub. This is just an idea, not a rule of course.
Everything depends on the usecase and I think as you try to learn more you will realize your special solutions are not as good as you thought. It sometimes happens to me. But I would not say that anything is prohibited. It is just not practical usually.
I meant that you don’t need to specify the name of a container in the compose file and run
docker stop mycontainer
because you can just let Docker Compose to name your container as “projectname_servicename_1” and run
docker-compose stop servicename
or stop every container with
docker-compose stop
without specifying the service name. I hope I could clarify it.
It should work if you use the right commands. If you build an image with Docker Compose, the first time you run the services it creates the image. Next time it doesn’t, but it also notifies you about that. This is because when you change your Dockerfile and change it during development, you can delete and recreate your containers without being afraid of using an incomplete Dockerfile. If you want to build the image anyway, you can run
docker-compose up -d --build
which you actually do. I work a lot with containers, but I almost never remove containers or images without docker compose when I created them with docker compose. Sometimes I do, when I don’t want to go the the fodler again and I just want to get more space. Docker Compose can have some bugs, but it is meant to be make your life easier and not harer. If you find a bug, you can report it.
May I suggest to always try --help with every command? That way you will not miss any possible subcommand. Just two examples but you can do it with any command not just Docker or Docker compose:
Since the name of the image is printed out when Docker compose creates it and the naming convention is well-known, so it will be