Mastering Docker Enterprise

Docker was born out of a lightning talk presentation, entitled The future of Linux Containers, delivered at PyCon on Friday, March 15, 2013. The presenter was Solomon Hykes, the founder of Docker. On that day, the software world changed even though Linux containers had been evolving in the Linux community for nearly 13 years. It was not the technology that Solomon shepherded that got the Docker movement off the ground, it was the vision behind it and the packaging of the container ecosystem. Solomon's vision was to create tools for mass innovation and his packaging of Linux containers in the Docker experience delivered this powerful technology and put containers within the grasp of mere mortals. Today, Docker runs on tens of millions of servers around the world.

Here are some notes on Linux containers:

Over the last 5 years, thousands of developers joined Docker's open source community to deliver what is known as Docker Community Edition (Docker Engine-Community). Docker has remained committed to an open platform and a level playing field. Docker has donated significant assets to the open source and standards community, including the Docker container format and runtime, to provide the cornerstone of the Open Container Initiative (OCI) in 2015 and the container runtime to the Cloud Native Computing Foundation (CNCF) in 2017. 

At Dockercon in 2017, Solomon Hykes released Project Moby, which effectively gives anyone the tooling they need to build their own Docker. This was very cool and ultimately in the best interests of the container community. However, this well-intentioned effort led to some comprehensive repackaging of Docker community assets without community buy-in. From a big-picture point of view, Docker has demonstrated its commitment to the community and Solomon's vision of tools for mass innovation.

Containers allow application developers to package up their application, along with all of their dependencies, into a portable unit called an image. These images are then stored in a remote repository where they can be pulled and run on any compliant container engine. Furthermore, the applications running on each container engine are isolated from each other and the host operating system:

docker run -p 8000:80 -v ${PWD}:/usr/share/nginx/html:ro -d nginx

In the following figure, you can see how the applications in the VMs (right side of the diagram) have a full copy of the OS and the supporting binaries in each virtual machine, whereas the containerized applications (left side of the diagram) all share the same Alpine binaries (no kernel necessary ~ 3 MB) and runtime binaries. There have been various reports on the financial impact of containers versus VMs, but the number I have seen ranges from a 15% to a 70% reduction in operational costs. As they say, your mileage may vary based on your OS, binaries, and whether or not you move to bare metal to eliminate hypervisor licensing costs:

Containerized apps vs VM apps

The following is globally a summary of what I hear from customers and students:

The open source version of Docker is called Docker Engine-Community and it is distributed under the Apache 2.0 licence. Sometimes referred to as free Docker, this version is self-and community-supported. Docker has two packaging schemes:

In addition to the platform packaging, Docker Engine-Community comes with two channels. It is important to note that as of Docker Engine-Community version 18.09, the stable channel will release on a six-month cadence and the edge channel will be replaced with a nightly build:

You may consider having a development cluster where developers deploy their code on a Docker infrastructure that matches production versions. If a dev cluster is available, developers should always deploy to dev before their code is checked in, to ensure no builds are broken. 

Free Docker is great! But supporting yourself is not always so great. Therefore, Docker Engine-Community is usually a fine choice for learning and getting started, but as soon as you head toward production, you should consider stepping up to Docker Enterprise for the support and/or the enterprise class tooling it provides. 

Docker Enterprise builds on Docker Engine-Community's already rich feature set and adds commercial support for the Docker Engine (Docker Enterprise Basic), as well as tooling that's important for managing multiple teams and production applications, including Kubernetes applications (Kubernetes is included in Docker Enterprise Standard and Advanced).

Docker offers the following support models for Docker Engine-Community and Docker Enterprise:

Docker Enterprise also includes seamless support for ISV-provided Docker certified plugins and Docker certified containers. That means if you have an issue with a certified plugin or container, you just call Docker for support.

Docker Enterprise also comes in three tiers:

Unless you have been hiding under a rock, you have probably heard about Kubernetes. Too many times I have heard (uninformed) members of the technology community say we don't use Docker, we use Kubernetes. This is a little naive since the vast majority of clusters running Kubernetes orchestration are doing so with the Docker Engine. 

Early on, born-in-the-cloud startups that were running at scale and usually deploying microservices became aware of a need for orchestration. Hence, the brilliant minds at Google created what has become the Kubernetes orchestration framework and later created an independent body to mange it, the Cloud Native Computing Foundation (CNCF), with Kubernetes as the CNCF's cornerstone project. Meanwhile, the Docker community started working on its own orchestration project called Swarmkit.

Kubernetes and Swarm – different philosophies to solve different problems

