The Missing Introduction To Containerization

Aymen El Amri -

Tunisia Docker Meetup - Sousse - March 2019

Aymen El Amri


  • I am building


  • I curate newsletters:


  • I tweet & write Stories
    on Medium: @eon01

Software is Eating the World

Software is Eating the World

  • 2015 -> 2019: Cloud Computing & Distributed Systems are the most in-demand skills


  • Containerization technologies are one of the trendiest topics in the cloud economy and the IT ecosystem


  • The container ecosystem can be confusing

We Are Made by History

We Are Made by History

  • Docker is the most popular containerization technology


  • Docker bring containers to the mainstream given its simplicity and accessibility


  • Historically containers and isolation started since 1997 with  Chroot Jails

We Are Made by History

Chroot Jail


  • In 2008, the first version of LXC (Linux Containers) was released.


  • LXC is similar to OpenVZ, Solaris Containers and Linux-VServer, however, it uses CGroups which is already implemented in the Linux Kernel


  • In 2013, the first version of Docker was introduced.


  • It performs, like OpenVZ and Solaris Containers, operating-system-level virtualization.

Google: a Leader in the Containers Industry

  • Google developed Cgroups & LMCTFY


  • LMCTFY: the open source version of Google’s container stack, which provides Linux application containers


  • Status: Currently stalled. Google collaborate with Docker over libcontainers


  • Google runs more than 2 Billions container on its infrastructure each week ( source: Google).

Jails, Zones, VPS, VM , OS & App Containers 


Evolved from Simple Chroot to OS Level Virtualization


Solaris Containers Create Isolated Sandboxes Called Zones


Shared kernel Support Across Multiple Native Host OSs


Generic Term to Describe an Emulated Virtual Machine on top of a “Real Hardware Machine”


Use a Runtime Engine for Virtualization & a Micro OS with Orchestration Frameworks like Kubernetes

OS Level virtualization




e.g: Linux-VServer, OpenVZ, KVM

OS Containers vs App Containers

OS Containers where the operating system with the whole application stack is packaged (example LEMP). Applications Containers usually run a single process per container.

Docker: Container Engine or Platform

Short Answer: Both

Long Answer

  • 2013: Docker Started using LXC


  • In early 2013, the Docker project was to build a “standard container”


Monolithic application with multiple features from launching Cloud servers to building and running images/containers

Let’s Create a Container Using Namespaces & Cgroups

sudo apt install cgroup-tools
sudo apt install stress

Start by installing CGroup Tools and stress utility as we are going to make some stress tests.

Cgroups & Libcontainer

  • Linux facilities like CGroups and other resource control features can create and manage isolated environments in Linux systems.


  • libcontainer interfaces with these facilities to manage and run Docker containers.

runC: Leveraging libcontainer Without Using Docker


In 2015, Docker announced runC: a lightweight, portable container runtime.


runC is basically a little command-line tool to leverage libcontainer directly, without going through the Docker Engine.


The goal of runC is to make standard containers available everywhere.


This project was donated to the Open Container Initiative (OCI).


The libcontainer repository has been archived now.

Industry-standard Container Runtimes

Industry-standard Container Runtimes

Since containers become mainstream, the different actors in the containers ecosystem have been working on standardization.


Standardization is a key to automation and generalization of best practices.


While giving the runC project to the OCI, Docker started using containerd in 2016, as a container runtime that interface with the underlying low-level runtime runC.

Containerd, Shim and runC, How Everything Work Together

Docker Components

Prior to version 1.11, Docker engine was used to manage volumes, networks, containers, images etc..


Now, Docker architecture is broken into four components:

  • Docker engine
  • containerd
  • containerd-shim
  • runC


The binaries are respectively called docker, docker-containerd, docker-containerd-shim, and docker-runc.

1) Docker engine creates the container and passes it to containerd.


2) Containerd calls containerd-shim


3) Containerd-shim uses runC to run the container


4) Containerd-shim allows the runtime (runC in this case) to exit after it starts the container



How a Container is Created

1) runC can exit after starting the container and we don’t have to have the whole runtime processes running.



2) containerd-shim keeps the file descriptors like stdin, stdout and stderr open even when Docker and/or containerd die.

daemon-less containers Advantages

“If runC and Containerd are both Runtimes, Why the Heck are We using Both to Run a Single Container ?”

When you create a Docker container, it is in reality managed by both runtimes containerd and runC.

Low-Level Runtime High-Level Runtime
light, fast and non-conflictual with other higher levels of containers management Manage the lifecycle of containers
Only allows running containers. Responsible for image transfer and storage, container execution, supervision, storage, network attachments, etc..

Different Runtime Levels



Different Runtime Levels

Adding a Runtime

sudo dockerd --add-runtime=<runtime-name>=<runtime-path> 
sudo apt-get install nvidia-container-runtime
sudo dockerd --add-runtime=nvidia=/usr/bin/nvidia-container-runtime


We can add new runtime using Docker by executing:

Container Runtime Interface


Kubernetes is one of the most popular orchestration systems.


With the evolving number of containers runtime, kubernetes aims to be more extensible and interface with more containers runtimes other than Docker


CoreOS wanted to use kubernetes with RKT runtime and offered patches to kubernetes to use this runtime as an alternative to Docker.


Instead of changing kubernetes code base when adding a new container runtime, Kubernetes upstream decided to create CRI or Container Runtime Interface


CRI or Container Runtime Interface is a set of APIs and libraries that allows running different containers runtime in Kubernetes.


Any interaction between Kubernetes core and a supported runtime is performed through the CRI API.


The first container runtime created for the kubernetes CRI interface.


cri-o is not intended to replace Docker but it can be used instead of Docker runtime in the specific context of Kubernetes.

Containerd CRI

With cri-containerd, users can run Kubernetes clusters using containerd as the underlying runtime without Docker installed.

gVisor CRI

gVisor is a project developed by Google which implements around 200 of the Linux system calls in userspace, for additional security compared to Docker containers that run directly on top of the Linux kernel and are isolated with namespaces.

CRI-O Kata Containers

Kata Containers is an open source project building lightweight virtual machines that plug into the containers ecosystem.


CRI-O Kata Containers allows running Kata Containers on Kubernetes instead of Docker default runtime.

The Moby Project


The project of building a single monolithic Docker platform is somehow abandoned and gave birth to Moby project where Docker is composed of many components like RunC.

The Open Containers Initiative

Open Containers Initiative

As we have seen, Docker donated RunC to the Open Container Initiative (OCI), but what is this initiative?


The OCI is a lightweight, open governance structure, launched in 2015 by Docker, CoreOS and other leaders in the container industry.


The Open Container Initiative (OCI) aims to establish common standards for software containers in order to avoid potential fragmentation and divisions inside the container ecosystem.


  • runtime-spec: The runtime specification


  • image-spec: The image specification

The Missing Introduction to Containerization

By eon01

The Missing Introduction to Containerization

  • 354
Loading comments...

More from eon01