Docker.github.io: Upgrade policy and procedure for Docker

Created on 22 Mar 2017 · 3Comments · Source: docker/docker.github.io

I tried searching the docs on how to upgrade Docker for each of the distributions we support, but I couldn't find anything.

Some users will be able to upgrade on their own, and if you don't care about downtime for your applications, you can pretty much upgrade/downgrade by uninstalling and installing the version you want.

What I'm searching for is:

What is our upgrade policy. Can I skip patches, minor, and major versions and jump directly to the version I want, or do I need to to intermediary upgrades? Take a look at this page to see what I mean
What is the upgrade process. This might seem obvious, but it's not. Can I upgrade all nodes at the same time or do I need to upgrade managers one by one and give them time to come up before upgrading the next one?

Who cares about this?

I would say that anyone trying to run Docker in production cares about it. More specifically if you're running Docker EE standard/advanced this is really critical.

Since UCP only supports specific Docker versions, when teaching how to upgrade UCP we tell users to start by upgrading Docker, but there's no guidance on how to do this.

areEngine areEnterprise

Source

joaofnfernandes

Most helpful comment

@thaJeztah, @andrewhsu do we have any guidelines in terms of upgrade policy for the engine? As an example can I skip versions when upgrading (e.g. 17.03 -> 18.x), or do I need to upgrade incrementally?

See what we have for DTR

joaofnfernandes on 12 Oct 2017

👍3

All 3 comments

The swarm mode upgrade document is also needed. In the swarm mode cluster, cluster states be managed by nodes. How to keep the states while docker upgrading.

Thanks @thaJeztah for some upgrade suggestions:

The recommended approach is to first upgrade manager nodes (one at a time, so that you don't loose quorum); after manager nodes are upgraded, upgrade your worker nodes.

Depending on your situation, you may want to drain nodes before upgrading (docker node update --availability=drain ..), which will stop the tasks on that node, and re-deploy them to another node in the cluster (assuming there's enough resources to deploy the tasks elsewhere). After upgrading, you can make the node available again (--availability=active)