Support assignment of a default `profile` (v2)

[thespad]

Description

The current implementation of profiles allows for zero or more profiles to be assigned to a service but if you assign one or more then you cannot also have a service be part of the default profile set, in a similar way to networks where not specifying a network assumes the service is attached to the default network, but if you attach it to the foo network can you also attach it explicitly to the default network.

Use case: I have a compose project with multiple services. Some of these services depends_on other services, some are standlone. The services that depend on others are assigned a profile so that I can docker compose --profile foo stop && docker compose --profile foo up -d to ensure the child containers are stopped before the parents are recreated.

I would like to be able to also assign those services to the default profile so that if I run for example docker compose pull it would pull images for all services. Right now I have to add every services to an explicit default profile and run docker compose --profile default pull to achieve this and that means always having to specify a profile for all commands.

Ultimately this would manifest as:

services:
  child:
    image: web
    profiles:
      - foo
      - default
    depends_on:
      - parent

  parent:
    image: db
    profiles:
      - foo
      - default

  standalone:
    image: metrics
    profiles:
      - bar
      - default

[ndeloof]

You could use docker compose --profile "*" <command> to run command with all services enabled

[thespad]

Huh, is that documented anywhere? I had tried --profile * previously and it didn't work but I hadn't thought to try wrapping it in quotes.

It's better than the current situation but it would still be preferable to be able to have a service be part of a "named" profile and still part of the default one.

[ndeloof]

profile have been designed to allow declaration of some optional resources, that should not be enabled by default. If you want a service to be part of the "default" profile, why do you declare a profile for it? Your use case is a bit unclear to me.

[thespad]

So I have a collection of services with depdendencies that need to be sent a stop before an up because (AFAIK) up still does not respect depends_on and recreate dependent containers in the correct order. There are also some services that are independent and don't need to be stopped before updating.

What I'd like my workflow to be is:

docker compose pull docker compose --profile foo stop docker compose up -d

And have that pull images for all services, stop the dependent services, then recreate any containers that need it.

At the moment my workflow is:

docker compose --profile "*" pull docker compose --profile foo stop docker compose --profile "*" up -d

This is fiddly because the profile names can differ between projects and it means I can't easy alias the commands.

Hope that makes sense.

[ndeloof]

ok, so the root cause for asking this is "up still does not respect depends_on and recreate dependent containers in the correct order". Did you opened an issue for this?

[thespad]

Not against v2 - there was definitely one for v1 but I wasn't the person who opened it.

[ndeloof]

I'm not aware of such an issue with v2. Gave a quick try using this minimal compose.yaml file:

services:
  c1:
    image: nginx
    depends_on:
     - c2
  c2:
    image: nginx

work as expected:

$ docker compose up --force-recreate -d
Container truc-c2-1  Recreate
Container truc-c2-1  Recreated
Container truc-c1-1  Recreate
Container truc-c1-1  Recreated
Container truc-c2-1  Starting
Container truc-c2-1  Started
Container truc-c1-1  Starting
Container truc-c1-1  Started                    

[thespad]

So I just ran this test (truncated compose) with Docker Compose version v2.2.3:

services:
  vaultwarden:
    image: docker.io/vaultwarden/server:alpine
    container_name: vaultwarden
    depends_on:
      - vaultwarden-db

  vaultwarden-db:
    image: docker.io/postgres:12-alpine
    container_name: vaultwarden-db

And with a docker compose up --force-recreate -d it does

 ⠿ Container vaultwarden-db  Recreate 

Then

 ⠿ Container vaultwarden     Recreate 

And then starts them in the correct order (vaultwarden-db then vaultwarden)

[thespad]

I should clarify, that's not correct behaviour (from my perspective).

When X depends_on Y, then Y should start before X and X should stop before Y.

In the case of a front end that depends_on a database I want the database running before the front end, but I want the front end stopped before the database, because pulling a database out from under a running front end which could be performing queries is a terrible idea.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.