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
Made with Slides.com