Extend a base service from the same file

[bfirsh]

It is a common pattern to define a base service which you want several services to extend, but it's currently very verbose to do this:

docker-compose-base.yml

base:
  environment:
    FOO: bar

docker-compose.yml

web:
  extends:
    file: docker-compose-base.yml
    service: base
  ...
db:
  extends:
    file: docker-compose-base.yml
    service: base
  ...

It should be possible to extend an incomplete service in a single compose file. Something like this:

base:
  abstract: true
  environment:
    FOO: bar
web:
  extends:
    service: base
  ...
db:
  extends:
    service: base

Design decisions:

• How should a service be marked as a service that shouldn't be run? (I've used "abstract" in the example above for the sake of illustration, pinched from Django's "abstract" models.)

[dnephin]

It is a common pattern to define a base service which you want several services to extend,

Do you have some examples of this? I've never seen it myself, and I'm having a hard time understanding why you would ever need this?

If you want to share a bunch of common environment you can use an env_file, or even a data volume container with volumes_from.

[dnephin]

I think supporting abstract services might be a mistake. The only requirement for a service is to have an image, which is a pretty easy requirement to satisfy. You can always just use small base image to satisfy it (ex: alpine:edge). Supporting abstract services adds extra complexity that I think we can avoid.

[bfirsh]

@dnephin The problem is it also has to run when you do docker-compose up. Sort of related to this too: #1896

[dnephin]

You can always set a command of true, sh, echo to just have it run basically a no-op. We fixed the behaviour in 1.4 so that one container exiting doesn't cause the whole stack to shutdown.

[aanand]

Actually, I think that fix lands in 1.5.

[j-a-m-l]

Currently I am using YAML node anchors, but this proposal could be more useful.

That works this way:

web: &piwik-base
  container_name: piwik-web
  image: piwik-image
  restart: always
  ...

cron:
  <<: *piwik-base
  container_name: piwik-cron
  command: cron -f

When extending other file, it also requires the file key, like this thread initial example.

[dnephin]

This is now in the 1.5.0 release. The rest is covered by #1896

[dnephin]

@j-a-m-l yaml nodes and anchors are another option. I've used them myself, but not everyone is a fan.

There's an older PR for adding them to the docs: #1015

[amanica]

I'd like to have a common base that includes dns and dns_search options, will look at the YAML node anchors workaround for now.

[bfirsh]

Reopening because @fxdgear has run into this issue running some internal Docker stuff.

We should either:

1. Document the recommended way of doing this currently (using command: /bin/true?)
2. Implement this as a feature and document it

My concern is that using a fake command is a hack – and isn't obvious when reading the Compose file what the intent of that is. I think (1) would work as a stop gap, but I think we should probably do (2) at some point.

[bfirsh]

Also another idea from @fxdgear: maybe these things could live under a different key? Example above would look like:

base-services:
  base:
    environment:
      FOO: bar
services:
  web:
    extends:
      service: base
    ...
  db:
    extends:
      service: base

The reason I dislike this is it would mean having a new top-level key for each type of object we add to Compose files (networks, volumes, etc).

[dunk]

I think that abstract base services are one half of the problem. They cover the case where you have services which are very similar, sharing most of their defined attributes. However, many services still need to share common subsets of attributes (frequently if there is a one-to-many relationship between some set of containers - e.g. a database or a queue - where all client services will share configuration). In that case, a single abstract base class doesn't buy you much. There's a longer ticket with more discussion over here if you are interested: #3167.

[wclr]

So, what is the current state, is it possible to extend service from current docker-compose.yml?

[jamshid]

@whitecolor idk but I think extends itself eventually became deprecated.

The recommended replacement, where you specify multiple compose yml files in COMPOSE_FILE and they are merged, doesn't really satisfy this use case.

In docker-compose 1.14.0 how do people reuse common configuration of a service when defining other services?

[wclr]

@jamshid probably not typical approach for a medium project I prefer to use dynamic docker-compose config that is produced from JS (TypeScript) configuration. But it works much better than dancing around docker-compose.yml format, yaml anchors, etc.

[bfirsh]

Specifying multiple Compose files doesn't satisfy this use case. (I ran into this problem again today.)

[shin-]

Addressed in #5140

[p7k]

Sorry, I still don't quite see what solution is now (from #5140). Could someone point me to the docs?

[shin-]

https://docs.docker.com/compose/compose-file/#extension-fields

[Fi1osof]

2020 year.
Still waiting for...

[shinsenter]

2021

[kylr42]

2022

[gfranxman]

2023

[xurvan]

2023 😢

[izakdvlpr]

2023

[dfyz011]

2024

[chardskarth]

@dfyz011 @izakdvlpr (and the rest)

Isn't this achievable already (since 2017) via Extension Fields?

Using the example above, you could do

x-base-service: &base-service
  environment:
    FOO: bar
    
web:
  <<: *base-service
  ...
db:
  <<: *base-service

[Nicba1010]

It is not, the extension fields override nodes of the same name. So for example it will override my entire environment.