This is the 3rd and final blog in a series that describes how to upgrade your Docker Community Edition to Enterprise Edition. If you are playing catch up, you can read here to learn more about why you should upgrade. In part I of this series, we demonstrated how to updated your existing Docker CE to EE in place. In part II, we demonstrated how to setup Universal Control Plane (UCP). To date, we've shown how easy it is to upgrade an existing Docker CE installation to Docker EE and to install UCP on top of that to give you an enterprise orchestration platform with the freedom to choose your orchestrator (Kubernetes or Swarm), your operating platform (Linux or Windows) and your infrastructure (on-premises, in the cloud of your choice, or a combination of both). We've started to touch on the security aspects by introducing the Role Based Access Control concepts of Teams, Collections, Grants and Roles.
The entire upgrade process (CE engine to EE engine to UCP) went smoothly without the need to redeploy our existing services and without any downtime.
One final step remains: integrating the Docker Trusted Registry (DTR) in all of this.
DTR is a container image repository that integrates with the role-based access control (RBAC) system defined in UCP. It allows your team members to digitally sign images on upload, allows you to verify those signatures when starting a container, and allows you to configure UCP in such a way that someone from the QA team must sign an image before it can be deployed to Production, for instance. It also includes a security scanning mechanism to make sure there are no known vulnerabilities in components used by our images, and ties that to a powerful automation engine. The DTR enables you to store images on cloud-storage.
Installing the DTR
For production environments, we recommend setting up three replicas of the DTR, on dedicated nodes to provide high-availability and to allow the security scanning engines to have enough available resources. However in our example we'll deploy a single replica of the DTR on node-3.
Make sure there are no services that use port 80 or 443 on the nodes that will run the DTR replicas, as those would conflict with our DTR installation. It is of course possible to run the DTR on different ports, but that's outside the scope of this demo.
When logged in as admin in the UCP, navigate to "Admin Settings" -> Docker Trusted Registry , select node-3 in the UCP Node drop-down and check the flag to Disable TLS verification - as this is a demo and we didn't create real certificates for UCP. Also make sure you add the public ip address of your node-3 in the box at the top, to tell the DTR which URL we'll use to access it. In a real life scenario, this might be an external load-balancer sitting in from of the DTR. Copy the installation commands at the bottom of the page. Login using ssh to a manager node, and run the command there. In our example:
[centos@manager-0 ~]$ docker run -it --rm docker/dtr install \> --ucp-node node-3 \> --ucp-username admin \> --ucp-url https://your.manager0.ip.address \> --dtr-external-url https://your.node-3.ip-address \> --ucp-insecure-tls
The installer script will prompt for the existing admin password for the UCP, so make sure you that one handy. This takes a couple of minutes, so watch this cool Demo on how to integrate CI/CD pipelines in DTR: Demo Webinar: Integrating CI/CD with Docker Enterprise Edition https://www.youtube.com/watch?v=gHlRpZJ768U
When the installation has finished, we can now access the DTR web interface using https://your.manager0.ip.address/ The DTR uses the UCP to provide Single Sign On mechanisms, so you'll be redirected to UCP to login.
After you've logged in with your UCP credentials, you'll be presented with the Repositories overview screen of the DTR. When navigating to "Organisations" in the menu bar on the left, you'll see that our DTR installation recognises the groups, teams and users we've created earlier.
Click on System in the menu bar, and you'll notice multiple options to configure the DTR: from defining your backend storage mechanism (Docker Volumes, NFS, Cloud storage systems), over garbage collection jobs, to Security. If you flip the "Enable Scanning" switch on the Security page and confirm you want to enable security scanning, the DTR will download a list of known components with security problems. This will take some time, as the database is quite large. By default the DTR will update this database every night. The differences with the old version will be downloaded, so the large database is only downloaded once.
Setting up Automation
As an admin, create a repository "mycorp/myapp-dev", and grant the Dev team read-write access to this repository. On the Settings page of the myapp-dev repository, configure "Scan on Push" for this repository. Every time a new image is uploaded to the mycorp/myapp-dev repository, it will automatically be scanned for known vulnerabilities. Also create a "mycorp/myapp-qa" repository, grant the QA team read-write access to this repo.
We want to add some automation to our installation. If a developer uploads a new image with the "myapp-dev:qa" tag, we want to promote (copy) that image to the myapp-qa repository if it contains no known critical vulnerabilities. The copied image should have a :candidate-$date tag.
To implement this, we define a Promotion policy on the myapp-dev repository as shown in the screenshot below.
Using the DTR on our workstation
We want to be able to use the DTR without having to login to one of the nodes in our cluster, on our local workstation. I am working on a Mac and have Docker Desktop for Mac installed on my machine. This means I have everything I need on my system. There's just one final step: my workstation needs to trust the DTR CA certificate. The procedure to do this depends on the operations system you're using. You can find the instructions for your environment here: https://docs.docker.com/ee/dtr/user/access-dtr/. In this case, I had to navigate to the /ca url on the DTR, import the certificate in my Mac's Keychain, and restart Docker Desktop for Mac.
This allows me to login to the DTR using the following commands:
~ ❯❯❯ docker login node-3.ip.addressUsername: tomPassword: Login Succeeded
Please note I used the "tom" user, as that user belongs to the Dev team.
Create a new folder called Demo, and create a Dockerfile with the following content in that folder.
FROM alpine:2.7Build the image (based on the Alpine v2.7 base image) with the following commands:
docker image build -t node-3.ip.address/mycorp/myapp-dev:qa Push the image to the DTR:
docker image push node-3.ip.address/mycorp/myapp-dev:qa
If you navigate to the mycorp/myapp-dev repository in the DTR's web UI, you'll notice that an image with the myapp-dev:qa has been uploaded by user "tom", and that a security scan is being executed.
After some time, the security scan has been executed, and should report a vulnerability. Verify that the image has not been copied (promoted in Docker speak) to the myapp-qa repository, as it contains at least one Critical security vulnerability.
Fix the security issues by changing your Dockerfile to use alpine:latest as the base image. Rebuild and push the image, using the same commands as you used above. When refreshing the DTR's UI, you'll notice a new scan has been triggered on our new version of the image. This scan should report no Critical vulnerabilities. When navigating to the mycorp/myapp-qa repository, you'll notice that the same image is now available in that repository with a new tag.
Conclusion
Now there's a lot more you can do with the DTR, but with this demo, we wanted to show you how it integrates with UCP's user access system, how you can scan all images for known vulnerabilities, and use automation tools to promote images based on a number of criteria.
In this series of blog posts, we started by examining the extra advantages Docker EE has over Docker CE and over other container orchestration platform (Choice, Agility and Security), we showed you how you can upgrade from Docker CE to Docker EE without downtime or having to redeploy. We then installed UCP on top of Docker EE Engine, and implemented simple RBAC based access mechanism. In this last blogpost, we looked at the DTR and focussed on some of the Security and Automation features it offers.
Next Steps - Try Docker Enterprise Edition for Free
We hope that this series of posts will show you that migration from Docker CE to Docker EE can be a seamless and smooth process. If you want to take your existing Docker setup to the next level and find out more about Docker EE, reach out to our engineers. We'd be happy to have a chat about our experiences with migrations.
If you are looking to test drive Docker Enterprise Edition first, click here and we will set you up with a free 5 day trial of the architecture described in this series of posts!
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.