docker-compose run <container> --rm does not rm links
HelloGrayson opened this issue · comments
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.
It is by design. Compose 1.6 (RC2 is out now) includes a docker-compose down for stopping and removing the other containers.
@dnephin also, that doesn't really address cleanup, if a docker-compose run <container> command failed...
Is there any plan for docker-compose run mycontainer --down then?
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 run docker-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):
#!/bin/bash
# Usage: run.sh SERVICE [CMD...]
docker-compose run --rm "$@"
exit_code=$?
docker-compose down
exit $exit_codeI'm wary of adding even more behaviour to run, even if optional. It's already quite complicated.
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.
IMHO, This ticket can be closed.
I've confirmed appears docker-compose rm --all -f resolved this issue.
But it does not resolve left over networking from #2279
IMHO, This ticket can be closed
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.
As mentioned in this thread, docker-compose rm -f --all and docker-compose down already allow cleaning up a project's containers / resources. We won't overload run with more options at that point.
You need to support docker-compose --rm up --build
:)
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:
#!/bin/bash -eu
# other commands here
docker-compose run --rm dotnet dotnet testWhat I'm currently stuck doing:
#!/bin/bash -eu
# other commands here
set +e
docker-compose run --rm dotnet dotnet test
exitcode=$?
if [ $exitcode -ne 0 ]; then
docker-compose down
exit $exitcode
fi
set -eCould you please reopen this?
Also would like --rm to remove linked containers.
+1 for removing linked containers somehow using run command.
In my opinion, it makes --rm option useless, unless your run starts only one container. In my case using
docker-compose down was best option as it removes all created containers and the network.
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
I'm wary of adding even more behavior to run, even if optional. It's already quite complicated.
it's also stated
The fact that it automatically starts dependencies was intended as a convenience so you don't have to run docker-compose up -d beforehand.
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"
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.