up --scale not working on 2.0.1

[ghost]

Description

docker compose up --scale name=num always reports "unknown service: name"

Steps to reproduce the issue:

$ cat docker-compose.yml
version: '3.8'

services:
  helloworld:
    image: alpine:edge
    entrypoint: /bin/echo Hello world
  scalable:
    image: alpine:edge
    entrypoint: /bin/echo Hello scalable
$ docker-compose -v
Docker Compose version 2.0.1
$ docker-compose up --scale scalable=0 -d helloworld
unknown service "scalable"

With docker-compose version 1.29.2 it works as expected:

$ docker-compose -v
docker-compose version 1.29.2, build unknown
$  docker-compose up --scale scalable=0 -d helloworld
Creating network "docker-compose-playground_default" with the default driver
Creating docker-compose-playground_helloworld_1 ... done

Describe the results you received:

Error: unknown service "scalable"

Describe the results you expected:

scalable service will not be started, all others should

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version 2.0.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.1)

Server:
 Containers: 62
  Running: 28
  Paused: 0
  Stopped: 34
 Images: 170
 Server Version: 20.10.9
 Storage Driver: btrfs
  Build Version: Btrfs v5.14.1
  Library Version: 102
 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 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: 8686ededfc90076914c5238eb96c883ea093a8ba.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.14.8-arch1-1
 Operating System: Arch Linux (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 8EiB
 Name: prometheus
 ID: UF3N:TXOA:MZ3G:J37B:FM36:AW3W:RFP6:ODUX:4UAB:XYQE:6KZJ:EZRG
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: bomensal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support
WARNING: No cpuset support
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
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

[Shikachuu]

To modify the number of replicas with the --scale flag you must start the service.
So you can't run: docker compose up --scale scalable=0 -d helloworld since there is no service specified with name scalable to scale.

If you only want to start the helloworld service, just run docker compose up -d helloworld.

[ghost]

@Shikachuu thanks for your answer. Very interesting. So this is a breaking change to v1 then? Is it intended? If yes I will adapt my scripts to take this into considerations, but is it really an intended change?

[Shikachuu]

I might not be the best person to answer this, because I only keep a close eye on this project since v2.
But if you ask me the v2 makes way more sense to me, then the v1 one, I think this was just a bug in v1, but correct me if I am wrong.

[allanlei]

I had similar expectations coming to v2 from v1.

I normally ran docker-compose up --scale cron=0 with something like

services:
    web:
    worker
    cron
    db
    queue

where normally I don't want to run the cron service. This method worked in v1, but in v2, I get no containers to start.

To get similar behaviour, I can

• Comment out the service in docker-compose.yml
  • Not ideal. Might accidentally commit
• Add a config chain with COMPOSE_FILE=docker-compose.yml:.docker-compose.yml
  • Not ideal. Might make a change that is not commited
• Explicitly run every service like docker-compose up --abort-on-container-exit web worker db queue
  • This is ok, but if there's many services to run, it's inconvient

So you can't run: docker compose up --scale scalable=0 -d helloworld since there is no service specified with name scalable to scale.

I can see some reasoning for this, but I think docker compose up --scale scalable=0 -d would be reasonable to have work since the default is to run all services.

[Shikachuu]

I had similar expectations coming to v2 from v1.

I normally ran docker-compose up --scale cron=0 with something like

services:

    web:

    worker

    cron

    db

    queue

where normally I don't want to run the cron service. This method worked in v1, but in v2, I get no containers to start.

To get similar behaviour, I can

• Comment out the service in docker-compose.yml

  • Not ideal. Might accidentally commit

• Add a config chain with COMPOSE_FILE=docker-compose.yml:.docker-compose.yml

  • Not ideal. Might make a change that is not commited

• Explicitly run every service like docker-compose up --abort-on-container-exit web worker db queue

  • This is ok, but if there's many services to run, it's inconvient

So you can't run: docker compose up --scale scalable=0 -d helloworld since there is no service specified with name scalable to scale.

I can see some reasoning for this, but I think docker compose up --scale scalable=0 -d would be reasonable to have work since the default is to run all services.

Without specifying the services, it is perfectly valid reasoning, I can see why someone might want to do that.

[srgg]

Another differences: if you use --scale svc=0 this service will not be started even it is a dependency of one of the started services? but if you just not started that service (as @Shikachuu suggested) that service will be started if it is a dependency.

Any chance to get back this functionality?

[Shikachuu]

Another differences: if you use --scale svc=0 this service will not be started even it is a dependency of one of the started services? but if you just not started that service (as @Shikachuu suggested) that service will be started if it is a dependency.

Any chance to get back this functionality?

Tbh this "workaround" sounds like you don't want to use the rules you set...

[srgg]

What rules? Not sure that I understand you. It is also unclear to me why you called "workaround" the behavior that was supported several years in a row.

"Dependency" is a specific mechanism that was introduced to achieve multi purpose, I need one aspect and do not need another, as to me - fair enough.

Nevertheless, I have a need to start or not to start several services (depending on current need), there was a way to do that.. And that works like a charm. I do not know any other suitable built-in features that allows me to do the same. I tried profiles, but it does not work smoothly, I've noticed multiple issues with that.

Therefore, Do we have any chance to get back this functionality?
Thank you

[xtaixe]

Hi.

Another vote for allowing to start all containers except the ones with scale=0 (e.g. docker-compose up --scale c1=0 --scale c2=0).

We are using this in an internal tool to start different groups on containers sequentially and as @allanlei mentions it would be quite inconvenient to specify all services to start (I don't think we actually have them currently since users can specify their own compose files). Also, I know we had some unexpected behavior in some cases using that approach (specifying the services we want to start), so it would be great if we can keep the current way.

This is currently a blocker for us to support v2 and causing some pain due to v2 being enabled by default on Mac. Any chance we can get a word on the intention to fix/support this behavior or not?

Thanks.

[rabotyaga]

We have a similar issue with groups.
Minimal reproducible scenario:
docker-compose.yml:

version: "3.4"
services:
  subset1:
    image: tianon/true
    restart: "no"
    depends_on:
      - service1
      - service2

  service1:
    image: tianon/true
    restart: "no"

  service2:
    image: tianon/true
    restart: "no"

docker-compose 1.29.2:

$ docker-compose up --scale service1=0 subset1
Creating network "docker-compose-test_default" with the default driver
Creating docker-compose-test_service2_1 ... done
Creating docker-compose-test_subset1_1  ... done
Attaching to docker-compose-test_subset1_1
docker-compose-test_subset1_1 exited with code 0
$ echo $?
0

docker-compose v2.0.0:

$ docker compose up --scale service1=0 subset1
[+] Running 3/3
 ⠿ Network docker-compose-test_default       Created                                                                                                                                                   0.1s
 ⠿ Container docker-compose-test-service2-1  Created                                                                                                                                                   0.2s
 ⠿ Container docker-compose-test-subset1-1   Created                                                                                                                                                   0.1s
Attaching to docker-compose-test-subset1-1
no containers to start
$ echo $?
1

[stale]

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.

[benesch]

This is not stale. Maintainers: gentle urge to reconsider the stale bot. What value is there in closing legitimate issues just because they haven’t seen any attention in a few months?

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.