Proposal: Replace scale command with a scale option in the compose file

[dnephin]

From #1661 (comment)

Having both a scale command and scale configuration option leads to a scenario with unexpected results. Take this example:

Given a docker-compose.yml that defines a service web with scale: 5
Run docker-compose up -d to start 5 instances of the web service
Then run docker-compose scale web=4 to down-scale the web service.
Finally, run another docker-compose up -d.

How many instances do you expect of web? Some might say 4 because the service was scaled independently. Some might say 5 because the compose file said 5.

In the case where there are 4 instances, the value in the compose file is ignored, which is undesirable. up -d should always bring services to the state described in the compose file.

In the case where up -d scales to 5, there is no reason to have a scale command at all. up -d is already handling scale. With the new file overrides a user could even set the scale numbers in a scale.yml, and run docker-compose -f docker-compose.yml -f scale.yml, which supports keeping scale separate from application configuration.

This proposal is to deprecate the scale command (add a removal warning for 1 or 2 releases, before finally removing it), and instead use up -d to scale a service.

Update

To handle the case of overriding the scale number from the command line, up can use the service=count syntax that is currently available to scale (#1661 (comment)).

[nazar-pc]

👍 Completely agree with proposal.

[schickling]

Sounds good! 👍

[migueleliasweb]

👍

[megastef]

+1

[ahfeel]

+1

[RobMaskell]

How abut having a minimum number of instances to scale in the docker-compose.yml and leave the scale command as it is, an override? That would seem to handle all the use cases people have proposed and what to do when the two different ways of scaling conflict.

[nazar-pc]

Why might you need scale command if you can just do docker-compose up -d?

[RobMaskell]

It leaves the value in the docker-compose.yml as declarative there should be a minimum of 3, and if there should be a minimum of three the docker-compose scale 2 would be bad and stopping someone from doing that might be a good thing

[nazar-pc]

This proposal is about removing scale command and introduce option instead, so you'll not be able to do docker-compose scale whatever=2. I do not understand your comments in this context.

[RobMaskell]

Context is that I disagree with removing scale, I like the fact that I can scale without having to first edit a file (sucks for automation) and that the command will not have unintended side-effects (me or someone else edits another part of the docker-compose and forgets about it) that could happen from a docker-compose up -d

But I like the idea (need) of starting more than one of a thing from the docker-compose.yml. Just my opinion though either way works for my actual problem.

[arun-gupta]

scale option allows to dynamically add/remove new instances as opposed to static number in the file. If the option is removed, how would the services be scaled in that case?

[kluen]

What about a parameter to set/override arbitrary options declared or missing in the yml file?

Given the following docker-compose.yml:

something:
    image: someimage
    scale: 5

You could run docker-compose up -d --set something.scale=3 or something similar.

Could be nice for automation as well, because you can override anything without using environment variables.

[nazar-pc]

Compose is stateless tool, option in yml file is intentionally suggested to avoid ambiguous behavior.

[kluen]

What I was suggesting is still meant to be stateless. Calling docker-compose up -d afterwards would restore the 5 instances.

I was trying to find a solution for arun-guptas concerns. I like the proposal, but it would remove the ability to scale services without having to edit a file. I guess you could work around this, but it makes automation unnecessarily cumbersome.

On a second thought, you could always work around this limitation with environment variables.

[pdevine]

Without the scale command, I'm not sure how you're supposed to run a service that needs to be scaled dynamically. Just thinking off the top of my head, but maybe there needs to be some way of storing intermediate state which can dump out a new compose yaml file with the correct scale values? That way we can keep the scale command but don't have the ambiguity of dynamic data.

[fesor]

Currently scale command is also used in deployment process to replace container with new versions of it. I prepared a small example which is illustrate the process. You can also see swap shell script, which is relies on scale command.

[moremagic]

👍

[mattgiles]

👍

[steven-sheehy]

I think the scale should be in docker-compose.yml since it is application configuration. However, I think it should be expanded so that it is a range like:

scale: 3-10

The above states that the application should start with 3 but can scale up to 10. That way the compose files specifies the allowed range and the command line specifies the current instance count. Whenever the container is brought up or restarted it would be set to the minimum configured. Anything set via command line is temporary and validated to be within that range. This makes sense since compose is a stateless tool so the previously set command line option would be lost on restart. This would allow for future enhancements with auto-scaling based upon load or other criteria. Using a min and max is how some PaaS providers scale like OpenShift: https://developers.openshift.com/managing-your-applications/scaling.html

[muhqu]

@steven-sheehy or…

scale:
  min: 3
  max: 10

[ncoghlan]

Coming over from the discussion on #1896, +1 for treating the contents of the compose file as a constraint on the scaling, rather than as the main interface for setting the current scaling level.

docker-compose up -d would bring the number of components up to the minimum if that wasn't already the case, but otherwise leave the scaling alone.

docker-compose scale would change to reject attempts to lower the scaling below the minimum, or above the maximum (perhaps with a --force option to make it easier to test failure conditions and search for scaling constraints in other parts of the system)

The default constraints would then be a minimum scale of 1, and no maximum scale.

[luckydonald]

How about setting a default value, you can still override with scale?
Continuing where @muhqu #2496 (comment) left of:

scale:
  min: 3
  max: 10
  default: 5

So mainly I want

scale:
  default: 5

Or written in short:

scale: 5

I use docker-compose.yml to make deploying a one-liner.

But

docker-compose up
docker-compose scale foo=2 bar=42 whatever=4458

is no one-liner no more, and I am required to write a Makefile again.

The problem here seems to be more a interpretation issue, and calling it default scale would remove that ambiguity.

[alwaysastudent]

Proposal is good. We at least need an option to initialize the number of instance per service. Please give us this.

[mschwartz]

Scale in the yml file should be a default or initial value.

If it's scale: 3, the 3 are started. If I use the command line option 6, then 6 is how many should be started.

If the server reboots, the last number of containers would start.

If I'm developing, I want to stop them all and docker-compose up, 3 as the yml says.

[luckydonald]

Adding to my last proposal (above):

While I included a min/ max value, as we had that in the discussion, I don't think that restricting users is good idea. This would only make sense with scaling, but this should be another issue, after this is implemented.

Still a default option for initial starting docker-compose up is needed:

• first ever deployment (new machine, new project,...)
• starting after a docker-compose down

Quoting the README:

Then, using a single command, you create and start all the services from your configuration.
[...] Compose will start and run your entire app.

[alwaysastudent]

^ the need for a default nimber of replicas is a no brainer.

[shin-]

Implemented in #4742

[luckydonald]

@shin- but this forces a scale?
I.e. you can't change it with docker-compose scale serviceABC=4
This issue discussion has come to the point that having a default value on startup is needed.
I think restricting your deployment to manually editing the docker-compose.yml file every time you want to scale is a step back.

[luckydonald]

Also see the comment a year ago

[shin-]

@luckydonald You can use docker-compose --scale serviceABC=4 up to the same effect.

[luckydonald]

@shin- Oh, great, thanks.
If I now reboot the server, what will be the scale? 4 or the value in the compose file (e.g. 3)?

[shin-]

Assuming restart_policy: always is set on your service, all 4 containers should restart, so the scale should be preserved.

[mschwartz]

IMO, it should retain the last scale, regardless of the scale value in the compose file. The compose file should indicate the starting number, but if you manually change scale, the assumption is you really mean to change scale until further change.

[boscowitch]

I cant find an argument against an option.. imagen your deploy system repulling the whole project and rebuilding everything... now all scaling is lost, worst case the system overloads ... so why not add a minimum default in the docker-compose since there are a lot of worker scenarious that should have more than 1 from the simplest small scaled project there is

[rikkigouda]

+1