The Missing Introduction To Containerization
Aymen El Amri - eralabs.io
Tunisia Docker Meetup - Sousse - March 2019
Aymen El Amri
- I am building eralabs.io
- I curate newsletters:
- DevOpsLinks.com
- JoinShipped.com
- Kaptain.xyz
- 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
LXC
- 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
Docker
- 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
Jails
Evolved from Simple Chroot to OS Level Virtualization
Zones
Solaris Containers Create Isolated Sandboxes Called Zones
VPS
Shared kernel Support Across Multiple Native Host OSs
VM
Generic Term to Describe an Emulated Virtual Machine on top of a “Real Hardware Machine”
Containers
Use a Runtime Engine for Virtualization & a Micro OS with Orchestration Frameworks like Kubernetes
OS Level virtualization
=
Containerization
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”
Docker
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
runC
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
source: www.ianlewis.org
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
Example:
We can add new runtime using Docker by executing:
Container Runtime Interface
CRI
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
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.
CRI-O
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
Moby
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.
Specifications
- runtime-spec: The runtime specification
- image-spec: The image specification
The Missing Introduction to Containerization
By eon01
The Missing Introduction to Containerization
- 1,180