[BUG] Why does compose up always recreate one-shot containers?

[felipecrs]

Description

Let's start small:

services:
  service:
    image: ubuntu
    command: [sleep, infinity]

Now run:

$ docker compose up --wait service
[+] Running 1/1
 ✔ Container tmpatc8nam0wa-service-1  Healthy                                                                  12.0s

It will start the service and exit once healthy.

Now run the same command again:

$ docker compose up --wait service
[+] Running 1/1
 ✔ Container tmpatc8nam0wa-service-1  Healthy                                                                   0.5s

It will NOT re-create the service, because nothing changed, and therefore the service didn't need to be recreated. This is great!

Now, let's add a one-shot container to the mix:

services:
  script:
    image: ubuntu
    command: [sleep, 5s]
  service:
    image: ubuntu
    command: [sleep, infinity]
    depends_on:
      script:
        condition: service_completed_successfully

And let's:

$ docker compose up --wait service
[+] Running 3/3
 ✔ Network tmpatc8nam0wa_default      Created                                                                   1.0s 
 ✔ Container tmpatc8nam0wa-script-1   Exited                                                                    8.1s 
 ✔ Container tmpatc8nam0wa-service-1  Healthy                                                                   8.1s

All good so far. Let's try again:

$ docker compose up --wait service
[+] Running 2/2
 ✔ Container tmpatc8nam0wa-script-1   Exited                                                                    6.8s 
 ✔ Container tmpatc8nam0wa-service-1  Healthy                                                                   6.8s

And as you can notice by the time taken, the script was recreated. Because of this, it did not finish fast.

In my opinion this is not the proper behavior. Since condition: service_completed_successfully, I was expecting the one-shot service not to be recreated if it had last completed succesfully and nothing was changed in the compose configuration.

At least for some of my use cases, this causes each docker compose up here to take useless 20 minutes to execute even if nothing was changed. So, this is big deal to me. :(

Steps To Reproduce

See above.

Compose Version

2.27.0

Docker Environment

Client: Docker Engine - Community
 Version:    26.1.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 3
  Paused: 0
  Stopped: 1
 Images: 20
 Server Version: 26.1.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc sysbox-runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.153.1-microsoft-standard-WSL2
 Operating System: Ubuntu 22.04.4 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 15.62GiB
 Name: FELIPE-MSI
 ID: fe0d4b33-6e01-4e84-819c-624eacf4eb44
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 172.25.0.0/16, Size: 24

Anything else?

No response

[ndeloof]

Compose expect a service to be a "long running process", and as such up will create and start container according to your compose file. Your script container then is created/restarted.

I was expecting the one-shot service not to be recreated if it had last completed succesfully and nothing was changed in the compose configuration.

compose does not have support for "init containers" (one-shot containers as you name them) that would support such a lifecycle, where the script container is ran with the service one and not executed in isolation. service_completed_successfully has been a very limited step toward this feature but we don't yet have a real solution to this.

[felipecrs]

I see. Thank you. Should we keep this issue open as a feature request then?

[ndeloof]

Closing until we get better support for init containers, see compose-spec/compose-spec#291

[felipecrs]

I just don't understand why a full-blown new syntax would be required. Can't the issue I'm reporting be fixed more simpler way? I think docker compose only needs to remember whether the service last exited successfully or not, and then re-run or not based on this + whether the service definition changed or not.

[ndeloof]

this would require a change in the existing behavior that would have impacts for other users

[felipecrs]

Maybe this is the kind of behavior change that everyone would appreciate receiving? lol