How do I manage updates of containers? We’re currently in a development phase an every time we need to update a container we need to do the following:
docker-pull.rancher-compose up with the correct configuration files.This seems a little bit tedious to say the least.
What is the correct procedure for this?
In v0.39.0 of rancher and v0.4.0 of rancher-compose, we have rancher-compose pull that allows you to pull new images to the hosts.
After you’ve pulled the new images, you can use rancher-compose upgrade to deploy a new service using the new images. http://docs.rancher.com/rancher/rancher-compose/upgrading/
Also, we have a in-service upgrade that will be coming out in an upcoming release. https://github.com/rancher/rancher/issues/1874
Modifying the compose file for a upgrade is a no no, I’m surprised anyone is using that. Wouldn’t that also break any service links?
Links to other services are re-established, but links from other services would need to manually be done.
The rancher-compose upgrade is for people who are more likely to use the different tags to differentiate versions so that they could try upgrading and if it doesn’t work, they’d be able to have the existing service to use to rollback to if needed.
Links to other services are re-established, but links from other services would need to manually be done.
Not good enough. Again, I can’t imagine a scenario where this would be useful. We keep all our configurations in github version control and changing the names of services when upgrading stuff would lead to total confusion and broken services. Especially as the links would be broken and going through every other service every time and change the links would not work in practice.
The rancher-compose upgrade is for people who are more likely to use the different tags to differentiate versions so that they could try upgrading and if it doesn’t work, they’d be able to have the existing service to use to rollback to if needed.
We want to be able to upgrade, test and possibly rollback without having to make up new service names and breaking the configuration.
This is the main issue holding us back from adopting Rancher. We would prefer a much better service upgrade story, both for development and testing as well as for production. If we need to do a hotfix for a client we need to be able to update a service in 1 minute and have everything up and running and in worst case simply rollback. We can’t run around changing multiple configurations in several steps just to make a simple hotfix.
We would be very much interested in either a better description and motivation for rancher-compose upgrade or an alternative method.