compose
compose copied to clipboard
[Feature Request] `docker compose up --scale` without side effects
Description
I originally asked this on SO without resolution, so I assume it's not possible, and hence this feature request.
Description
I have a number of services in a docker stack, where some are started manually only.
docker-compose.yml:
services:
other:
# ...
app:
# ...
depends_on:
- postgres
deploy:
replicas: 0
postgres:
# ...
deploy:
replicas: 0
pgadmin:
# ...
deploy:
replicas: 0
I can start app and postgres like this:
docker compose up -d --scale app=1 --scale postgres=1
If I then start pgadmin:
docker compose up -d --scale pgadmin=1
...it will stop app and postgres and then start pgadmin. I don't want to stop them.
I assume I can't scale a service without impacting existing services. The only reason I can imagine is the swarm reasoning: you tell compose what state you want, and it scales services to get to that state. BUT: 1) I'm not using swarm, and 2) why should that be the rule?
This is a very common use case, and the only workaround is complex hard-to-maintain scripts.
Please allow us to scale services without side effects. For example via a --scale-independently switch:
docker compose up -d --scale pgadmin=1 --scale-independently
Docker would realise that other services are already running, so that command would be equivalent to:
docker compose up -d --scale app=1 --scale postgres=1 --scale pgadmin=1
Hey @lonix1
I have a question for you, did you consider using profiles instead of setup all your services with replicas: 0 ?
Profiles were typically design for this kind of use cases, being able to start services only when you explicitly need/want
Hi @glours
I really want to use "profiles" because they are so simple. But there is a problem that makes them hard to use.
That is why I moved from profiles to scaling - but then I encountered this new difficulty (explained above).
I wonder whether it's better to use profiles (but have difficulty with docker compose down), or scaling (but have difficulty with side effects). Either approach would be fine, but both approaches have issues. :smiley:
To avoid compose up to stop your previous started services you can explicitly ask for the pgadmin service to start, like this :
> docker compose up -d --scale app=1 --scale postgres=1
[+] Building 0.0s (0/0) docker:desktop-linux
[+] Running 4/4
✔ Network issue-10965_default Created 0.0s
✔ Container issue-10965-postgres-1 Started 0.0s
✔ Container issue-10965-other-1 Started 0.0s
✔ Container issue-10965-app-1 Started 0.0s
> docker compose up -d --scale pgadmin=1 pgadmin
[+] Building 0.0s (0/0) docker:desktop-linux
[+] Running 1/1
✔ Container issue-10965-pgadmin-1 Started 0.1s
Thanks @ndeloof for the idea :wink:
Thanks! :+1: That is actually how I do it now. And it's easy when doing it once-off.
But for an automated infrastructure, that process must be scripted - and it's quite ugly and error-prone.
I think the issue most people have (in this and that linked issue) is for the non-manual use cases. Either this or that issue should be eventually addressed so we can have proper scaling or profiles without issues.
Closing this issue as scale command is now available