Which is better (for you)? Well, it depends…

Getting started with Kubernetes is pretty challenging. This is somewhat because in addition to a container runtime (such as Docker Engine-Community), you need to install and configure kubectl, kubeadm, and kubelet, but that's just the beginning. You also have to make some decisions up front, such as picking a networking model and configuring/installing the provider's container CNI implementation. Kubernetes does not usually provide default options (some cloud services do this for you), which gives you some great flexibility, but naturally forces you to make upfront decision and complicates installation. Again, this is great if you need this flexibility and you know exactly what you are doing.

On the other hand, if you have Docker 1.12 or newer (we strongly recommend having something much newer), you only need to activated it with thedocker swarm initcommand. It creates a certificate authority, an encrypted Raft store, and overlay networking automatically, as well as a tokenized join command for securely adding additional nodes to your cluster. However, in the spirit of simplicity and security, Docker made some default choices for you. That's great if you can live with those choices, at least while you get up to speed on enterprise container platforms.

Beyond installation, describing application deployment (using YAML files) in Kubernetes is inherently more complex. When it comes to styles of deployment, Kubernetes deploys discrete components and wires them up with a collection of YAML files that rely on labels and selectors to connect them. Again in Kubernetes style, when creating components, you have to define a wide range of behavior parameters to describe exactly what you want, rather than assuming some default behavior. This can be verbose, but it is very powerful, precise, and flexible!

Kubernetes also includes the pod as the atomic deployment unit, which can be handy for isolating a bundle of containers from the flat networking model. This leads to the use of sidecar containers that essentially interface pods to the rest of the world. This is very cool and a great way to handle networks of loosely coupled, shared, long-running services in a flat address space:

Swarm and Kubernetes

Swarm takes an application-centric, monolithic approach by defining a stack of related services in a .yaml file. Swarm stacks assume you are running a collection of related services, isolated by overlay networks, to support specific functionality in the context of an application. This makes it easy to deploy a typical application stack such as an Angular frontend with an application's RESTful API and a Postgres database.

Leveraging containers in your continuous integration and continuous deployment pipeline has become a best practice for most DevOps teams. Even the pipeline itself is often run as a containerized platform. The motivation here is a higher-quality product, based on the immutable server pattern where containers are built once and promoted through the pipeline. In other words, the application is not re-installed on a new virtual server between each step in the pipeline. Instead, the same container image is pulled from a central repository and run in the next step. Environment variables and configuration files are used to account for variations between the environments.

Since the application team has taken on the tasks of wiring up and configuring the application for deployment, the operations team can shift its focus toward the container platform. This includes setting up and maintaining the container platform's operational environments, monitoring and centralized logging for applications running in the cluster, and security/policy management within the cluster to ensure that applications and users are behaving as expected.

What if, before you started migrating all of your applications to a specific cloud-specific provider, you instead containerize your applications first and then migrate them to the cloud. This is sometimes referred to as a container-first strategy. There are several significant benefits to this approach:

Moving to the cloud is fun and cool! However, it can get very expensive and hard for an enterprise to control. Most of what I see from clients is that the cloud makes sense for highly variable workloads where elastic capacity is very important. However, when steady, predictable workloads are involved, many organizations find the public cloud to be too expensive and ultimately migrate them back to their data center or private cloud. This is referred to as workload repatriation and it's becoming a very common event.

Docker customers have documented significant reductions in operational costs achieved by simply containerizing traditional web-based (.NET 2.0+ and Java) applications and establishing a Docker Enterprise infrastructure to run them. This infrastructure can run in the cloud, VMware, or even bare metal. There is a methodology used by Docker solution architects to help enterprises migrate traditional applications. It starts with accelerated PoC, moves to a pilot application, and finally to production, where each step builds on the last. 

At this point in the game, most development teams won't even attempt to build and deploy microservices without containers and orchestrators. 12-factor style development teams have lots of moving part and deploy often—a perfect fit for Docker and Kubernetes! These teams use containerized, decentralized CI/CD systems that come with built-in container support to achieve low error rates using high-speed automated deployments. 

While compliance for container platforms is achievable with third-party products such as Sysdig Secure, Twistlock, and AquaSec, Docker Enterprise 2.1 adds FIPS compliance support for Windows and RHEL platforms. This means the Docker platform is validated against widely accepted standards and best practices during Docker Enterprise product development.With this, the companies and agencies get additional confidence to adopt Docker containers. Federal Information Processing Standard (FIPS) Publication 140-2 being the most remarkable standards, verifies and permits the use of various security encryption modules within an organization software stack which now includes the Docker Enterprise Engine.