Are there any instructions (maybe best practices) on how to upgrade docker-engine on a host that is managed by rancher?
I just logged to ask this question myself, I am guessing that you would need to add a label to the HW host something like maintenance=true and the redeploy all apps in the host with the scheduler avoiding this tag. Still seems a lot like a manual task and the docker-engine project moves very fast.
I would be interested in getting some feedback from someone in the trenches,
Best regards,
Alejandro
We are facing the same questions, regardless of having rancher or not. It is clear that there is a quite high risk that by upgrading a docker-engine, this may cause the containers to not restart properly or a certain downtime of the application. If your host is a single point of failure, meaning that you have some single service containers running on that host, you may risk the entire application to be down. At that point, if you have Rancher and proper configured health checks, your containers will be rescheduled on a new host. However for stateless containers this is just fine, but if you have stateful containers than these will not be moved, this is all in WIP in the entire docker ecosystem, unless you use flocker.
So right now we do like this:
we just do normal classic IaaS blue-green upgrades between VMs, meaning we create a new host/find an existing host, move the persistent data there (or remount a NAS volume), start a new stack on the new host(s), check that it works, deactivate the old host. lots of manual steps, sad but true.
afaik, Rancher ppl do not reply to this post, because clearly they do not yet have a solution for this.
1 Like
The deactivate action on hosts prevents new containers from being scheduled to it (and does not do anything else), so that’s basically the equivalent of the maintenance label you mention.
RancherOS releases come with a packaged version of Docker we consider stable and has its own release upgrade mechanism. For hosts created with docker-machine through Rancher, the upgrade action will eventually be added #2202. For anything else the host OS and packages installed are below the level at which Rancher is involved.
In general I would avoid Docker 1.x.0 releases, despite all the pre-release testing @ibuildthecloud does with them there are often major bugs and a quickly following 1.x.1.
Thanks for the feedback, the deactivate action option is interesting. as @demarant mentioned: This is not a problem exclusive to Rancher, but still a problem for everyone.
RancherOS releases come with a packaged version of Docker we consider stable and has its own release upgrade mechanism.
Could you point me to some docs on how this works exactly? This would be a very good excuse to try it out.