Docker Enterprise Standard or Docker Enterprise Advanced

(Posted by Sacha Oltmans) Docker has just rebranded their products. Docker Community Edition are their unsupported, free to use products, and Docker Enterprise Edition are their supported, paid-for products. Docker Enterprise Edition starts with Docker Engine that is tested and certified to run on specific platforms (OS), called Docker Enterprise Basic, then adds Docker Trusted Registry and Universal Control Plane (Docker DataCenter) and secrets management. This is called Docker Enterprise Standard.
On top of Docker Enterprise Standard, image scanning for DTR is added. This product is called Docker Enterprise Advanced.

What I really like in Docker DataCenter are two things:

1. HTTP Routing Mesh, and
2. Secrets management

HTTP Routing Mesh

HTTP Routing Mesh is very useful. As you know, both Services and Containers expose a fixed port. A Docker Service is in fact a scale set consisting of a fixed number of containers: Tasks. Swarm publishes the Service port(s) port at each node a Task runs on, so you can loadbalance across these nodes to access a Service. Swarm then routes incoming calls underwater to available Tasks.

This is nice, but it means you have to do some kind of translation between the application or service you’re running (URL), and the port that it actually services requests. Your loadbalancer can do this, you have to set up a loadbalancer rule for every application. This for example translates to port 9000.

But you have to keep track of each port you assign, to prevent clashes, and have to set up loadbalancer rules, even though Swarm does its own loadbalancing.

Is there an easier way? Yes! HTTP Routing Mesh takes care of translating URLs to Service ports. And it’s really, really easy to use. You just assign the network ‘ucp-hrm’ to the Service and tell Docker what the URL is that your application should listen to, and then Docker will translate calls to that URL to whatever port your Service is listening on. You don’t need to keep track of which port your Service uses, because Docker does that for you, and you just randomly loadbalance across all Swarm nodes, because Swarm reroutes calls to available Tasks (containers).

Secrets management

Secrets Management is also very simple, but you have to adapt your application to take advantage of this.

If you assign a secret to your Container or Service, then Docker mounts an in-memory filesystem at /run/secrets/ inside your container or Tasks. This file contains the secret and your application can then read it to use the secret. The file will get automatically deleted when the secret is deleted.

And of course, all secrets are encrypted at rest, and TLS is used for communication between nodes by default.

Missing Part

The main thing I’m currently missing from the Docker platform is a scale set. A Docker Service has a fixed scale. Swarm ensures that the Service always has the specified number of Tasks (read: containers). However, it makes sense that under high load more Tasks are created, and with low load the scale set is lower. An idle container doesn’t use a lot of resources, but still.

Serverless computing

A while ago I did a short proof of concept using a Docker Service for serverless computing, where the container would just exit after servicing the request. The advantage of that is that you only have very short-lived, stateless containers, which is more secure than having longer running containers. The big advantage over other lambda function solutions is that with Docker you can bring your own stack. You’re not dependent on whatever your Cloud provider provides, and you can run your own lambda function wherever you can run Docker.

Dynamic scale sets, combined with secrets management and HTTP Routing Mesh would make serverless computing with Docker very powerful.

Leave a Reply

Your email address will not be published. Required fields are marked *