Containerizaton

In this entry we look at containerization as a general technology that is distinct from its particular implementation by Docker.

We can understand the role and significance of containers and containerization by analogy with shipping containers. Before the invention of shipping containers as a standardised modular unit for transporting goods, shipping and supply chains were chaotic: inefficient, complex, frictional. With the advent of the shipping container, the same artefact could be used for transportation via ships, trains, lorries etc.

With containers we can share and transport software via a single standardised unit that works regardless of the host operating system or server. We can also iterate different software environments easily: local, production, test etc. As with the shipping of goods, standardisation has driven down running costs and increased the speed of transport.

Containers and software

• Containers are a technology that allow you to package and isolate applications with their entire runtime environment. This makes it easy to move the contained application between various environments whilst retaining full functionality.

• The technology of containerization is distinct from Docker. Docker is a particular implementation of containerization that simplifies the process and bases it on a standardised specification.

• Containers are native to the Linux kernal and are key part of how it works. Thus when you run containers on Linux, you are using native capability. When you use containers on Windows or Mac you have to run a virtual version of Linux in order to exploit the capabilities of that kernel. (Docker provides this)

How containers work

A key feature of the Linux kernal is the existence of cgroups (control groups).

Containerization = resource control + process isolation

• A cgroup groups a series of processes together and contrains their access to system resources (CPU, memory, disk)
• Cgroups use namespaces to provide process isolation: groups of processes are isolated so that they cannot access other processes on the system. For example a container is ignorant of the underlying operating system and network, by default.

In ordinary user space applications share the same processor, memory and file system resources. This increases the likelihood of resourcing challenges, dependency conflicts and security threats. Without modularisation and the titration of resources, you are opened up to much greater possibility of failure.

For example one application could fill up the harddrive preventing other applications from writing to it. One application can “bring down” another applicaton.

Prior to containerization, in an enterprise environment most of the system administration consisted in managing resouces to avoid excessive resource expenditure and security challenges.

Standard userspace

Userspace with containerization

Differences with virtual machines

Containers are similar in many regards to VMs. They both offer a virtualized environment in which to run software and they both provide isolation of resources. (When you start up a VM you specify the available RAM and disk space.)

The central difference is that VMs require the existence of a full operating system. Containers can run without an OS although it is often convenient to run them with stripped-down Linux distributions.

A VM contains a complete installation of a guest OS and requires a hypervisor on the host OS to manage the different operating environments. This makes them slower and consume more resources.

A containerized system radically reduces this overhead. It just starts up the container and after that it’s job is done since the Linux kernel handles the rest as it would any other process on the OS.

Why use containers?

• portability
• scalability
• efficiency
• isolation
• DevOps agility