During the second day at Dockercon EU 2015 in Barcelona, Docker introduced the missing glue which they call "Containers as a Service Platform". With both focus on public cloud and on-premise, this is a great addition to the eco system. For this blogpost I would like to focus on the Run part of the "Build-Ship-Run" thought of Docker, and with the focus on on-premise. To realize this, Docker launched the Docker Universal Control Plane which was the project formerly known as Orca.
I got to play with version 0.4.0 of the software during a hands-on lab and I will try to summarize what I’ve learned.
Of course the installation is done by launching Docker containers on one or more hosts, so you will need to provision your hosts with the Docker Engine. After that you can launch a
orca-bootstrap container to install, uninstall, or add an Orca controller. The orca-bootstrap script will generate a Swarm Root CA, Orca Root CA, deploy the necessary Orca containers (I will talk more about this in the next section), after which you can login into the Docker Universal Control Plane. Adding a second Orca controller is as simple as running orca-bootstrap with a join parameter and specifying the existing Orca controller.
Let’s talk a bit about the technical parts and keep in mind that I’m not the creator of this product. There are 7 containers running after you have succesfully run the orca-bootstrap installer. You have the Orca controller itself, listening on port 443, which is your main entry point to Docker UCP. There are 2 cfssl containers, one for Orca CA and one for Swarm CA. Then you have the Swarm containers (Manager and Agent) and the key-value store, for which Docker chose etcd. Finally, there is an orca-proxy container, whose port 12376 redirects to the Swarm Manager. I’m not sure why this is yet, maybe we will find out in the beta.
From the frontend (which we will discuss next) you can download a ‘bundle’, which is a zip file containing the TLS parts and a sourceable environment file containing:
<h1>Run this command from within this directory to configure your shell:</h1>
<h1>This admin cert will also work directly against Swarm and the individual</h1>
<h1>engine proxies for troubleshooting. After sourcing this env file, use</h1>
<h1>"docker info" to discover the location of Swarm managers and engines.</h1>
<h1>and use the --host option to override $DOCKER_HOST
As you can see, it also works directly against Swarm manager and Engine to troubleshoot. Running
docker version with this environment returns:
API version: 1.21
Go version: go1.4.2
Git commit: 76d6bc9
Built: Tue Nov 3 17:43:42 UTC 2015
API version: 1.21
Go version: go1.5
Git commit: 56afff6
Okay, so when I opened up the frontend it looked pretty familiar and I was trying to remember where I’ve seen this before. After a look at the source, I found an ng-app parameter in the html tag named shipyard. The GUI is based on the Shipyard project, which is cool because this was an already well functioning management tool built upon Docker Swarm and the Docker API, so people familiar with shipyard already know the functionality, so let me quickly sum up what it can do and wthat it looks like in Docker UCP.
Application expanded, quickly start/stop/restart/destroy/inspect running container
Application overview, graphs of resource usage and container IDs can be included or excluded from the graph.
Containers overview, multi select containers and execute actions
Ability to quickly inspect logs
Ability to exec into the container to debug/troubleshoot etc.
Secrets Management & Authentication/Authorization
So, in this hands-on lab there were a a few things that were not ready yet. Eventually it will be possible to hook up Docker UCP to an existing LDAP directory but I was not able to test this yet. Once fully implemented you can hook it up to your existing RBAC system and give teams the authorization they need.
There was also a demo showing off a secret management tool, which also was not yet available. I guess this is what the key-value store is used for as well. Basically you can store a secret at a path such a secret/prod/redis and then access it by running a container with a label like:
docker run -ti --rm -label com.docker.secret.scope=secret/prod
Now you can access the secret within the container in the file /secret/prod/redis.
A lot of the new things are being added to the ecosystem, which is certainly going to help the adoption of Docker for some customers and bringing it into production. I like that Docker thought of the on-premise customers and deliver them an equally as the cloud users. As this is an early version they need feedback from users, so if you are able to test it, please do so in order to make it a better product. They said they are already working on multi-tenancy for instance, but no timelines were given.
If you would like to sign up for the beta of Docker Universal Control Plane, you can sign up at this page: https://www.docker.com/try-ducp