compose: docker-compose run --rm does not remove volumes
Running one-off commands with docker-compose does not delete volumes used by the container. This is different than docker run --rm
which does remove volumes after the container is deleted.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 7
- Comments: 17
Commits related to this issue
- Remove anonymous volumes when using run --rm. Named volumes will not be removed. This is consistent with the behavior of docker run --rm. Fixes #2419, #3611 — committed to nkovacs/compose by nkovacs 8 years ago
- Remove anonymous volumes when using run --rm. Named volumes will not be removed. This is consistent with the behavior of docker run --rm. Fixes #2419, #3611 Signed-off-by: Nikola Kovacs <nikola.kov... — committed to nkovacs/compose by nkovacs 8 years ago
- Remove anonymous volumes when using run --rm. Named volumes will not be removed. This is consistent with the behavior of docker run --rm. Fixes #2419, #3611 Signed-off-by: Nikola Kovacs <nikola.kov... — committed to nkovacs/compose by nkovacs 8 years ago
This is a fundamental docker behaviour - if the image has volumes in it, they will created whenever you run a container from that image.
It’s common to run one off tasks from an image that has volumes you may never use for that task.
The docker-compose run --rm behaviour should mirror the docker run --rm behaviour, which does correctly remove volumes.
You can work around this issue in Docker Compose 1.7 as follows:
docker-compose run xxx
docker-compose down -v
The key here is to not use the
--rm
flag on the run command. Because Docker Compose 1.7 removes containers started with the run command, it cleans up everything correctly including all volumes (as long as you use-v
)@schmunk42
docker-compose down -v
always removes named local volumes (1.6+), the current issue relates to volumes defined in the image of the service you are running that are automatically created not declared as explicit volumes in yourdocker-compose.yml
.For example given the following
docker-compose.yml
file:If we use
docker-compose run --rm
:Notice that the volume
tmp_mysql_run
is created and destroyed correctly, but we get an orphaned volume which is the/var/lib/mysql
volume in the mysql image.If we use
docker-compose run
instead:Everything is cleaned up correctly…
docker-compose down -v
would bring down the service stack and delete named volumes. I want neither to happen.@dnephin Our use-case is a rather simple web-app. We usually have
web
(nginx),php
andworker
(same image asphp
). We’re sharing static-files (assets) betweenweb
andphp
, but in other scenarios we also need to share files betweenphp
andworker
.The volume is defined in
docker-compose.yml
- sure there could be optimizations how much files are shared, but it still looks like a general problem to me.docker exec
could be a workaround, but I’d like to stay withdocker-compose
and I would rather not rely on the fact that my container is namedproject_php_1
because it may be namedproject_php_2
in some cases.I also noticed that we ran a cleanup script before, I had to reactivate/fix that, but having an option to remove volumes after
docker-compose run
would still be great.I need to look into named volumes a bit more I think, basically all apps we run, are running on a swarm, so I need to configure that properly.