Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Services with profile in yml, always enable when execute command start, stop, restart, up #9286

Closed
ani3llyon opened this issue Mar 15, 2022 · 11 comments · Fixed by #9488
Closed

Comments

@ani3llyon
Copy link

Since docker compose v 2.3.0 when ever I run docker compose with command start, stop, restart, and up all container for service with profile in docker-compose.yml will be always included even the profile is not enabled.

example command

# will create container for service without profile but will start all container
# even the container is for service with profile
docker compose up -d

# will start/stop/restart all container even the container is for service with profile
docker compose start
docker compose stop
docker compose restart

example docker-compose.yml

version: "3.9"
services:
  serviceA:
    ...
  serviceB:
    ...
    profiles: ["debug"]

step by step

# will create and start container for service A
docker compose up -d

# will start/stop/restart container for service A
docker compose start
docker compose stop
docker compose restart

# will stop and remove container for service A
docker compose down

# will create and start container for service B
docker compose up -d serviceB

# will stop container for service B
docker compose stop serviceB

# will create and start container for service A
# also start serviceB <-- why? profile 'debug' is not enabled
docker compose up -d

# will start/stop/restart container for service A
# also start/stop/restart serviceB <-- why? profile 'debug' is not enabled
docker compose start
docker compose stop
docker compose restart
@JimDabell
Copy link

I’m experiencing this too. It started happening immediately after upgrading to Docker for Mac 3.6.0 which brought with it the new version of Compose.

Output of docker compose version:

