“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 26-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

1. The success of containers depends on different Linux features. Which of the following is not one of them?

1. Cgroups

2. Semaphores

3. Namespaces

4. SELinux

2. What is the name of the Red Hat solution to add enterprise features such as scalability and availability to containers?

1. OpenStack

2. OpenShift

3. Kubernetes

4. JBoss

3. How do you detach from a running container without shutting it down?

1. exit

2. quit

3. detach

4. Ctrl-P, Ctrl-Q

4. Which command will run an application container in the background?

1. podman run nginx

2. podman run -d nginx

3. podman run --background nginx

4. podman run -it nginx

5. Which command do you use to inspect images that have not yet been pulled to your local system?

1. podman inspect

2. buildah inspect

3. skopeo inspect

4. docker inspect

6. Which command do you use for an overview of the registries currently in use?

1. podman info

2. podman status

3. podman search

4. podman registries

7. There are many ways to figure out whether a container needs any environment variables. Which of the following can you use?

1. Use podman inspect to inspect the image that you want to run. Within the image, you’ll often find usage information.

2. Use podman run to run the container. If environment variables are required, it will fail. You can next use podman logs to inspect messages that have been logged to STDOUT.

3. Read the documentation provided in the container registry.

4. All of the above.

8. Which SELinux context type must be set on host directories that you want to expose as persistent storage in the container using bind mounts?

1. container_t

2. container_file_t

3. container_storage_t

4. public_content_rw_t

9. Which of the following commands shows correct syntax to automatically set the correct SELinux context type on a host directory that should be exposed as persistent storage inside a container?

1. podman run --name mynginx -v /opt/nginx:/var/lib/nginx nginx

2. podman run --name mynginx --bind /opt/nginx:/var/lib/nginx nginx

3. podman run --name mynginx -v /opt/nginx:/var/lib/nginx:Z nginx

4. podman run --name mynginx --bind /opt/nginx:/var/lib/nginx:Z nginx

10. What is needed to ensure that a container that user anna has created can be started as a systemd service at system start, not just when user anna is logging in?

1. Configure the container as a systemd service.

2. Use loginctl enable-linger anna to enable the linger feature for user anna.

3. Use systemctl enable-linger anna to enable the linger feature for user anna.

4. Just use systemctl --user enable to enable the container.

Foundation Topics

Understanding Containers

In the past decade, containers have revolutionized the way services are offered. Where not so long ago physical or virtual servers were installed to offer application access, this is now done by using containers. But what exactly is a container? Let’s start with an easy conceptual description: a container is just a fancy way to run an application based on a container image that contains all dependencies required to run that application.

To install a noncontainerized application on a server, the server administrator must make sure that not only the application is installed but also all the other software dependencies required by the application. This includes, for instance, the right (supported) version of the underlying operating system. This makes it difficult for application developers, who need to provide many versions of their applications to support all current operating systems.

A container is a complete package that runs on top of the container engine, an integrated part of the host operating system. A container is comparable to an application on your smartphone: you get the complete application package from the smartphone’s app store and install it on your phone.

To use a container, you run the container from the container image. This container image is found in the container registry, which can be compared to the app store that hosts smartphone applications. The result is the container, which is the runnable instance of the container image.

To run containers, you need a host operating system that includes a container engine, as well as some tools used to manage the containers. On versions of RHEL prior to RHEL 8, this was supported by Docker. Docker delivered the container engine as well as the tools to manage the containers. In RHEL 8, Red Hat replaced Docker with a new solution, which is still used on RHEL 9: CRI-o is the container engine, and Red Hat offers three main tools to manage the containers:

• podman: The main tool, used to start, stop, and manage containers

• buildah: A specialized tool that helps you create custom images

• skopeo: A tool that is used for managing and testing container images

Container Host Requirements

Sometimes it is said that containers are Linux, and that is true. This is because containers rely heavily on features that are offered by the Linux kernel, including the following:

• Namespaces for isolation between processes

• Control groups for resource management

• SELinux for security

