compose: docker-compose run --rm does not rm links
Looks like --rm does not propagate to dependencies:
docker-compose run mycontainer --rm # start container with links
docker-compose ps # linked containers are still running
Hoping this is not desirable functionality.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 12
- Comments: 16
I was expecting
docker-compose run --rm
to also clean up linked containers if it created them. This would be really helpful when running integration tests in build environments.What I would like to do:
What I’m currently stuck doing:
Could you please reopen this?
As mentioned in this thread,
docker-compose rm -f --all
anddocker-compose down
already allow cleaning up a project’s containers / resources. We won’t overloadrun
with more options at that point.I know this thread is probably DOA, but any chance of reviving the discussion? I find it hard to comprehend that in the same post where it’s stated
it’s also stated
So, why are we fine including a convenience in only one half of the equation? If this is not the desired use, then shouldn’t we remove the convenience at the start, rather than refuse to include it at the end?
I feel we should either complete the circle or not allow people to fall into this trap and remove the convenience of the implicit “up”
+1 for removing linked containers somehow using run command.
Dunno. Running builds, e.g. using
docker-compose run --rm ....
is a great use case. I use it for Java and Go and any lang that needs to compile a deployment artifact, then use my Dockerfile to build my final image using that artifact.If my build has a dependency, e.g. testing needs a database or three, then the compose file makes a great way to spin it up automatically.
But, when compose removes my one-time run via
run --rm
, it leaves the other services up.At the very least, would be good if I could say,
run --rm-all
or similar, so it would know to start and stop all.Just adding my +1. If a “run” command is responsible for creating linked containers “for convenience” then it should similarly clean up after itself “for convenience”.
Note that, as others have said, it should only take down containers that were spun up to facilitate the command. If the containers were already up then they should remain so.
Yes, that is my use case. It is quite convenient for running automated functional tests (i.e.: jmeter) as part of a continuous integration pipeline.
You need to support docker-compose --rm up --build
😃
run
is used for a lot of different things, but its primary designed use case is running a one-off command against a long-running dev environment. The fact that it automatically starts dependencies was intended as a convenience so you don’t have to rundocker-compose up -d
beforehand.@breerly, @theypsilon: it sounds like your use case is more like spinning up a multi-container environment purely for the purpose of running a single container which depends on that environment, capturing the output of that container, and then cleaning up the entire environment. Is that right?
If so, it’s not really what
run
is for. You can certainly do it, it’s just a little more work on your side to run the cleanup after the command. Off the top of my head, this should do it (not tested):I’m wary of adding even more behaviour to
run
, even if optional. It’s already quite complicated.Also would like
--rm
to remove linked containers.Is there any plan for docker-compose run mycontainer --down then?