[BUG] docker compose run trying to map service ports?

[DanielBaulig]

Description

I am using docker compose --profile=tests --project=tests run to run isolated tests in my development environment. The documentation of docker compose run states that no service ports will get published to the host unless --service-ports=true is specified.

However, my tests www container seems to fail to start for failing to bind ports if I have my development container running at the same time. Note that the container being run is not the www container, but the tests container, which however depends_on the www container, My guess is that depends_on containers still expose their service ports even when no --service-ports=true is specified.

Output of docker comose --verbose run below

TRAC[0000] Docker Desktop integration not enabled
DEBU[0000] Running service without ports exposed as --service-ports=false
[+] Creating 1/0
 ✔ Container tests-db-1  Running                                                                    0.0s
[+] Running 1/2
 ✔ Container tests-db-1   Healthy                                                                   0.5s
 ⠹ Container tests-www-1  Starting                                                                  0.3s
Error response from daemon: driver failed programming external connectivity on endpoint tests-www-1 (b744
e88e0bd602da01807baf96d14d351f24587a71efb6e8275788d8a4430e55): Bind for 0.0.0.0:5173 failed: port is alre
ady allocated

If this is intended behavior, then the documentation for docker compose run should be explicit about it. Nothing currently makes it clear that this is how it's expected to work.

Steps To Reproduce

Container A that depends_on container B. Container B has published ports in the compose.yml. When container A is started with docker compose run, container B will get started as a dependency, too, but will have it's ports published, even though no --service-ports was provided.

Compose Version

Docker Compose version 2.26.1

Docker Environment

Client:
 Version:    26.0.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  0.13.1
    Path:     /usr/lib/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.26.1
    Path:     /usr/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 63
  Running: 5
  Paused: 0
  Stopped: 58
 Images: 41
 Server Version: 26.0.0
 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: cgroupfs
 Cgroup Version: 1
 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
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dcf2847247e18caba8dce86522029642f60fe96b.m
 runc version:
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 5.15.146.1-microsoft-standard-WSL2
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.31GiB
 Name: Zauberwerkstatt
 ID: b491fb94-8397-41c8-ad83-677228b08b11
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support

Anything else?

No response

[ndeloof]

My guess is that depends_on containers still expose their service ports

indeed. "one-off" container started by run command doesn't get ports exposed by default, as the run command is designed to run maintenance scripts and not main service. But dependencies run as services, so get ports exposed.

I guess your issue here is that you want to run with a dedicated test project name, so the conflict with the running services already using ports. Why do you override project name? You should just run your test container and rely on existing services.

[DanielBaulig]

It might be useful to call out this behavior explicitly in the documentation. I read the run and --service-ports documentation multiple times and it wasn't clear to me that this is expected behavior.

I need to run the tests in a separate instance of the services for state reasons. I want to have close control over the state of the application and service and not pollute / interfere with the state of my development environment. For example I want to cover the case of spinning up / updating the service containers in production. If I was running the tests against an already active instance of the application I would not get that.