Let’s explore each of these features. To start with, containers need namespaces. A namespace provides isolation for system resources. To best understand what namespaces are like, let’s look at the chroot jail, a feature that was introduced in the 1990s. A chroot jail is a security feature that presents the contents of a directory as if it is the root directory of your system, so the process that runs in a chroot jail can’t see anything but the contents of that directory.

Chroot jails are important for security. When a process is restricted to just the contents of a chroot jail, there is no risk of it accessing other parts of the operating system. However, to make sure this works, all the dependencies required to run the process must be present in the chroot jail.

Chroot jails still exist, but the functionality is now leveraged and is a part of what is called the mount namespace. Here’s an overview of it and some of the other namespaces (note that new namespaces may be added in the future as well):

• Mount: The mount namespace is equivalent to the chroot namespace. The contents of a directory are presented in such a way that no other directories can be accessed.

• Process: A process namespace makes sure that processes running in this namespace cannot reach or connect to processes in other namespaces.

• Network: Network namespaces can be compared to VLAN. Nodes connected to a specific network namespace cannot see what is happening in other network namespaces, and contact to other namespaces is possible only through routers.

• User: The user namespace can be used to separate user IDs and group IDs between namespaces. As a result, user accounts are specific to each namespace, and a user who is available in one namespace may not be available in another namespace.

• Interprocess communication (ipc): Interprocess communication is what processes use to connect to one another, and these namespaces ensure that connection can be made only to processes in the same namespace.

In containers, almost all of the namespaces are implemented to ensure that the container is a perfectly isolated environment. Only the network namespace is not enabled by default, to ensure that communication between containers is not restricted by default.

The second important Linux component that is required for running containers is the control group, or cgroup. Cgroups are a kernel feature that enables resource access limitation. By default, there is no restriction to the amount of memory or the number of CPU cycles a process can access. Cgroups make it possible to create that limitation in such a way that each container has strictly limited access to available resources.

The last important pillar of containers is implemented on RHEL by using SELinux. As you’ve learned elsewhere in this book, SELinux secures access by using resource labels. On RHEL, a specific context label is added to ensure that containers can access only the resources they need access to and nothing else.

Running a Container

To get familiar with containers, let’s start by running some. To get full access to all tools that RHEL is offering for running containers, you should start by installing the appropriate software. You can do this by using sudo dnf install container-tools. After installing this software, you can start running your first container by using podman run, which does not require any root privileges. You can use this command with many arguments; the only argument that is really required, however, is the name of the image that you want to run. As we discuss later, the image is fetched from one of the container registries that is configured by default. To run your first container, use the command podman run nginx. This will try to start the nginx image from one of the known registries. You can see the result of running this command in Example 26-1.

Example 26-1 Podman May Prompt Which Registry You Want to Use

[root@server1 ~]# podman run nginx
? Please select an image:
    registry.fedoraproject.org/nginx:latest
    registry.access.redhat.com/nginx:latest
    registry.centos.org/nginx:latest
    quay.io/nginx:latest
    docker.io/library/nginx:latest

While using podman run, it may not be clear from which registry the image you want to run should be started. If that is the case, the podman command will prompt to make a choice from one of the available registries, as can be seen in Example 26-1. This can be avoided by including the complete registry name of the image: if you use podman run docker.io/library/nginx, Podman knows it needs to fetch the image from the docker.io registry. Example 26-2 shows how this works out.

Example 26-2 Running Your First Container with podman run nginx

[root@server1 ~]# podman run docker.io/librarynginx
Resolved "nginx" as an alias (/var/cache/containers/short-name-
  aliases.conf)
Trying to pull docker.io/library/nginx:latest...
Getting image source signatures
Copying blob eef26ceb3309 done
Copying blob 71689475aec2 done
Copying blob 8e3ed6a9e43a done
Copying blob f88a23025338 done
Copying blob 0df440342e26 done
Copying blob e9995326b091 done
Copying config 76c69feac3 done
Writing manifest to image destination
Storing signatures
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will
  attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /
  docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-
  ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/
  nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/
  nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-
  templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-
  processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2022/10/31 07:27:27 [notice] 1#1: using the "epoll" event method
