Applies to Container Guide

2 Introduction to Linux containers #

Linux containers offer a lightweight virtualization method to run multiple isolated virtual environments simultaneously on a single host. This technology is based on the Linux kernel’s namespaces for process isolation and kernel control groups (cgroups) for resource (CPU, memory, disk I/O, network, etc) management.

Unlike Xen and KVM, where a full guest operating system is executed through a virtualization layer, Linux containers share and directly use the host OS kernel.

Advantages of using containers

Size: Container images should only include the content needed to run an application, whereas a virtual machine includes an entire operating system,
Performance: Containers provide near-native performance, as the kernel overhead is lower compared to virtualization and emulation.
Security: Containers make it possible to isolate applications into self-contained units, separated from the rest of the host system.
Resources management: It is possible to granularly control CPU, memory, disk I/O, network interfaces, etc inside containers (via cgroups).
Flexibility: Container images hold all necessary libraries, dependencies, and files needed to run an application, thus can be easily developed and deployed on multiple hosts.

Limitations of containers

Containers share the host system’s kernel, so the containers have to use the specific kernel version provided by the host.
Only Linux-based applications can be containerized on a Linux host.
A container encapsulates binaries for a specific architecture (AMD64/Intel 64 or AArch64 for instance). So a container made for AMD64/Intel 64 only runs on a AMD64/Intel 64 system host without the use of emulation.
Containers in themselves are no more secure than executing binaries outside of a container, and the overall security of containers depends on the host system. While containerized applications can be secured through AppArmor or SELinux profiles, container security requires putting in place tools and policies that ensure security of the container infrastructure and applications.

2.1 Key concepts and introduction to Podman #

Although Docker Open Source Engine is a popular choice for working with images and containers, Podman provides a drop-in replacement for Docker that offers several advantages. While Chapter 6, Podman overview provides more information on Podman, this chapter offers a quick introduction to key concepts and a basic procedure for creating a container image and using Podman to run a container.

The basic Podman workflow is as follows:

Running a container, either on a local machine or in a cloud service, usually involves the following steps:

Fetch a base image by pulling it from a registry to your local machine.
Create a Dockerfile and use it to build a custom image on top of the base image.
Use the created image to start one or more containers.

To run a container, you need an image. An image includes all dependencies needed to run the application. For example, the SLE SLE BCI-Base image contains the SLE distribution with a minimal package selection.

While it is possible to create an image from scratch, few applications would work in such an empty environment. Thus, using an existing base image is more practical in most situations. A base image has no parent, meaning it is not based on another image.

Although you can use a base image for running containers, the main purpose of base images is to serve as foundations for creating custom images that can run containers with specific applications, servers, services, and so on.

Both base and custom images are usually available through a repository of images called a registry. Unless a registry is explicitly specified, Podman pulls images from the openSUSE and Docker Hub registry. While you can fetch a base image manually, Podman can do that automatically when building a custom image.

To build a custom image, you must create a special file called a Containerfile or Dockerfile containing building instructions. For example, a Dockerfile can contain instructions to update the system software, install the desired application, open specific network ports, run commands, etc.

You can build images not only from base images, but also on top of custom images. So you can have an image consisting of multiple layers. Please refer to Chapter 11, Creating custom container images for more information.