Compose: Add support for non-service container

[kitingChris]

Unfortunatelly the discussion in https://github.com/docker/compose/issues/1896 was closed. And since @shin- wrote a long post https://github.com/docker/compose/issues/1896#issuecomment-322285976 about the service philosophy I made some thoughts on that.

I would agreee with your point. Calling it service would then not be the correct term. But as the discussion and the recurring demands of such an feature request show there is a real need to define "command containers" as wenn in the docker-compose service.

Having containers that run a single command is not an unfamiliar concept to docker. So why does docker-compose do not help with such containers?

Defining command containers as services is currently still the defacto standard to have them defined somewhere.

So there is a really broad need for the feature defining command containers. Therefore I would ask for a new section in docker-compose files besides "services".

Could be called "commands".

Docker container could be defined exactly like services there. But they are not started with docker-compose up but only by docker-compose run.

Optional command containers are runned with --rm by default (unlike services)

[chris-crone]

Hi @kitingChris,

The current scope for the Compose format is to define a list of services and how they interact. This means that one can write a Compose file, deploy it locally with docker-compose to develop and test before deploying it to an orchestrated environment (Swarm or Kubernetes) with docker stack deploy with little or no changes. Because of this we need to be mindful of what we add to the format and how it translates to orchestrated environments.

At the moment there is no notion of running a container for a single task on Swarm but there is work on Swarmkit to add tasks which would do this, see: https://github.com/docker/swarmkit/issues/2852

We will need to investigate what UI we provide for this and if it makes sense to add something to the Compose format or not.

[kitingChris]

@chris-crone thanks for answering :)
Well I actually need this feature not during deploy with docker-swarm or else in prod environment but in development.

For example: An php-web application requires many One-off Tasks such as composer for installing dependencies, phpunit for running the unit tests or phpstan for the QA tasks. Also php-cli commands running tasks or one-off jobs during development for testing purposes.

In my current main project I am working with we have the following containers as task containers:

• yarn:
• php-console
• phpunit
• phpstan
• composer

and the following as true services:

• mysql:
• elastic:
• nginx:
• php-fpm:
• redis:

So there is also in docker-compose the high demand for this feature.

Best way in my opinion to solve this would be to define a sibling definition to services calles tasks where you can define all non-service container in exact the same way you define the service containers but during up docker-compose just ignores them.
During build both should be considered ...

This may be the easiest solution to solve this issue AND keep the service-philosophy.

[kitingChris]

Is there any chance we can get this soon? Because this issue drives me crazy.

When you have a team with mixed OS users and you use overrides to cope with volume issues AND then have to split docker-compose files because you don't want to up non-service container it really gets fuzzy!

This feature is severely needed! There were several claims and discussions for it in the past so PLEASE!!!

[kitingChris]

Now I have the same issue for a dotnet project. Need to execute a non-service container for database migrations. Still no suitable way to work this out with docker-compose. :(

[enghelewa]

I think it would be great if we can just tag a service to be on-demand:true so that docker-compose will not start it up by the up command.

[AstraLuma]

To add my $.02: I would love support for declaring commands. My use case involves things like initializing a database and other operational tasks. My current preference is to run those commands in one of the containers I already declared (since they have the context needed to do it).

I currently do this by adding executables in the container and doing things like docker-composes exec web /init-db. This isn't complex, but I would still like to be able to declare this in my compose file, for the same reasons you might write them out in a Makefile:

• Discoverability
• Executable documentation
• It's just convenient