2022/10/31 07:27:27 [notice] 1#1: nginx/1.23.2
2022/10/31 07:27:27 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian
  10.2.1-6)
2022/10/31 07:27:27 [notice] 1#1: OS: Linux 5.14.0-70.13.1.el9_0.x86_64
2022/10/31 07:27:27 [notice] 1#1: getrlimit(RLIMIT_NOFILE):
  1048576:1048576
2022/10/31 07:27:27 [notice] 1#1: start worker processes
2022/10/31 07:27:27 [notice] 1#1: start worker process 24
2022/10/31 07:27:27 [notice] 1#1: start worker process 25

As you can see in Example 26-2, when running the container, Podman starts by fetching the container image from the registry you want to use. Container images typically consist of multiple layers, which is why you can see that different blobs are copied. When the image file is available on your local server, the nginx container is started. As you will also notice, the container runs in the foreground. Use Ctrl-C to terminate the container.

You typically want to run containers in detached mode (which runs the container in the background) or in a mode where you have access to the container console. You can run a container in detached mode by using podman run -d nginx. Notice that all options that modify the podman command (podman run in this case) need to be placed behind the podman command and not after the name of the image.

When you run a container in detached mode, it really runs like a daemon in the background. Alternatively, you can run the container in interactive TTY mode. In this mode, you get access to the container TTY and from there can work within the container. However, this makes sense only if the container is configured to start a shell as its default command. If it does not, you may have to add /bin/sh to the container image, so that it starts a shell instead of its default command.

Let’s have a look at how this works:

Step 1. To start the nginx image in interactive TTY mode, use the command podman run -it nginx.

Step 2. You are now connected to a TTY in which you only have access to the nginx process output. That doesn’t make sense, so use Ctrl-C to get out.

Step 3. Now start the container using podman run -it nginx /bin/sh. This will start the /bin/sh command, instead of the container default command, which will give you access to a shell. After starting the container in this way, you have access to the TTY, and all the commands that you enter are entered in the container and not on the host operating system.

When you’re running in interactive mode, there are two ways to get out of it:

• Use exit to exit the TTY mode. If you started the container using podman run -it nginx /bin/sh, this will stop the container. That’s because the exit command stops the primary container command, and once that is stopped the container has no reason to be around anymore.

• Use Ctrl-P, Ctrl-Q to detach. This approach ensures that in all cases the container keeps on running in the background in detached mode. That may not always be very useful though. If like in the previous example you’ve started the nginx image with /bin/sh as the default command (instead of the nginx service), keeping it around might not make much sense because it isn’t providing any functionality anyway.

To get an overview of currently running containers, you can use the podman ps command. This will show you only containers that are currently running. If a container has been started but has already been stopped, you won’t see it. If you also want to see containers that have been running but are now inactive, use podman ps -a. In Example 26-3 you can see the output of the podman ps -a command.

Example 26-3 podman ps -a Output

student@podman ~]$ podman ps -a
CONTAINER ID  IMAGE       COMMAND    CREATED        STATUS
PORTS           NAMES
1f6426109d3f  docker.io/       sh        6 minutes ago  Exited (0) 6
  minutes ago  adoring_
              library/
feynman
              busybox: latest
0fa670dc56fe  docker.io/        nginx -g   8 minutes ago  Up 8
  minutes             web1
              library/        daemon o...                 ago
              nginx:latest
15520f225787  docker.io/       nginx -g     32 minutes ago Exited (0)
  32 minutes ago peaceful_
              library/       daemon o...
visvesvaraya
              nginx:latest

Notice the various columns in the output of the podman ps command. Table 26-2 summarizes what these columns are used for.

In Exercise 26-1 you can practice running containers and basic container management.

Working with Container Images

The foundation of every container is the container image. The container is a running instance of the image, where while running it a writable layer is added to store changes made to the container. To work with images successfully, you need to know how to access container registries and how to find the appropriate image from these registries. Container images are created in the Docker format. The Docker format has become an important standard for defining container images, which is why you can run container images in Docker format without any problem in RHEL.

