Difficulty: Intermediate
Estimated Time: 30-45 minutes

Background

In this self paced tutorial you will gain a basic understanding of the moving parts that make up the typical container architecture. This will cover container hosts, daemons, runtimes, images, orchestration, etc.

By the end of this lab you should be able to:

  • Draw a diagram showing how the Linux kernel, services and daemons work together to create and deploy containers
  • Internalize how the architecture of the kernel and supporting services affect security and performance
  • Explain the API interactions of daemons and the host kernel to create isolated processes
  • Command the nomenclature necessary to technically discuss container repositories, image layers, tags, registry server and other components

Video

This video will give you a background to all of the concepts in this lab.

Outline

  • Containers Are Linux: Userspace libraries interact with the kernel to isolate processes
  • Single Host Toolchain: Includes Docker runtime, Systemd, runc, and Libcontainer
  • Multi-Host Toolchain: Includes Kubernetes/OpenShift
  • Typical Architecture: Explains what a production cluster looks like
  • Community Landscape: Explains the basics of the upstream projects and how they are contributing

Start Scenario

Once you have watched the background video, continue to the exercises.

In this course you learned:

  • Containers Are Linux: Userspace libraries interact with the kernel to isolate processes
  • Single Host Toolchain: Includes Docker runtime, Systemd, and LibContainer
  • Multi-Host Toolchain: Includes Kubernetes/OpenShift
  • Typical Architecture: Explains what a production cluster looks like
  • Community Landscape: Explains the basics of the upstream projects and how they are contributing

You can find a copy of the slides and GitHub repo that contains all of these commands so that you can run them yourself in your own environment:

Also, if you have any questions tweet us at:

@OpenShift @RedHatAtomic @fatherlinux

Don’t stop now! The next scenario will only take about 10 minutes to complete.

Linux Container Internals - Lab 1: Container Architecture

Step 1 of 5

Topic 1 - Container Architecture: Starting From Scratch

First and foremost, you need to understand that THE INTERNET IS WRONG. If you just do a quick Google search, you will find architectural drawing after architectural drawing which depict things the wrong way or depict only part of the whole picture, rendering the viewer to come to the wrong conclusion about containers. One might suspect that the makers of many of these drawings have the wrong conclusion about how containers work. So, forget everything you think you know.

Containers Are Linux

What’s wrong? Two main things:

  1. Most of the architectural drawings above show the docker daemon as a wide blue box stretched out over the container host. The containers are shown as if they are running on top of the docker daemon. This is incorrect - the containers are actually created and run by the Linux kernel.
  2. When the architectural drawings do actually show the right architecture between the docker daemon, libcontainer/lxc/etc and the kernel, they never show containers running side by side. This leaves the viewer to imagine #1.

OK, let’s start from scratch. In the terminal, let's start with a simple experiment - start three containers which will all run the top command:

docker run -td rhel7 top''

docker run -td rhel7 top''

docker run -td rhel7 top''

Now, let's inspect the process table of the underlying host:

ps -ef | grep top

Notice that even though we started each of the top commands in containers, they are still just a regular process which can be viewed with the trusty old ps command. That's because containers are just fancy Linux processes with extra isolation from normal Linux processes.

While they are still just Linux processes, containerized processes are started in a way in which their kernel data structures are separate from other Linux processes on the system, and are further isolated using technologies like selinux and cgroups. This is sometimes described as "sand boxing" or "isolation" or an "illusion" of virtualization.

In the end though, containerized processes are just regular Linux processes. All processes live side by side, whether they are regular Linux processes, long lived daemons, batch jobs, interactive commands which you run manually, or containerized processes. All of these processe make requests to the Linux kernel for protected resources like memory, RAM, TCP sockets, etc. We will explore this deeper in later labs, but for now, commit this to memory...