Skip to content

Add option to specify services to be started by default #87

Description

@acran

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:

  1. provide a file-wide (white)list of services to be started by default, which when not specified defaults to all defined services
  2. 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
  3. 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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions