Added "docker exec" command for a service or all services.

[osteenbergen]

Example:

$ docker-compose execute busybox echo "Hello World!"

Supports --detach for background running
Supports running command on all containers with:

$ docker-compose execute all echo "Hello World!"
----- busy_busybox_1-----

Hello World!

----- busy_busybox2_1 -----

Hello World!

----- busy_busybox2_2 -----

Hello World!

[jfinkhaeuser]

That sounds awesome, +1 for merging it!

[Vrakfall]

+1

[aanand]

Thanks for contributing!

1. The command should be called exec, not execute, to keep consistency with docker exec.
2. all is a cool feature, but it should be a flag (i.e. --all), not a positional argument. Using --all alongside any service names should be an error.
3. exec should be interactive - we should use dockerpty to attach to the process. This might require changes to dockerpty or docker-py.

[aanand]

Oh, and:

• The -i and -t flags should be supported, just as with docker exec.
• docker-compose exec -i --all CMD or docker-compose exec web db CMD should be an error - you can't run a command interactively against multiple services.

[osteenbergen]

Aanan, thanks for your comments and I will integrate them as soon as possible

1. I named it execute as exec is a python build in command, will change it
2. --all was my first version although it became difficult to distinguish between:
   docker-compose exec apache2 ps aux and docker-compose exec apache2. But I have just thought of a simple solution, so no problem there
3. Interactive is a bit wierd as discussed in: Support docker exec command #593 (comment) Although I can limit it to a service with one container. Need to look into dockerpty on how to support the terminals. -i & -t are not a problem as they exist in the docker-py execute command

[jfinkhaeuser]

Agree that interactive is a little weird.

I understand that docker images with SSH are not really the way to go, but if you really want interactivity on multiple machines, something like SSH + clusterssh (or similar projects) are probably the way to go.

[osteenbergen]

Point 1 & 2 are integrated.

It seems that the Jenkins build bot has an error.

 docker build --rm --force-rm -t compose:docker-compose:3951ce4 .
time="2015-03-27T16:40:06-04:00" level=fatal msg="Invalid repository name (compose:docker-compose), only [a-z0-9-_.] are allowed"

About the commit itself:

Due to the way docopt works my only way to have --all was to write the usage line as
Usage: exec [options] [ SERVICE CMD... | CMD... ]

Other combinations (Usage: exec [options] [SERVICE] CMD...) could not handle single commands on all services.

$ docker-compose exec --all ps

[aanand]

I think that if there are multiple containers for a service running, Compose should either refuse to run exec or pick an arbitrary container.

Thinking about it, execing on multiple services (and, by extension, exec --all) is not an MVP feature. Since it complicates things like command parsing, I think it'd be better to just remove it.

[osteenbergen]

I do not agree that compose exec should always run on a single container, unless you were talking about the interactive option.

The idea is to have a service (or system with --all) in a predictable state, executing a command on a single worker could result in different behaviour. Over time this will lead to an unstable system.

The use-case of exec is to inspect or to fix a small problem in a live environment. If for example the next heartbleed happens and you want to update all certificates with a gracefull restart you can do: compose exec apache apachectl -k graceful. However maybe the compose consist of apache image for serving content and a service using apache image for loadbalanding. Then the same command can be execute on both services.

I agree that there aren't many use cases, but we can't predict the usage of compose. Maybe some user like to have an arbitrary container, which can be solved by a --pick-random option. However I understand that we should not complicate stuff by jamming a lot of features into compose.

For parsing the output we could add a output folder option. This will create a separate file for every container running in the service/system.

[aanand]

I can believe there are a few good use cases for running an exec on all containers for a service, although doing an upgrade is a bad one - you should be updating your image and restarting your containers for that. Running some kind of diagnostic command is a good one.

But Compose isn't (yet) a tool for production environments, and so there isn't a strong need for that feature now. What would be useful, right now, is a command for inspecting a running container - an analogue to docker exec -it that doesn't require you to type a full service name.

[osteenbergen]

Will work on that (need to add support for exec in dockerpty). As soon as that is finished and pulled I will update this pull.

[mattes]

+1

[mcortinas]

+1

[antono]

+1

[aanand]

Closing as #2023 is the direction we're going in - thanks for the PR!