docker-rollout icon indicating copy to clipboard operation
docker-rollout copied to clipboard

Feature Request: Rollout the whole stack

Open DomiiBunn opened this issue 8 months ago • 2 comments

Hia.

It would be great for support to be added for large CI stacks where it's not efficient to have a seperate rollout command for each microservice contained within a single compose file.

Thus it would be extreamly helpfull to support the same behavoiour as docker compose where not providing a service just re-creates all the containers that have a newer version avilable.

I'm not sure how viable this is as I did not get into the code of the project 🙈 but it would be an amaizing feature if you'd ask me

DomiiBunn avatar Apr 17 '25 15:04 DomiiBunn

Hi, I've considered implementing that behavior, but it has a few problems:

  • Not all services can be updated with docker-rollout, e.g. services having a port mapping or container_name defined. Docker rollout can't start another instance of the same service, and will fail.
  • Not all services should be updated with docker-rollout, especially stateful services that should not have two instances running (databases)

docker compose up is safe for the above cases because it will remove the container before creating another one.

I think a good approach to your problem would be creating a script to update all services like this:

#!/bin/bash
docker compose up service1 service2
docker rollout service3
docker rollout service4

or if you want to run them at the same time (output might be confusing tho):

#!/bin/bash
docker compose up service1 service2 &
docker rollout service3 &
docker rollout service4 &
wait

Would you mind describing your use case in more detail, so I have more info on how the project is used?

wowu avatar Apr 23 '25 17:04 wowu

As a simple solution add an enable label?

If no service is specified and the compose file has services with rollout-enable=true it'll roll out said services.

Also. I think a default fallback of "just recreate it" like standard compose would be acceptable when a failure occurs due to a pre good port/container name.

The main use case for me is a rolling deployment of a bunch of micro services that are contained within a bunch of nested compose files.

Switching to k8s is a debate in process but I think it's a nice addition to the project

  • I think if it had such support it could be included in base if dockge (there is already an issue requesting it under it's gh) and a label would allow an explicit want to preform a rolling update rather than a recreate.

But again. I did not have the time to look at the code of the project so if it's something that's out of scope I won't complain if the issues is closed as a no-resolve

Edit: sorry for the broken English. Catching up on notifications and falling asleep

DomiiBunn avatar Apr 24 '25 00:04 DomiiBunn