Global service options

[maciejpankanin]

Description

Let's consider a project like this:

• docker/additional-services.yml - a file containing definitions of services that I don't want to know much about
• docker-compose.yml - a file containing core services of my project
• docker-compose.production.yml - a file containing additional configuration for all services that should be applied in production

Example content of the files:

# docker/additional-services.yml

services:
  service1:
    ...
  ...
  serviceN: # as I mentioned before, I don't care how many, and what kind of services this file contains
    ... 

# docker-compose.yml

include:
  - path:
      - ./docker/additional-services.yml

services:
  my-core-service:
    ...

# docker-compose.production.yml

services:
  my-core-service:
    restart: always

The issue is when I run

docker compose -f docker-compose.yml -f docker-compose.production.yml up

I would like to all the services being always restarted, but the only way of achieving this is running:

docker update --restart always $(docker ps -q) 

It is not a clean solution, it would be better if I could

# docker-compose.production.yml

restart: always

and this configuration would apply to the all services. There is a similar solution in the Gitlab CI configuration where

before_script:
    - echo "1 + 1 = "

job1:
  script:
    - echo "2"

job2:
  before_script:
    - echo "2 + 2 = "
  script:
    - echo "4"

would print 1 + 1 = 2 for job1 and 2 + 2 = 4 for job2

What could I do to make it clean?

[ndeloof]

Just use docker compose restart if you want all service to be restarted.
What's the use-case for this ?

[maciejpankanin]

That's a confusing question. You don't add restart: always when you want to restart all containers once, but when you want them to start after failure, after system reboot, etc.

[ndeloof]

Yes indeed, I've been too fast posting an answer.

Generally speaking, use of include assumes the author of the nested compose file offers the required flexibility, relying on variables in the included compose file so you can tweak the model for your needs. For your usage, this means additional-services.yml should have restart configured with a variable so you can set value to always when relevant. Another option is for author to provide a dedicated override compose file to set this attribute.

Compose doesn't offer any kind of "global/pattern override" that you could use to set attribute on all services.

[maciejpankanin]

I understand, but at the moment the only way to reuse a configuration is to use yaml anchors or, as you suggested, with a variable. I think both solutions are bad and that is why I have marked this as a feature request.

Explanation:

• yaml anchors - why would you rely on this when it has limitations, e.g. in the case I mentioned above. include is not a standard `yaml' feature, and the way it works now it does not work with anchors defined in including files.
• variables - these are not really explicit and assume their existence in all included yamls.

Assumption: there is currently no clean way to reuse/detail service configuration.

[ndeloof]

variables is the way compose offers flexibility. The other way is by explicit override files
What you are asking for here is a completely distinct approach that we could consider for a future major release, but would involve a major change in compose file parser design - or maybe could be implemented as a separate tool, to pre-process your compose model.
What about docker compose config | yq <transformation> | docker compose -f - up ?

[maciejpankanin]

Ok, I understand this would be a BIG change, but had to try 😀

I will stick to the variables for now, thanks.

For me it can be closed, up to you.