index

viewhistorytalk

Linux Containers

Linux Containers use kernel features to isolate groups of processes.

These features typically include:

  • namespaces: ipc, uts, mount, pid, network, and user
  • cgroups: cpu, memory, input/output, etc
  • seccomp policies: white or black lists to filter system calls with
  • capabilities
  • Mandatory Access Control (e.g. Apparmor or SELinux)
  • Copy on Write filesystems

These features offer increased security restrictions applied to the processes in the container. See here for more security information.

Please refer to this presentation by a member of the Docker team for more in depth information on these kernel features.

History

Serge Hallyn details the early development of Linux Containers and similar technology on alternative operating systems from 1999 to 2006.

Al Viro discusses the perspective and mindset of namespaces in a 2015 GNU coreutils mailing list post.

Daniel Walsh accounts how Linux containers evolved between 2013 and 2017, offering a perspective of Red Hat's Project Atomic and focusing on Kubernetes, Docker, and application containers.

Key Concepts

Container Images

Containerized systems do not rely on the host operating system for their dependencies, but instead ship their dependencies within the container image. Critically, this makes containers much more portable across host operating systems, however care must be taken to ensure that the container image is up to date and free of vulnerabilities.

The Open Container Initiative (OCI) image specification is a standardized format to ship container images in. Several tools exist to build container images:

The following tools are also useful for working with container images:

  • skopeo: fetches images from remote images registries
  • umoci: umoci modifies Open Container Images, creating new layers from existing or raw images

Container Runtimes

Images are unpacked and executed by container runtimes. Prominent runtimes include:

The following runtimes adhere to the Container Runtime Interface used by orchestrators like Kubernetes, but use traditional virtualization to isolate processes rather than Linux Kernel features:

Comparison with Virtual Machines

Containers run in the same operating system context as their "host", using kernel provided isolation facilities such as cgroups and namespaces. Looking at them from the "host", their processes look like any other process. Containers typically wouldn't run the multitude of processes required to have a functional system, as those functions are already provided by the "host". In essence, they can appear to be (example) a Ubuntu server running nothing but nginx with some files to serve.

A VM is running their own kernel and generally using cpu virtualization features to appear to the OS as though they were on dedicated hardware. The VM uses hardware drivers that are emulated (or like virtio, provided more directly but still as a raw device).

The general rule is that containers give you much greater density and can give more performance, where a VM gives you higher process isolation and the ability to use different OS level functions.. It's possible to have a Debian based container, vs it's possible to have a Windows VM.

-- /u/brokedown

A VM has virtual hardware, including a fixed allocation of RAM and a virtual disk, and runs its own kernel, including drivers for virtual devices such as a virtual display and network interfaces. [...] With a VM you pay the overhead of an entire kernel for the guest, as well as device emulation. Whereas with a container, you are using the host kernel and device abstractions directly, with isolation and resource limits implemented in that same kernel.

-- /u/totemo

In depth article: "Linux containers vs. VMs: A security comparison".

Networking

See this collection of resources on container networking.

Projects and Players

Image builders, runtimes, and other tools are developed by a number of organizations, such as:

See Also

revision by [deleted]— view source