CODEWITHSUNDEEP
dockerdocker-compose
Andrew Stubbs
Andrew Stubbs

Reputation: 4462

Configure docker-compose override to ignore / hide some containers

If I have (simplified), the following docker-compose.yml:

parent:
  image: parent
  links:
    - child

child:
  image: child

Can I construct a docker-compose.override.yml file that will not create or start the child image?

An undesirable (for me) solution, would be to reverse the files, such that the default yml file would create only the parent, and the override would create both.

However, I would like the master configuration file to contain the most common usage scenario.

Upvotes: 28

Views: 14081

Answers (4)

Roman Podlinov
Roman Podlinov

Reputation: 24944

I really like solution from Ryan. But it can be improved. Create docker-compose.override.yml next to docker-compose.yml with content:

# disable services
version "3"

fluentd:
    image: hello-world
    command: hello
    restart: "no"

elasticsearch:
    image: hello-world
    command: hello
    restart: "no"

I believe hello-world is a smallest image (size: ~1Kb) on the other hand the size of alpine linux is ~6Mb

Upvotes: 13

Matthew Strasiotto
Matthew Strasiotto

Reputation: 369

For versions of compose < 1.28, january 2021

If you're disabling multiple services in an override file (As in Ryan's answer ), you might find it useful for Don't-Repeat-Yourself to make use of extension fields, & yaml anchors (essentially "back references" in yaml).

As in:

# Your version
version: "2.4"

# `&anchor-name` defines the anchor (Here it is a map/dict)
# `*anchor-name` references the anchor
# `<<: *anchor-name` merges (`<<:`) the keys of `*anchor-name` with the current map

x-disabled-service: &disabled
  image: "tianon/true"
  command: "true"
  entrypoint: "true"

services:
  elasticsearch:
    <<: *disabled
    
  fluentdb:
    <<: *disabled

This uses tianon/true as suggested in Ryan's comment as a very small image.

The outcome is functionally the same as Ryan, or Roman's answers, but a bit less verbose.

For compose versions >= 1.28

Also, according to mcarson's answer to a similar SO question as of compose 1.28, January 2021, there exists a new compose field, profiles, which lets you group together containers that can be switched on using a commandline option --profile.

https://docs.docker.com/compose/profiles/

Upvotes: 9

Ryan
Ryan

Reputation: 1221

In defense of the original poster: I totally get why you would want to do this. The docker-compose way always seems to be "put your variation in the override files", but in the interest of keeping things simple within a large development team, I like:

  • The ability to start everything with one command (e.g. "docker-compose up" or "docker-compose up main")
  • All of my docker definitions in one place
    • The only variation in override files to be which containers are disabled

Here's how I did it in my override files: 

  # Disable database containers
  postgres:
    image: alpine:latest
    command: "true"
    entrypoint: "true"
  mysql:
    image: alpine:latest
    command: "true"
    entrypoint: "true"

The upshot is, all containers are started by "docker-compose up", but those that I've overridden immediately die.

If you want an ever lighter weight container than alpine, try tianon/true.

Upvotes: 24

johnharris85
johnharris85

Reputation: 18916

You don't have to start every service when you run compose, you can just run up and pass the names of the services to start. See the official reference for up here.

So for instance: docker-compose up -d parent

Upvotes: 3

Related Questions