Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Server Documentation / Container Guide / Introduction to Linux containers
Applies to SUSE Linux Enterprise Server 15 SP4

1 Introduction to Linux containers

The Linux kernel's namespaces and kernel control groups features enable the container to be isolated from the rest of the host system and other containers. Linux containers offer a lightweight virtualization method to run multiple isolated environments simultaneously on a single host. 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. This reduces the overhead required for accessing the operating system resources and allows for better overall performance compared to a generic Virtual Machine environment.

Advantages of using containers
  • Containers make it possible to isolate applications in self-contained units.

  • Containers provide near-native performance, as the kernel overhead is lower compared to virtualization and emulation.

  • It is possible to control network interfaces and apply resources inside containers through kernel control groups (cgroups).

  • Portability and ease of development for application developers as the container will hold all necessary libraries, dependencies, and files needed.

Limitations of containers
  • Containers run on the host system's kernel, so the containers will have to use the specific kernel version provided by the host.

  • Only Linux-based applications can be containerized.

  • A container encapsulates binaries for a specific architecture (x86_64 or aarch64 for instance). So a container made for x86_64 only runs on a x86_64 system host.

  • 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 require putting in place tools and policies that ensure security of the container infrastructure and applications.

1.1 Key concepts and brief 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 11, 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 it to run a container.

The basic Podman workflow is as follows:

Image

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

  1. Fetch a base image by pulling it from a registry to your local machine.

  2. Create a Dockerfile and use it to build a custom image on top of the base image.

  3. 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 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 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 need to 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:

Image

1.1.1 Practical example

The following procedure shows how to build a custom Docker image that can be used to run a container with a simple PHP application called example, served using the built-in PHP development server.

Procedure 1.1: Building an image and running a container
  1. Install Podman:

    > sudo zypper in podman
  2. Switch to the PHP project's directory (in this case, the directory is called example) and create a file named Dockerfile:

    > cd example
    > touch Dockerfile
  3. Open the Dockerfile file for editing and add the following:

    FROM php:7.4-cli
    COPY . /usr/src/example
    WORKDIR /usr/src/example
    EXPOSE 8000
    CMD [ "php", "-S", "0.0.0.0:8000" ]
  4. Build a container image:

    > sudo podman build -t example .

    When prompted, select the image in the Docker registry.

  5. Run a container:

    > sudo podman run -it -p 8000:8000 --rm example
  6. Point the browser to localhost:8000 to access the application running in the container.

Note that SUSE does not provide support for third-party images, such as the one used in this example.