Compose: docker-compose run <container> --rm does not rm links

[unhashable]

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.

[dnephin]

It is by design. Compose 1.6 (RC2 is out now) includes a docker-compose down for stopping and removing the other containers.

[unhashable]

@dnephin is that shorthand for docker-compose kill && docker-compose rm -f?

[unhashable]

@dnephin also, that doesn't really address cleanup, if a docker-compose run <container> command failed...

[theypsilon]

Is there any plan for docker-compose run mycontainer --down then?

[aanand]

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_code

I'm wary of adding even more behaviour to run, even if optional. It's already quite complicated.

[theypsilon]

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.

[ghost]

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 https://github.com/docker/compose/issues/2279

[deitch]

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.

[shin-]

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.

[billnbell]

You need to support docker-compose --rm up --build

:)

[ctaggart]

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 test

What 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 -e

Could you please reopen this?

[Brodan]

Also would like --rm to remove linked containers.

[Drew-Goddyn]

+1 for removing linked containers somehow using run command.

[barell]

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.