In PART I of this series, we started the process of upgrading existing Docker Community Edition instances to Docker Enterprise Edition. We followed an example company, MyCorp, in their upgrade journey from Docker CE cluster to Docker EE’s engine. Docker EE makes it even easier for organizations to get critical applications into production with full stack portability across any infrastructure from CE to EE without breaking the seamless workflow between development and operations. As we experienced, the transition from Docker CE to Docker EE was smooth and seamless with all services.
DTR is Docker’s Registry solution. It will host your organization’s images in a secure and cloud-ready way. Besides traditional storage, the DTR allows you to store images in various object-store engines, such as Amazon S3. It adds digitally signed images, image automation, fine-grained access control and security scanning.
We’ll install Docker DTR in part III of this series. In this post however, we’ll focus on the other component that’s included with Docker EE: Docker’s UCP
UCP adds enterprise tooling on top of Docker Engine. It allows you to manage all your containerized workloads, on Kubernetes or Docker Swarm, on Windows or Linux from a single UI or API. It adds an advanced RBAC-based user management system — compatible with LDAP and Active Directory — and integrates with registry solutions such as the DTR. UCP also includes additional tooling to make your “Day 2” tasks such as backup-procedures, monitoring and alerting easier.
For more information about the features UCP will give you, visit https://docs.docker.com/ee/.
In the PART I, we started with a Docker CE cluster consisting of 3 manager nodes and 4 workers. We then upgraded our Docker Engine from CE to EE, without having to redeploy our services and without any downtime. As UCP is a Docker Swarm application in itself, installation is easy.
In our previous example, we didn’t want to run any workloads on our manager nodes by draining the master nodes. This is considered to be a best practice, but will prevent our UCP components from installing, as those have to run on manager nodes.
So, in this case, the first thing to do is re-enable our manager nodes by issuing the following commands:
[centos@manager-0 ~]$ docker node update — availability active manager-0
[centos@manager-0 ~]$ docker node update — availability active manager-1
[centos@manager-0 ~]$ docker node update — availability active manager-2
Later on, we can tell UCP we don’t want to run regular workloads on our ucp-managers.
To install UCP, we issue the following command from one of our manager nodes:
[centos@manager-0 ~]$ docker container run — rm -it \
> — name ucp \
> -v /var/run/docker.sock:/var/run/docker.sock \
> docker/ucp \
This command takes a while and will perform these actions behind the scenes:
It will download UCP and all its components.
It will download and setup an HA Kubernetes cluster,
It will initiate distributed databases for the configuration etc. This would be a good time to grab a cup of coffee, go out for a quick walk around the office or to read up on the three advantages that Docker has over other container orchestration solutions: Freedom of Choice, Agile Operationsand Integrated Container Security.
At the end of the install process, the installer will print out the https URL and the random generated password for the admin account.
When we navigate to that url and login with the admin account, we are greeted by UCP’s dashboard. When navigating to “Shared Resources” -> “Nodes”, you’ll see all our nodes have been added, and our existing services (“myweb” and “myweb-staging”) are still running. We didn’t have to re-deploy them as they never went down!
In our example, we setup two services: one running 4 replicas of our production website, and another one running two copies of our staging site. At this point, they are running next to each other and the only user on our system (Admin) can manage everything. For the next step, let’s add some security.
Using the documentation available at https://docs.docker.com/ee/ucp/authorization/ee-advanced/, we created an organization called “mycorp”, which has a team “QA” and a team “Dev”. Tom is a member of the Dev team, and he’s allowed to deploy our staging Staging application. Jane is a member of the QA team, she’s allowed to deploy to production. To implement that requirement, we’ve created a Collection called MyCorp with two subcollections (Staging and Production), and added the myweb-staging service to de Mycorp/Staging collection, and the myweb service to the MyCorp/Production collection.
We create a grant giving the QA team full control over the Production collection and read-only access to the Staging collection, and granting the Dev team full control over the Staging collection.
If we then logout as admin and log back in as Jane, we notice that while she can see both services, she can’t change or control the staging app even when she restarts the myweb service. When logging in as Tom, he can only see the staging service and associated containers.
We’ve now seen how easy it is to install UCP on top of an existing Docker Swarm, without having to redeploy existing applications. We’ve also see how we can add organisations, groups and users, and define access rights for each group or user. Now of course, there’s a lot more to know and learn about UCP, such as the Kubernetes subsystem, integration with Active Directory, load-balancing, Layer 7 routing etc. You can see from this post that it is easy to start with an existing Docker CE installation, upgrade to Docker EE and add UCP on top of that.
ABOUT THE AUTHOR
Frank Louwers is a Hybrid Cloud Architect at the Stone Door Group, a Cloud and DevOps consulting company 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. To learn more, drop us an email at email@example.com.