# Upgrading services with rancher-compose **URL:** \ **Category:** Rancher 1.x\ **Created:** [April 27, 2016, 6:56pm UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618 "2016-04-27T18:56:04Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![nolan](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@nolan](https://forums.suse.com/u/nolan)\ **Post date:** [April 27, 2016, 6:56pm UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618/1 "2016-04-27T18:56:04Z")
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? Thanks. ---
**Author:** ![mishak](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/mishak/32/412_2.png) [@mishak](https://forums.suse.com/u/mishak)\ **Post date:** [May 2, 2016, 2:48pm UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618/2 "2016-05-02T14:48:58Z")
`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. ```auto rancher-compose up --upgrade --pull $service rancher-compose up --confirm-upgrade $service ``` ---
**Author:** ![nolan](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@nolan](https://forums.suse.com/u/nolan)\ **Post date:** [May 5, 2016, 12:05pm UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618/3 "2016-05-05T12:05:40Z")
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. Thanks. ---
**Author:** ![hwaastad](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/hwaastad/32/225_2.png) [@hwaastad](https://forums.suse.com/u/hwaastad)\ **Post date:** [May 6, 2016, 7:18am UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618/4 "2016-05-06T07:18:59Z")
I’m running the following in my gocd auto deployment: up -u --force-upgrade -p -c -d I need to wait to make sure deployment is OK before running performance tests. works for me 🙂 /hw ---
**Author:** ![Jonathan\_Baker](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@Jonathan\_Baker](https://forums.suse.com/u/Jonathan_Baker)\ **Post date:** [November 2, 2017, 4:05pm UTC](https://forums.suse.com/t/upgrading-services-with-rancher-compose/2618/5 "2017-11-02T16:05:41Z")
> [@hwaastad](#): > > I need to wait to make sure deployment is OK before running performance tests. 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.