[student@server1 ~]$ podman info | grep -A 10 registries
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
  - docker.io
store:
  configFile: /home/student/.config/containers/storage.conf
  containerStore:
    number: 0  OsArch: linux/amd64
  Version: 4.0.2

INDEX        NAME                DESCRIPTION
  STARS   OFFICIAL   AUTOMATED
docker.io  docker.io/panubo/   MariaDB Galera Cluster         23
  [OK]
           mariadb-galera
docker.io  docker.io/demyx/    Non-root Docker image running  0
           mariadb             Alpine Linux a...
docker.io  docker.io/toughiq/  Dockerized Automated MariaDB   41
  [OK]
          mariadb-cluster      Galera Cluster ...
docker.io  docker.io/bianjp/   Lightweight MariaDB docker     15
  [OK]
          mariadb-alpine       image with Alpine...
docker.io  docker.io/          MariaDB relational database    2
  [OK]
          clearlinux/mariadb   management syste...
docker.io  docker.io/          Fast, simple, and lightweight  2
  [OK]
          jonbaldie/mariadb    MariaDB Docker...
docker.io  docker.io/          Docker MariaDB server w/       1
  [OK]
          tiredofit/mariadb    S6 Overlay, Zabbix ...

student@podman ~]$ podman inspect busybox
[
    {
        "Id":
"6858809bf669cc5da7cb6af83d0fae838284d12e1be0182f92f6bd96559873e3",
        "Digest": "sha256:d366a4665ab44f0648d7a00ae3fae139d55e32f9712c
  67accd604bb55df9d05a",
        "RepoTags": [
            "docker.io/library/busybox:latest"
        ],
        "RepoDigests": [
"docker.io/library/busybox@sha256:2ca5e69e244d2da7368f7088ea3ad0653c3ce
  7aaccd0b8823d11b0d5de956002",
"docker.io/library/busybox@sha256:d366a4665ab44f0648d7a00ae3fae139d55e3
  2f9712c67accd604bb55df9d05a"
        ],
       "Parent": "",
        "Comment": "",
        "Created": "2020-09-09T01:38:02.334927351Z",
        "Config": {
            "Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "sh"
            ]
        },
        "Version": "18.09.7",
        "Author": "",
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 1454611,
        "VirtualSize": 1454611,
        "GraphDriver": {
            "Name": "overlay",
            "Data": {
                "UpperDir": "/home/student/.
local/share/containers/storage/overlay/
be8b8b42328a15af9dd6af4cba85821aad30adde28d249d1ea03c74690530d1c/diff",
               "WorkDir": "/home/student/.
local/share/containers/storage/overlay/
be8b8b42328a15af9dd6af4cba85821aad30adde28d249d1ea03c74690530d1c/work"
            }
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
"sha256:be8b8b42328a15af9dd6af4cba85821aad30adde28d249d1ea03c74690530
  d1c"
            ]
        },
        "Labels": null,
        "Annotations": {},
        "ManifestType": "application/vnd.docker.distribution.manifest.
  v2+json",
        "User": "",
        "History": [
            {
                "created": "2020-09-09T01:38:02.18459328Z",
                "created_by": "/bin/sh -c #(nop) ADD file:72be520892
  d0a903df801c6425de761264d7c1bc7984d5cf285d778147826586 in / "
            },
            {
                "created": "2020-09-09T01:38:02.334927351Z",
                "created_by": "/bin/sh -c #(nop)  CMD ["sh"]",
                "empty_layer": true
            }
        ]
    }
]

