The Problem / Use Case
docker-compose is often used as a simple way to setup and run an application locally for development purposes. For this not always all defined services are required to run - or additional services may be useful for development. But starting the application with a simple docker-compose up without explicitly specifying a list of services always starts all defined services.
For example: I like to define an additional service running phpMyAdmin alongside a mysql database service in order to have a convenient way to inspect and manipulate the database in development. But this service should only ever run in development and may even there be optional/only started on-demand.
Currently the recommended way for this use case is to split the services into multiple files and pass them on the command line
docker-compose -f docker-compose.dev.yml up
Since the additional services may depend on (e.g. the database service) or extend already defined services this may require to combine multiple files when starting the development environment:
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up
In an automated environment this is no issue since it just needs to be scripted once. But in a development environment this is a huge inconvenience for the developer:
- the command lines become very long to type instead of a simple
docker-compose up
- the developer has to remember/lookup which services are defined in which files and pass them as parameters
- the same set of files needs to be passed to every
docker-compose command since services defined in other files will be ignored, i.e. one can not just stop the application with docker-compose stop/docker-compose down since the additional services will be ignored
This is a real pain for developers which is why various solutions to this issue were repeatedly requested over years, see linked issues below.
The desired new feature
There should be a simple way to define the set of "default services" that are started when docker-compose up is called without any arguments.
This way additional services can still be defined in the same docker-compose.yml file which can then be started on-demand:
# start set of "default services"
docker-compose up -d
# start additional service for development
docker-compose up phpmyadmin
There are various ways the default set could be specified in the docker-compose.yml file:
- provide a file-wide (white)list of services to be started by default, which when not specified defaults to all defined services
- specify a (black)list of services which should not be started by default but only when explicitly listed or when pulled in as a dependency
- specify on a per service basis if it should be included in the default set or not; when not specified, the service will be included
Additional context
This or a similar feature was requested for docker-compose repeatedly and in the discussions many more example use cases were explained by the users showing this is a real pain point for them:
docker/compose#6742 (most recent discussion), docker/compose#1896 (main discussion), docker/compose#697, docker/compose#912, docker/compose#1294, docker/compose#1439, docker/compose#1547, docker/compose#2803, docker/compose#3027, docker/compose#3289
Further related issues: docker/compose#1661, docker/compose#1988, docker/compose#2773, docker/compose#3684, docker/compose#4096, docker/compose#4650, docker/compose#6676
Personal note
I am missing such a feature with docker-compose since a very long time. I think it can be implemented with quite reasonable effort but provides an immense improvement convenience-wise for local development.
One possible solution I already have implemented which I will explain in the comments.
I'm very committed to making this feature happen whether with my proposed solution or any other different way which I'm also open too. My desired outcome is the improved developer-convenience for the presented use case.
So I am grateful for any feedback and suggestions!
The Problem / Use Case
docker-composeis often used as a simple way to setup and run an application locally for development purposes. For this not always all defined services are required to run - or additional services may be useful for development. But starting the application with a simpledocker-compose upwithout explicitly specifying a list of services always starts all defined services.For example: I like to define an additional service running phpMyAdmin alongside a mysql database service in order to have a convenient way to inspect and manipulate the database in development. But this service should only ever run in development and may even there be optional/only started on-demand.
Currently the recommended way for this use case is to split the services into multiple files and pass them on the command line
Since the additional services may depend on (e.g. the database service) or extend already defined services this may require to combine multiple files when starting the development environment:
In an automated environment this is no issue since it just needs to be scripted once. But in a development environment this is a huge inconvenience for the developer:
docker-compose updocker-composecommand since services defined in other files will be ignored, i.e. one can not just stop the application withdocker-compose stop/docker-compose downsince the additional services will be ignoredThis is a real pain for developers which is why various solutions to this issue were repeatedly requested over years, see linked issues below.
The desired new feature
There should be a simple way to define the set of "default services" that are started when
docker-compose upis called without any arguments.This way additional services can still be defined in the same
docker-compose.ymlfile which can then be started on-demand:There are various ways the default set could be specified in the
docker-compose.ymlfile:Additional context
This or a similar feature was requested for
docker-composerepeatedly and in the discussions many more example use cases were explained by the users showing this is a real pain point for them:docker/compose#6742 (most recent discussion), docker/compose#1896 (main discussion), docker/compose#697, docker/compose#912, docker/compose#1294, docker/compose#1439, docker/compose#1547, docker/compose#2803, docker/compose#3027, docker/compose#3289
Further related issues: docker/compose#1661, docker/compose#1988, docker/compose#2773, docker/compose#3684, docker/compose#4096, docker/compose#4650, docker/compose#6676
Personal note
I am missing such a feature with
docker-composesince a very long time. I think it can be implemented with quite reasonable effort but provides an immense improvement convenience-wise for local development.One possible solution I already have implemented which I will explain in the comments.
I'm very committed to making this feature happen whether with my proposed solution or any other different way which I'm also open too. My desired outcome is the improved developer-convenience for the presented use case.
So I am grateful for any feedback and suggestions!