I’m trying to build tooling around upgrading Rancher services automatically in my CI system, then confirming/rolling back upgrades by manually triggering another CI job once I’ve confirmed the upgrade works. In general, I don’t change the rancher-compose file at all when deploying new services. I just push a new image, then bring up new services. But I’m confused about how upgrades work in rancher-compose:
If I specify -d on an upgrade action, when does rancher-compose return? I’d hoped it would at least finish the pull/upgrade operation but it looks like it may be returning immediately. I’m not seeing upgrades kicked off in the UI if I specify -d.
If I specify --confirm-upgrade/–rollback, do I also need to specify --upgrade? The examples seem to indicate I need to call --upgrade too, but I’m confused as to why confirming or rolling back a) needs to specify --upgrade at all since it’s a separate operation and b) wouldn’t automatically imply --upgrade if it was needed.
It looks like --upgrade and --force-upgrade are mutually exclusive. --upgrade only updates if you’ve changed rancher-compose/docker-compose.yml, while --force-upgrade makes the update happen regardless. Is that accurate?
rancher-compose up --upgrade --pull will upgrade services that are using old images.
I suggest using it with explicit names to avoid loosing DVC containers and/or databases .
This usually works.
rancher-compose up --upgrade --pull $service
rancher-compose up --confirm-upgrade $service
Do I need to pass --upgrade to --confirm-upgrade too? I think the docs do which is a bit confusing.
Also, is it my imagination or does none of this work with rancher-compose up -d? Trying to build a CI job that starts the upgrade, and another that confirms it. When I run the command locally, it just looks like the service is started. When I remove the -d flag then the upgrade seems to happen instead, but I can’t do that on my CI server.
This can be fraught - since the call to “rancher-compose up -d --upgrade” is non-blocking, without a secondary cli call to determine state, services can still be in a state of “upgrading” when this validation occurs; potentially validating on the prior iteration of the service if a batched upgrade is requested. What would be preferred, is if there were an option in rancher-compose to block and return only when the service reached the “upgraded” state - then perform validation, then --confirm-upgrade. As it stands, this workflow only seems possible with a secondary cli call to query the service state.
.