FROM registry.access.redhat.com/ubi8/ubi:latest
RUN dnf install nmap
CMD ["/usr/sbin/nmap", "-sn", "192.168.29.0/24"] [

Managing Containers

While working with containers, you need to be aware of a few operational management tasks:

• Managing container status

• Running commands in a container

• Managing container ports

• Managing container environment variables

In this section you learn how to perform these tasks.

Managing Container Status

You have already learned how podman ps shows a list of currently running containers and how you can extend this list to show containers that have been stopped by using podman ps -a. But let’s talk about what brings a container to a stopped status.

To understand containers, you need to understand that they are just a fancy way to run an application. Containers run applications, including all of the application dependencies, but in the end, the purpose of a container is to run an application. In some cases, the application is a process that is meant to be running all the time. In other cases, the application is just a shell, or another command that runs, produces its result, and then exits, as you have seen in Exercise 26-3. Containers in the latter category are started, run the command, and then just stop because the command has been executed successfully, and there is nothing wrong with that.

Before we continue, let me explain where the potential confusion about the stopped status of containers comes from. Sometimes, a container is considered to be something like a virtual machine. If you start an Ubuntu virtual machine, for instance, it starts and will keep on running until somebody comes and decides to stop it. Containers are not virtual machines. Every container image is configured with a default command, and as just discussed, the container runs the default command and then exits, as it’s done after running the command. Some containers, however, run services, which keep running all the time.

For those containers that do keep on running after starting them, you can use a few commands to stop and start them:

• podman stop sends a SIGTERM signal to the container. If that doesn’t give any result after 10 seconds, a SIGKILL command is sent.

• podman kill immediately sends a SIGKILL command. In most cases, that’s not necessary because podman stop will send a SIGKILL after 10 seconds.

• podman restart restarts a container that is currently running.

Also, don’t forget that after stopping a container, it is still available on your local system. That availability is convenient because it allows you to easily restart a container and maintain access to modifications that have previously been applied and stored in the writable layer that has been added to the container image while running the container. If, however, you’ve been starting and stopping containers a lot and don’t need to keep the container files around, use podman rm to remove those container files. Alternatively, use podman run --rm to run your container. This command ensures that after it is run, the container files are automatically cleaned up.

Managing Container Environment Variables

Many containers can be started without providing any additional information. Some containers need further specification of how to do their work. This information is typically passed using environment variables. A well-known example where you have to pass environment variables to be able to run the container successfully is mariadb, the database service that needs at least to know the password for the root user that it is going to use.

If a container needs environment variables to do its work, there are a few ways to figure this out:

• Just run the container without any environment variables. It will immediately stop, and the main application will generate an error message. Use podman logs on your container to read the log for information on what went wrong.

• Use podman inspect to see whether there is a usage line in the container image that tells you how to run the container. This may not always work, as it depends on whether or not the image creator has included a usage line in the container image.

After you’ve found out how to run the container, run it, specifying the environment variables with the -e option. To run a mariadb instance, for example, you can use podman run -d -e MYSQL_ROOT_PASSWORD=password -e MYSQL_USER=anna -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=mydb -p 3306:3306 mariadb. Exercise 26-6 guides you through the procedure of running a container using environment variables.

Exercise 26-6 Managing Container Environment Variables

1. Use podman run docker.io/library/mariadb. It will fail (and you will see an error message on the STDOUT).

2. Use podman ps -a to see the automatically generated name for the failing mariadb container.

3. Use podman logs container_name to see the Entrypoint application error log. Make sure to replace container_name with the name you found in step 2.

4. Use podman inspect mariadb and look for a usage line. You won’t see any.

5. Use podman search registry.redhat.io/rhel9/mariadb to find the exact version number of the mariadb image in the RHEL registry.

6. Use podman login registry.redhat.io and provide valid credentials to log in.

7. Use podman run registry.redhat.io/rhel9/mariadb-nnn (make sure to replace nnn with the version number you found in step 5). It will also fail but will show much more usage details on the STDOUT. The reason is that the Red Hat mariadb image is not the same as the image that was fetched from the Docker registry in the first step of this procedure.

8. Use podman inspect registry.redhat.io/rhel9/mariadb-nnn and in the command output search for the usage line. It will tell you exactly how to run the mariadb image.

9. According to the instructions that you found here, type podman run -d -e MYSQL_USER=bob -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=mydb -e MYSQL_ROOT_PASSWORD=password -p 3306:3306 registry.redhat.io/rhel9/mariadb-105. (By the time you read this, the version number may be different, so make sure to check the version number of the image if you’re experiencing a failure in running this command.)

10. Use podman ps. You will see the mariadb container has now been started successfully.

Managing Container Storage

When a container is started from an image, a writable layer is added to the container. The writable layer is ephemeral: modifications made to the container image are written to the writable layer, but when the container is removed, all modifications that have been applied in the container are removed also. So if you run an application in a container and want to make sure that modifications are stored persistently, you need to add persistent storage.

To add persistent storage to Podman containers, you bind-mount a directory on the host operating system into the container. A bind-mount is a specific type of mount, where a directory is mounted instead of a block device. Doing so ensures that the contents of the directory on the host operating system are accessible within the container. So, when files are written within the container to the bind-mounted directory, they are committed to the host operating system as well, which ensures that data will be available beyond the lifetime of the container. For more advanced storage, you should use an orchestration solution. When you use OpenShift or Kubernetes, it’s easy to expose different types of cloud and datacenter storage to the containers.

To access a host directory from a container, it needs to be prepared:

• The host directory must be writable for the user account that runs the container.

• The appropriate SELinux context label must be set to container_file_t.

Obviously, the container_file_t context label can be set manually by a user who has administrator privileges, using semanage fcontext -a -t container_file_t "/hostdir(/.*)?"; restorecon. It can also be set automatically, but that works only if the user who runs the container is the owner of the directory. It is not enough if the user has write permissions on the directory! For an easy way to apply the right SELinux context, you should focus on the automatic solution.

To mount the volume, you use the -v host_dir:container_dir command. If the user running the container is owner, or the container is a root container, you can use -v host_dir:container_dir:Z as an alternative to setting the SELinux context automatically. So, to make sure that a mariadb database is started in a way that database files are stored on the host operating system, you use podman run -d --name mydb -v /home/$(id -un)/dbfiles:/var/lib/mysql:Z -e MYSQL_USER=user -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=mydatabase registry.redhat.io/rhel9/mariadb-105. In Exercise 26-7 you can practice running containers with storage attached.

To understand what is really happening while running rootless containers, it makes sense to investigate a bit more. Rootless containers are launched in a namespace. For each user, a namespace is created in which all containers are started. The namespace provides isolation, which allows the container inside the namespace to run as the root user, where this root-level access does not exist outside of the namespace. To make this work, inside the container namespace different UIDs are used than those used outside of the namespace.

To ensure that access is working correctly, UIDs are mapped between the namespace and the host OS. This UID mapping allows any UID inside the container namespace to be mapped to a valid UID on the container host. The podman unshare command can be used to run commands inside the container namespace, which in some cases is necessary to make sure the container is started the right way. To start with, as a non-root user, type podman unshare cat /proc/self/uid_map. This shows that the root user (UID 0) maps to the current user ID, which in Example 26-8 is shown as UID 1000.

Example 26-8 Using podman unshare to Show UID Mappings

[student@server1 ~]$ podman unshare cat /proc/self/uid_map
          0        1000          1
          1      100000      65536

If you want to set appropriate directory ownership on bind-mounted directories for rootless containers, additional work is required:

Step 1. Find the UID of the user that runs the container main application. In many cases podman inspect imagename will show this.

Step 2. Use podman unshare chown nn:nn directoryname to set the container UID as the owner of the directory on the host. Notice that this directory must be in the rootless user home directory, as otherwise it wouldn’t be a part of the user namespace.

Step 3. Use podman unshare /cat/proc/self/uid_map to verify the user ID mapping.

Step 4. Verify that the mapped user is owner on the host by using ls -ld ~/directoryname.

In Exercise 26-8 you’ll practice bind-mounting in rootless containers

Running Containers as Systemd Services

As containers are becoming increasingly common as the way to start services, a way is needed to start them automatically. When you’re using Kubernetes or OpenShift to orchestrate container usage, this is easy: the orchestration platform ensures that the container is started automatically, unless you decide this is not desired behavior. On a standalone platform where containers are running rootless containers, systemd is needed to autostart containers.

In systemd, services are easily started and enabled with root permissions using commands like systemctl enable --now myservice.service. If no root permissions are available, you need to use systemctl --user. The --user option allows users to run the common systemd commands, but in user space only. This works for any service that can run without root permissions; for instance, use systemctl --user start myservice.service to start the myservice service.

By default, when systemctl --user is used, services can be automatically started only when a user session is started. To define an exception to that, you can use the loginctl session manager, which is part of the systemd solution to enable linger for a specific user account. If you use loginctl enable-linger myuser, you enable this for the user myuser. When linger is enabled, systemd services that are enabled for that specific user will be started on system start, not only when the user is logging in.

The next step is to generate a systemd unit file to start containers. Obviously, you can write these files yourself, but a much easier way is to use podman generate systemd --name mycontainer --files to do so. Note that this container file must be generated in the ~/.config/systemd/user/ directory, so you have to create that directory and change to it before running the podman generate command.

The podman generate systemd command assumes that a container with the name mycontainer has already been created and will result in a unit file that can be enabled using systemctl --user enable container-mycontainer.service. In Example 26-9 you can see what such a unit file looks like.

Example 26-9 Podman Autogenerated Container Service File

[student@server1 ~]$ cat container-wbe2.service
# container-wbe2.service
# autogenerated by Podman 4.0.2
# Mon Oct 31 10:35:47 CET 2022

[Unit]
Description=Podman container-wbe2.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/1000/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman start wbe2
ExecStop=/usr/bin/podman stop -t 10 wbe2
ExecStopPost=/usr/bin/podman stop -t 10 wbe2
PIDFile=/run/user/1000/containers/overlay-containers/2a7fe7b225bdbbfd3b
  3deb6488b9c57400530b2e77310fd3294b6d08b8dc630b/userdata/conmon.pid
Type=forking

[Install]
WantedBy=default.target

In Exercise 26-9 you can practice working with Podman autogenerated systemd unit files.

Summary

In this chapter you learned about containers. First, you learned how containers really come forth from the Linux operating system and then learned all that is needed to run containers. This includes managing images, managing containers and container storage, as well as running containers as systemd services.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have several choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix C; Chapter 27, “Final Preparation”; and the practice exams.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the margin of the page. Table 26-5 lists a reference for these key topics and the page numbers on which each is found.

Complete Tables and Lists from Memory

There are no memory tables or lists in this chapter.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

container

container engine

registry

CRI-o

namespace

Docker

Kubernetes

OpenShift

image

orchestration

linger

Review Questions

The questions that follow are meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.

1. What is the name of the tool that Red Hat includes with RHEL 9 to work with container images without having to download them from the registry first?

2. What are the three Linux features that are needed in container environments?

3. What is the name of the container engine on RHEL 9?

4. Which file defines the registries that are currently used?

5. After you start a container, using podman run ubuntu, executing podman ps doesn’t show it as running. What is happening?

6. What do you need to do to start a rootless container that bind-mounts a directory in the home directory of the current user account?

7. How can you find the default command that a container image will use when started?

8. How do you start an Ubuntu-based container that prints the contents of /etc/os-release and then exits?

9. What do you need to do to run a podman nginx container in such a way that host port 82 forwards traffic to container port 80?

10. Which command do you use to generate a systemd unit file for the container with the name nginx?

End-of-Chapter Lab

At this point you should be familiar with running containers in a RHEL environment. You can now complete the end-of-chapter lab to reinforce these newly acquired skills.

Lab 26.1

1. Ensure that you have logged in to get access to the Red Hat container registries.

2. Download the mariadb container image to the local computer.

3. Start the mariadb container, meeting the following requirements:

   • The container must be accessible at port 3206.

   • The MYSQL_ROOT_PASSWORD must be set to “password”

   • A database with the name mydb is created.

   • A bind-mounted directory is accessible: the directory /opt/mariadb on the host must be mapped to /var/lib/mysql in the container.

4. Configure systemd to automatically start the container as a user systemd unit upon (re)start of the computer.