Docker Compose version v2.3.3

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.0)
  compose: Docker Compose (Docker Inc., v2.3.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 41
  Running: 40
  Paused: 0
  Stopped: 1
 Images: 34
 Server Version: 20.10.13
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 5
 Total Memory: 15.6GiB
 Name: docker-desktop
 ID: PXOD:DP6Y:5VBX:AWEG:FKRP:JMIL:TXPW:RGK7:A7LK:23AP:ZXOV:C6NN
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

The docker info output doesn’t seem to be correct – it says I’ve got 40 running containers. I have four running containers and one stopped container, confirmed with docker ps and docker ps -a.

@lorthirk
Copy link

lorthirk commented Mar 22, 2022

Just noticed this as well

EDIT: It seems that Compose tries to bring up any container he finds in a project that has already started once, even if stopped. Removing those containers works around the issue, but as soon as they start once they come back again.

@krissetto
Copy link

krissetto commented Mar 22, 2022

I have also noticed this issue on MacOS using the latest version of Docker Desktop. This is quite a deal breaker, as it renders the profiles feature unusable in most of my development scenarios

$ > docker compose version

Docker Compose version v2.3.3
$ > docker context show

default
$ > docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.0)
  compose: Docker Compose (Docker Inc., v2.3.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 19
  Running: 0
  Paused: 0
  Stopped: 19
 Images: 25
 Server Version: 20.10.13
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 6
 Total Memory: 11.67GiB
 Name: docker-desktop
 ID: UDA4:27AH:5HX2:EOR6:HVM6:KDGM:HF3M:RKUD:KVYP:PXNL:7VSH:ORLU
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false
$ > docker version

Client:
 Cloud integration: v1.0.22
 Version:           20.10.13
 API version:       1.41
 Go version:        go1.16.15
 Git commit:        a224086
 Built:             Thu Mar 10 14:08:43 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.6.0 (75818)
 Engine:
  Version:          20.10.13
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.15
  Git commit:       906f57f
  Built:            Thu Mar 10 14:05:37 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.5.10
  GitCommit:        2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc:
  Version:          1.0.3
  GitCommit:        v1.0.3-0-gf46b6ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

@lorthirk
Copy link

Yeah, I forgot, I'm on macOS as well:

❯ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.0)
  compose: Docker Compose (Docker Inc., v2.3.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 5
  Running: 0
  Paused: 0
  Stopped: 5
 Images: 196
 Server Version: 20.10.13
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.842GiB
 Name: docker-desktop
 ID: GGYN:WBT3:SSZ2:QEVD:JSRE:D2VU:6476:SWPN:HAXA:TEEL:GWP3:BXCQ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

❯ docker version
Client:
 Cloud integration: v1.0.22
 Version:           20.10.13
 API version:       1.41
 Go version:        go1.16.15
 Git commit:        a224086
 Built:             Thu Mar 10 14:08:44 2022
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.6.0 (75818)
 Engine:
  Version:          20.10.13
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.15
  Git commit:       906f57f
  Built:            Thu Mar 10 14:06:05 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.5.10
  GitCommit:        2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc:
  Version:          1.0.3
  GitCommit:        v1.0.3-0-gf46b6ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

❯ docker compose version
Docker Compose version v2.3.3

@ndeloof
Copy link
Contributor

ndeloof commented Apr 11, 2022

For up command AFAICT this has been fixed by #9365
For start, restart and a few others, the issue is the code is based on project name, not the compose file you provide, so profile isn't applied.
As discussed with @glours we need to globally define logic and apply on all commands:

if compose file set {
   project = // parse compose file and apply profiles
} else if --project-name {
   project = // search for resources with project label
}

@AdrienPoupa
Copy link

I am having the same issue on MacOS with Docker Desktop 4.7.0 and Docker Compose 2.4.1.

When I do docker compose --profile my-profile up -d, the containers associated with my-profile start as expected.

But after I stop them, whether this is with down or stop, if I do docker compose up -d the containers associated with my-profile still start even though they should not.

@krissetto
Copy link

For up command AFAICT this has been fixed by #9365 For start, restart and a few others, the issue is the code is based on project name, not the compose file you provide, so profile isn't applied. As discussed with @glours we need to globally define logic and apply on all commands:

if compose file set {
   project = // parse compose file and apply profiles
} else if --project-name {
   project = // search for resources with project label
}

I feel like it could be useful to include profile information with the project iteself (maybe there are some metadata fields available?), so users aren't required to specify both the project name and the compose files for services that are already part of the project.
Has this type of behavior already been considered, or is the idea to require both project and compose files to be able to use the profile functionality?

@gisostallenberg
Copy link

For up command AFAICT this has been fixed by #9365
For start, restart and a few others, the issue is the code is based on project name, not the compose file you provide, so profile isn't applied. As discussed with @glours we need to globally define logic and apply on all commands:

if compose file set {
   project = // parse compose file and apply profiles
} else if --project-name {
   project = // search for resources with project label
}

#9365 only seems to fix this for start, not up, or maybe I understand something wrong...

@AdrienPoupa
Copy link

It seems to be fixed in up on my end (Docker Desktop v4.8.1)

@basicdays
Copy link

basicdays commented May 18, 2022

For me, config/build/up/down are working. However start/stop/restart are not respecting profiles. Hitting ctrl+c after running up without --detach will also cause the same stop behavior regardless of what profiles were used during the up invocation.

I am running docker compose 2.5.0 on MacOS. I have a VSCode Docker dev container that has the Docker socket bound into it as well. It's running docker compose 2.4.1+azure-1 with the same results.

@jonocodes
Copy link

jonocodes commented May 19, 2022

I had this problem when using compose 2.3.3, but now it is manifesting differently in compose 2.5.1. Same experience on mac (Docker Desktop v4.8.2) and linux (without Docker Desktop). Now it just hangs forever during cleanup since it appears to be trying to stop a container that is not running.

docker-compose.yaml :

version: "3.8"
services:
  foo:
    image: nginx
    ports:
      - "123:123"
    profiles: ["f"]
  bar:
    image: nginx
    ports:
      - "123:123"
    profiles: ["b"]
➜  ~ docker compose --profile f up            
[+] Running 1/0
 ⠿ Container test-foo-1  Running        
Attaching to test-foo-1
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 1/1
 ⠿ Container test-foo-1  Stopped      
canceled

➜  ~ docker compose --profile f up    
[+] Running 1/0
 ⠿ Container test-foo-1  Created   
Attaching to test-foo-1
test-foo-1  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
test-foo-1  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
test-foo-1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
test-foo-1  | 10-listen-on-ipv6-by-default.sh: info: IPv6 listen already enabled
...
test-foo-1  | 2022/05/19 03:47:16 [notice] 1#1: start worker process 29
test-foo-1  | 2022/05/19 03:47:16 [notice] 1#1: start worker process 30
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 1/1
 ⠿ Container test-foo-1  Stopped  
canceled

➜  ~ docker compose --profile f up   
[+] Running 1/0
 ⠿ Container test-foo-1  Created  
Attaching to test-foo-1
test-foo-1  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
test-foo-1  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
test-foo-1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
test-foo-1  | 10-listen-on-ipv6-by-default.sh: info: IPv6 listen already enabled
...
test-foo-1  | 2022/05/19 03:47:23 [notice] 1#1: start worker process 28
test-foo-1  | 2022/05/19 03:47:23 [notice] 1#1: start worker process 29
test-foo-1  | 2022/05/19 03:47:23 [notice] 1#1: start worker process 30
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 1/1
 ⠿ Container test-foo-1  Stopped       
canceled

➜  ~ docker compose ps  
NAME                COMMAND                  SERVICE             STATUS              PORTS
test-foo-1    "/docker-entrypoint.…"   foo                 exited (0)

➜  ~ docker compose --profile b up    
[+] Running 1/0
 ⠿ Container test-bar-1  Created  
Attaching to test-bar-1, test-foo-1
test-bar-1  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
test-bar-1  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
test-bar-1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
test-bar-1  | 2022/05/19 03:47:23 [notice] 1#1: start worker process 30
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 2/2
 Container test-bar-1  Stopped
 Container test-foo-1  Stopped
^Cno container to kill^CERRO[0040] got 3 SIGTERM/SIGINTS, forcing shutdown

➜  ~ docker compose ps  
NAME                COMMAND                  SERVICE             STATUS              PORTS
test-bar-1    "/docker-entrypoint.…"   bar                 exited (0)
test-foo-1    "/docker-entrypoint.…"   foo                 exited (0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants