Compose: services with 'depends_on' cannot be extended

[krasi-georgiev]

Will this be supported in the future releases ?

[gingerlime]

... Not sure if this achieves the same results as extends, but you can use yml references to avoid copy&pasting and keeping this DRY inside your docker-compose.yml, e.g.

web: &web
  image: your_image
  depends_on:
    - db
  ...
web1:
  <<: *web

[aanand]

What are you trying to do that requires both extends and depends_on? Can it be done with multiple Compose files instead?

[gingerlime]

I'm personally only experimenting and considering options at this stage.

I'm trying to build a zero-time rolling upgrade based on this pattern.

Perhaps multiple compose files can also be used in this case, but I haven't tried it yet. Thanks for suggesting it.

[intellent]

Why has this been closed? May I cite the official documentation here:

Note: links, volumes_from, and depends_on are never shared between services using extends. These exceptions exist to avoid implicit dependencies—you always define links and volumes_from locally. This ensures dependencies between services are clearly visible when reading the current file. Defining these locally also ensures changes to the referenced file don’t result in breakage.

I interpret this as follows: Extending services with depends_on should work, but you have to redefine your dependencies locally. Which would totally make sense to me.

Basically all my services use depends_on and networks for orchestration since links are not recommended anymore. This renders the extends mechanism useless for me.

[krasi-georgiev]

i think I managed to achieve the same effect by using multiply compose files with the -f option

[intellent]

@krasi-georgiev You’re right. However, IMHO the current behavior renders the extends mechanism useless in a lot of cases. This could not be the intention, could it?

[krasi-georgiev]

I don't know , some of the devs should answer that

[mlovic]

I've been wondering the same thing. I had the same interpretation of the docs as @intellent. The documentation doesn't seem to match behaviour.

Regarding @aanand's suggestion of using multiple compose files, that could work, but I think extends would fit much better in situations where services only slightly differ, or the same app/codebase takes on different "roles". For example:

web_app:
  depends_on:
    - db
  command: puma -C config/puma.yml
  ...
worker:
  extends:
    service: web_app
  command: sidekiq -C config/sidekiq.yml

for a Rails worker process

or

...
admin:
  extends:
    service: web_app
  environment:
      - ADMIN_MODE=true

for an Admin instance

Please let me know if there's anything I'm missing, thanks!

[mkozjak]

Why is this closed once more?

[dazinator]

Can this be reopened?

[shin-]

It is closed because the original reporter considers the issue resolved.

It does not need to be re-opened as:

1. It is a duplicate of #1988
2. the recommended way to have an abstract, inheritable "base definition" is to use extension fields. We still believe that depends_on should be declared ad-hoc to improve clarity and reduce complexity, but that method doesn't enforce it.

[pdfrod]

At the very least the docs should be clarified, as I too had the same interpretation as @intellent.

[shin-]

https://github.com/docker/docker.github.io/issues/new

[Kolyunya]

Why can't compose just ignore or skip the depends_on option while extending services and let us reuse all the other bits of service configuration? This approach would have several benefits:

• it is backward compatible;
• it prevents implicit service dependencies;
• it make the extends option actually useful.

[superlevure]

I also think the implementation is not what the documentation leads us to believe, totally agree with @Kolyunya and @intellent .
So I opened a new issue: https://github.com/docker/compose/issues/7916