Containers are at the heart of Cloud operations nowadays, and Docker should undoubtedly be credited for popularizing this technology. Its runtime is built on top of process isolation and resource allocation mechanisms that exist in the Linux kernel.
From its inception as a tool that merely offered containerization support on Linux platforms some five or so years ago, Docker has grown its portfolio to include areas such as infrastructure provisioning and orchestration. Further, they’ve made significant improvements to the core containerization offering in terms of architectural improvements and OS support(am I the only one excited about the prospects of hyper-v containers and native windows containers?). The enterprise edition of the offering is a great option for those enterprises’ who wish to walk the containerization path with minimum hassle. However, it should be noted that there are other alternatives to all the components that make up the Docker stack, as such developers and organizations may mix and match their preferred technologies with the Docker runtime if they so wish.
“The enterprise edition of Docker is a great option for those enterprises’ who wish to walk the containerization path with minimum hassle.”
The first part of the article will provide a brief introduction to the Docker stack. The aim of this article is to give the reader at least a general idea of what each component of the stack does regardless of their level of technical competency or familiarity with Docker. The subsequent article will provide a demonstration that spans the complete breadth of the stack. Not this again cried the Petunias..
The runtime extrapolates the containerization capabilities of the operating system, in the case of Linux, the kernel. It provides an easy to use interface, the Docker Client. The Docker Client communicates with the Docker runtime service(dockerd) to perform various containerization related tasks.
The Docker runtime service, referred to as dockerd from this point on, is mainly responsible for,
- Hiding the complexities of creating containers and other container related resources(such as networks) out of the tools provided by the kernel and its own persistence mechanism.
- Hiding the complexities of Dockers persistence mechanism, Images(think of an image as the metadata of a container), This mechanism lies at the heart of docker runtime’s value proposition.
- Providing seamless integration to other components of the docker stack such as the docker registries, swarm and compose.
The Docker Registry
The Docker registry as its name implies acts as a registry for persisted containers, Images. The registry works as a trusted broker between different Docker container runtimes’ allowing them to securely share images among each other.
Docker Hub is a publically accessible deployment of the docker registry, which has thousands of official container images by various software vendors. An organization may just as easily place registries within the confines of its private network or even integrate them into containerization based solutions to reap the same benefits.
Docker runtime supports parsing a YAML based configuration, to build docker images. This configuration file is usually given the name “Dockerfile”. Find a link to the configuration language here.
A Dockerfile can be thought of as a “how it should be” statement. the Docker runtime’s build command can be used to parse and create an image when needed. The configuration language is able to describe most aspects of this statement, however, some aspects of the runtime cannot be known in advance(such as port availability on the host) as such these aspects have been abstracted out to be managed separately.
At the time of writing, this component is shipped separately. It provides convenience in provisioning virtualized infrastructure. The component supports multiple virtualization platforms/tools such as Virtualbox, VMWare and OpenStack, as well most of the public IaaS providers such as GCP, AWS and Azure. Find a complete list of supported platforms here
The tool provisions the infrastructure using platform specific drivers which manipulate the platform using its API to create the bare computation resources, it then sets up a barebone Linux distribution(boot2docker) with the docker runtime preinstalled.
“Like with the docker runtime, Docker-Machine adds value by hiding the complexities of infrastructure provisioning and providing uniformity across different virtualization and IaaS offerings. ”
Like with the docker runtime, Docker-Machine adds value by hiding the complexities of infrastructure provisioning and providing uniformity across different virtualization and IaaS offerings.
Docker Compose and Services
Okay, so you can isolate and manage resource allocation to your system processes with Docker containers better that it was possible with virtualization solutions, but to harness the true power of granularity that containerization gives you, you need to make the containers work together, you need to arrange them in meaningful ways and make them work together.
Docker Compose and Docker Services are the first layer of orchestration support that docker provides to its users.
“To harness the true power of granularity that containerization gives you, you need to make the containers work together, you need to arrange them in meaningful ways and make them work together.”
At the time of writing, Docker compose is shipped separately and it can be used to build or/and run group(s) containers as atomic units. It hides the complexities of networking isolated containers and sharing volumes.
Just as a Dockerfile provides a configuration file based build to a container, a Docker Compose file can group together a collection of containers that should work as atomic units. This file allows developers to mark down dependencies containers have on each other and define shared resources such as volumes and device mounts. The compose file doubles up a convenient way of bring up container groups(with the stack command)
Find a link to the compose configuration language here.
As mentioned elsewhere, there are some networking related properties of a runtime container that you simply cannot know with certainty at build time. By abstracting networking related properties of a group of containers, you remove the possibility of tightly coupled relationships that can exist between the containers of one group and the containers of another, while allowing them to access each other through the abstracted interface.
This networking related abstraction is especially important when containers need to be created and deleted at a high frequency, as is the case with Cloud Services.
“This networking related abstraction is especially important when containers need to be created and deleted at a high frequency, as is the case with Cloud Services.”
Docker Swarm is docker’s container orchestration solution, similar in functionality to other orchestration solutions such as Kubernetes and Apache Stratos. Like its competition, Swarm employes a master-slave model. Unlike some of its competition its discovery/replication mechanism is based on RAFT Consensus algorithm, one paper finds the algorithm superior to its competition in some ways and that is favored by CS students.
Leaving the architectural decisions of Swarm aside, since its usage and behavior is similar to other Docker products, those who get into containerization through the Docker runtime are likely to find it easier to use than its competition.
The swarm manager is responsible for monitoring node(VM’s or bare metal) health, allocating tasks such as running containers(replication) on specific nodes and scheduling tasks. The slave nodes are responsible for pulling tasks allocated to them and carrying the work.
The subsequent article will provide a demonstration that spans the breadth of the Docker stack.
 – https://www.docker.com/enterprise-edition
 – https://hub.docker.com/
 – https://docs.docker.com/engine/security/trust/content_trust/
 – http://www.yaml.org/start.html
 – https://docs.docker.com/engine/reference/builder/
 – https://docs.docker.com/machine/drivers/
 – https://docs.docker.com/compose/compose-file/
 – https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14