Description
Description
Hi there! Starting in compose version 2.3.0, the run
command is bringing up linked containers that are not strict dependencies of the service that is being started. This behavior only happens if I have previously used up
with one of the unrelated services.
I don't see anything that's jumping out to me in the changelog that would cause this & I don't see any updates to the docs suggesting that the behavior of these has changed, which makes me think this is a bug. Is this new behavior intentional though?
Steps to reproduce the issue:
I can demonstrate this issue with a toy compose definition:
version: "3.6"
services:
service_a:
image: bash
command: echo "a"
depends_on:
- shared_dep
service_b:
image: bash
command: echo "b"
depends_on:
- shared_dep
shared_dep:
image: bash
Describe the results you received:
If I just execute run service_a
, compose will start the shared_dep
container and the service_a
container as expected:
❯ docker-compose run service_a
[+] Running 2/2
⠿ Network compose-bug-test_default Created
⠿ Container compose-bug-test-shared_dep-1 Created
[+] Running 1/1
⠿ Container compose-bug-test-shared_dep-1 Started
a
However, an docker version 2.3.0 and above if I (1) execute up service_b
and then (2) execute run service_a
, I see the unrelated service_b
also get launched:
~panorama/compose-bug-test
❯ docker-compose up service_b
[+] Running 3/2
⠿ Network compose-bug-test_default Created
⠿ Container compose-bug-test-shared_dep-1 Created
⠿ Container compose-bug-test-service_b-1 Created
Attaching to compose-bug-test-service_b-1
compose-bug-test-service_b-1 | b
compose-bug-test-service_b-1 exited with code 0
~panorama/compose-bug-test
❯ docker-compose run service_a
[+] Running 1/0
⠿ Container compose-bug-test-shared_dep-1 Created
[+] Running 2/2
⠿ Container compose-bug-test-shared_dep-1 Started
⠿ Container compose-bug-test-service_b-1 Started
a
Describe the results you expected:
I would not expect run service_a
to ever launch the service_b
container, since they have no dependencies against one another
Additional information you deem important (e.g. issue happens only occasionally):
I have confirmed that this behavior was not present in compose 2.2.3:
❯ docker-compose@2.2.3 up service_b
[+] Running 3/3
⠿ Network compose-bug-test_default Created
⠿ Container compose-bug-test-shared_dep-1 Created
⠿ Container compose-bug-test-service_b-1 Created
Attaching to compose-bug-test-service_b-1
compose-bug-test-service_b-1 | b
compose-bug-test-service_b-1 exited with code 0
~panorama/compose-bug-test
❯ docker-compose@2.2.3 run service_a
[+] Running 1/0
⠿ Container compose-bug-test-shared_dep-1 Created
[+] Running 1/1
⠿ Container compose-bug-test-shared_dep-1 Started
a
I do see the bug in the 2.3.0 release however:
❯ docker-compose@2.3.0 up service_b
[+] Running 3/2
⠿ Network compose-bug-test_default Created
⠿ Container compose-bug-test-shared_dep-1 Created
⠿ Container compose-bug-test-service_b-1 Created
Attaching to compose-bug-test-service_b-1
compose-bug-test-service_b-1 | b
compose-bug-test-service_b-1 exited with code 0
~panorama/compose-bug-test
❯ docker-compose@2.3.0 run service_a
[+] Running 1/0
⠿ Container compose-bug-test-shared_dep-1 Created
[+] Running 2/2
⠿ Container compose-bug-test-shared_dep-1 Started
⠿ Container compose-bug-test-service_b-1 Started
a
Output of docker compose version
:
❯ docker-compose --version
Docker Compose version 2.5.0
Output of docker info
:
Client:
Context: default
Debug Mode: false
Server:
Containers: 75
Running: 18
Paused: 0
Stopped: 57
Images: 434
Server Version: 19.03.12
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.19.130-boot2docker
Operating System: Boot2Docker 19.03.12 (TCL 10.1)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.789GiB
Name: dinghy
ID: CN3C:XYJB:SR6V:ISNK:5CRG:J4QB:KVQO:EK44:YHJV:U2P6:K2NZ:CSZT
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode: false
Username: mdiscalapanorama
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
Thanks so much for any help that ya'll can offer!