Docker has taken the software world by storm. Since its introduction about 6 years ago, it’s quickly become the de-facto standard for containerized applications. Using proven and battle-tested technologies that have been present in the Linux kernel for a number of years, Docker has enabled application developers to write applications in a way that is more scalable, easy to maintain and even easier to setup than ever before.
With Docker containers being the platform of choice to run containers, it is likely there are at least several applications in organizations running as Docker containers. Your team is probably using Docker CE to run these containers.
As organizations move more and more workloads to a container-based solution, they may hit some of the limitations of Docker CE. The following are a few items that need to be addressed:
Should all teams and all team-members have full control over all running containers?
What would happen if a junior developer accidentally restarts the production ERP services?
How do we prevent a piece of code with a critical security vulnerability from being pushed to production?
How can we be sure that the container images we use come directly from our developers and have not been tampered with?
Can we provide proof to external auditors to show that we are compliant with the prerequisite security standards?
How do we monitor and backup our entire platform configuration?
The answer to these problems is Docker EE. While other (supported) container orchestration platforms exist, Docker EE provides three important key features: Choice, Agility and Security.
With Docker EE, you have the choice to run any type of container workload (Kubernetes or Swarm),on any type of platform (Linux, Windows and even mainframe) and on any infrastructure (on-premises data center, public clouds or a combination). The agility, scalability, and the ease of deployment functionality Docker provides, coupled with integrated security scanning and automation tools enable you to not only prove to auditors or higher management that everything is running smoothly and securely, it also enables you to build CI/CD pipelines that automates much of that security work.
In this series of posts, we’ll demonstrate how you can upgrade your existing Docker CE environment to Docker EE without having to redeploy running services and applications. We’ll start with a set of servers running Docker CE engine using Docker Swarm, upgrade the engine to Docker EE, and then install UCP and DTR — the two major enterprise tools that are built on top of the Docker EE Engine.
Starting with Docker CE
This post will follow a company called MyCorp as they upgrade their Docker CE installation. MyCorp currently has a 7 node setup with 3 managers nodes (manager-0 to manager-3), and 4 worker nodes (node-0 to node-3). All nodes run the current version of Docker CE (18.09.2) and are clustered in a swarm.
As per best practices, the manager nodes don’t run any workload.
[centos@manager-0 ~]$ docker node lsID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE Vpj5r… * manager-0 Ready Drain Leader 18.09.2yg3o… manager-1 Ready Drain Reachable 18.09.2m3g9… manager-2 Ready Drain Reachable 18.09.2cfdj… node-0 Ready Active 18.09.2i4oj… node-1 Ready Active 18.09.2wia1… node-2 Ready Active 18.09.2u32e… node-3 Ready Active 18.09.2We start a service called myweb, that consists of four replicas of the nginx image. We’re also running a myweb-staging service with 2 replicas. Our production myweb app uses port 8000, our staging app uses port 8080.
[centos@manager-0 ~]$ docker service create — name myweb — replicas 4 -p 8000:80 nginxufura4wtqcdb7c5kodvio4uy2overall progress: 4 out of 4 tasks1/4: running [==================================================>]2/4: running [==================================================>]3/4: running [==================================================>]4/4: running [==================================================>]verify: Service converged[centos@manager-0 ~]$ docker service create — name myweb-staging — replicas 2 -p 8080:80 nginx96nxcao6z8f98fxrp8munk6svoverall progress: 2 out of 2 tasks1/2: running [==================================================>]2/2: running [==================================================>]verify: Service convergedWe can now verify that our two apps are reachable from the outside world. Our production app is running on port 8000, our staging application is running on port 8080.
Ending with Docker EE
We will now upgrade our Docker engines to the Docker EE engines.
In the past, to upgrade from Docker CE to EE, you had to add the new repository to your system, remove the old docker package, then install the new package. More or less, you have to follow the same procedure to upgrade your Docker version.
Starting with Docker 18.09, that’s no longer needed. You can now upgrade and license them without having to remove old packages and install new ones.
In our example, we’ll start by upgrading node-3 to Docker EE. Strictly speaking, while it is not needed, it’s best practice to “drain” the node first. This will remove all docker workloads from the node and signal Swarm that we’re not ready to accept new workloads.
[centos@manager-0 ~]$ docker node update — availability drain node-3node-3[centos@manager-0 ~]$ docker service ps mywebID NAME IMAGE NODE DESIRED STATE CURRENT STATE6tkdj967vfg5 myweb.1 nginx:latest node-0 Running Running 12 minutes ago0cwqoi4mqgz2 myweb.2 nginx:latest node-1 Running Running 12 minutes agovuygt5d5fpvz myweb.3 nginx:latest node-2 Running Running 12 minutes agoj2zef1894f5x myweb.4 nginx:latest node-2 Running Running 9 seconds ago410vht69jojz \_ myweb.4 nginx:latest node-3 Shutdown Shutdown 10 seconds agoAs you can see in the output of the last command, the replica of our myweb service that was running on node-3, has been moved to a different node, node-2 in this example. Our node-3 is now empty.
Activating our Docker EE license on one worker node
The first thing we need to do after logging in to our node-3, is to login to the Docker Hub. Because of the way the engine activation works, we have to use “sudo” when doing so:
[centos@node-3 ~]$ sudo docker loginLogin with your Docker ID to push and pull images from Docker Hub. If you don’t have a Docker ID, head over to https://hub.docker.comto create one.
Username: YOUR_HUB_USERNAME
Password:
We can now activate our license:
[centos@node-3 ~]$ sudo docker engine activateLooking for existing licenses for YOUR_HUB_USERNAME…NUM OWNER PRODUCT ID EXPIRES PRICING COMPONENTS0 yourcompanyname docker-ee 2020–01–23 17:17:21 +0000 UTC Linux (x86–64) Nodes:10Please pick a license by number: 0License: Quantity: 10 Nodes Expiration date: 2020–01–24 License is currently active…After restarting the Docker service, our new license is active on our node-3 server.
[centos@node-3 ~]$ sudo systemctl restart docker[centos@node-3 ~]$ docker versionClient:Version: 18.09.2API version: 1.39Go version: go1.10.6Git commit: 6247962Built: Sun Feb 10 04:13:27 2019OS/Arch: linux/amd64Experimental: falseServer: Docker Engine — EnterpriseEngine:Version: 18.09.2API version: 1.39 (minimum version 1.12)Go version: go1.10.6Git commit: 1ac774dBuilt: Sun Feb 10 03:43:47 2019OS/Arch: linux/amd64Experimental: falseWe can now safely re-enable our node-3 in the Swarm cluster:[centos@manager-0 ~]$ docker node update — availability active node-3node-3Active Docker EE on all nodes
By performing the exact same procedure for all our nodes, we’ve now added the Docker EE license to all existing nodes in our cluster.
Adjusting the repositories
We’ve now successfully upgraded all servers in our cluster from Docker CE to Docker EE. All our services are still online, nothing went down, everything kept working.
To enable our nodes to automatically upgrade using the default package management tools that our operating systems support, we still have to update the packages using the instructions that can be found on the Docker Docs website. In our example we’re using CentOS Linux distribution, so we will follow the steps at https://docs.docker.com/install/linux/docker-ee/centos/to add the yum repositories.
Conclusion: Easy upgrade path, everything still running
We can verify that our app services are still running the same way as they were before the upgrade process. The only thing that has happened is that all replicas restarted one at a time, because we “drained” the nodes before upgrading them. But, we didn’t have to redeploy, Swarm kept our desired number of replicas online, there was no application downtime!
Now that we’ve upgraded our engine to Docker EE, we can install and explore the additional software components that make up the Docker EE product offering. In our next post, we will install Docker Universal Control Plane and we will conclude the series by installing Docker Trusted Registry.
ABOUT THE AUTHOR
Bill Weissborn is a Docker Certified Associate and Docker Accredited Instructor for Stone Door Group, a DevOps solutions integrator, and team lead for their Docker Accelerator℠ solutions. Accelerator solutions take all the guesswork out of the DevOps journey with simple to understand and easy to quantify results. Stone Door Group helps enterprises of all sizes execute on their digital transformation projects. To learn more about Stone Door Group, drop us a line: letsdothis@stonedoorgroup.com.