Red Hat System Administration II
After completing this section, you should be able to start, stop, and check the status of a container as a systemd service.
When you deploy services such as databases or web servers as containers, you usually want those containers to start automatically with the server.
By creating systemd user unit files for your rootless containers, you can manage them with systemctl commands, similar to regular services.
By enabling those services, you ensure that the associated containers start when the host machine starts.
If your container runs in "rootless" mode, you can manage these services from a non-privileged user account for increased security.
For more sophisticated scaling and orchestration of many container-based applications and services, you can use an enterprise orchestration platform based on Kubernetes, such as Red Hat OpenShift Container Platform.
In addition to managing system services, systemd can also manage user services.
With systemd user services, users can create unit files for their own services and manage those services with systemctl commands, without requiring root access.
When you enable a user service as a non-root user, that service automatically starts when you open your first session through the text or graphical consoles or using SSH. The service stops when you close your last session. This behavior differs from the system services, which start when the system starts and stop when the system shuts down.
However, you can change this default behavior and force your enabled services to start with the server and stop during the shutdown by running the loginctl enable-linger command.
To revert the operation, use the loginctl disable-linger command.
To view the current status, use the loginctl show-user command with your user name as parameter.
username
[user@host ~]$loginctl enable-linger[user@host ~]$loginctl show-user user...output omitted...Linger=yes[user@host ~]$loginctl disable-linger[user@host ~]$loginctl show-user user...output omitted...Linger=no
To define systemd user services, create the ~/.config/systemd/user/ directory to store your unit files.
The syntax of those files is the same as the system unit files.
For more details, review the systemd.unit(5) and systemd.service(5) man pages.
To control your new user services, use the systemctl command with the --user option.
The following example lists the unit files in the ~/.config/systemd/user/ directory, forces systemd to reload its configuration, and then enables and starts the myapp user service.
[user@host ~]$ls ~/.config/systemd/user/myapp.service[user@host ~]$systemctl --user daemon-reload[user@host ~]$systemctl --user enable myapp.service[user@host ~]$systemctl --user start myapp.service
Note
To use systemctl --user commands, you must log in at the console or directly through SSH.
Using the sudo or su commands does not work.
The systemctl command interacts with a per user systemd --user process.
The system only starts that process when the user logs in for the first time from the console or SSH.
The following table summarizes the differences between systemd system and user services.
Table 13.2. Comparing System and User Services
| Storing custom unit files | System services |
/etc/systemd/system/
|
| User services |
~/.config/systemd/user/
| |
| Reloading unit files | System services |
|
| User services |
| |
| Starting and stopping a service | System services |
|
| User services |
| |
| Starting a service when the machine starts | System services |
|
| User services |
|
If you have a single container host running a small number of containers, then you can set up user-based systemd unit files and configure them to start the containers automatically with the server.
This is a simple approach, mainly useful for very basic and small deployments that do not need to scale.
For more practical production installations, consider using Red Hat OpenShift Container Platform, which will be discussed briefly at the end of this section.
To simplify the management of the rootless containers, you can create a dedicated user account that you use for all your containers. This way, you can manage them from a single user account.
Note
The account that you create to group all your containers must be a regular user account.
When you create an account with useradd, the command reserves a range of user IDs for the user's containers in the /etc/subuid file.
However, when you create a system account, with the --system (or -r) option of useradd, the command does not reserve a range.
As a consequence, you cannot start rootless containers with system accounts.
From an existing container, the podman command can generate the systemd unit file for you.
The following example uses the podman generate systemd command to create the unit file for the existing web container:
[user@host ~]$cd ~/.config/systemd/user/[user@host user]$podman generate systemd --name web --files --new/home/user/.config/systemd/user/container-web.service
The podman generate systemd command uses a container as a model to create the configuration file.
After the file is created, you must delete the container because systemd expects the container to be absent initially.
The podman generate systemd command accepts the following options:
--namecontainer_nameThe
--nameoption specifies the name of an existing container to use as a model to generate the unit file. Podman also uses that name to build the name of the unit file:container-.container_name.service--filesThe
--filesoption instructs Podman to generates the unit file in the current directory. Without the option, Podman displays the file in its standard output.--newThe
--newoption instructs Podman to configure thesystemdservice to create the container when the service starts and delete it when the service stops. In this mode, the container is ephemeral, and you usually need persistent storage to preserve the data. Without the--newoption, Podman configures the service to start and stop the existing container without deleting it.
The following example shows the start and stop directives in the unit file when you run the podman generate systemd command with the --new option:
[user@host ~]$podman run -d --name web -v /home/user/www:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105[user@host ~]$podman generate systemd --name web --new...output omitted...ExecStart=/usr/bin/podman run--conmon-pidfile %t/%n-pid --cidfile %t/%n-cid --cgroups=no-conmon -d --name web -v /home/user/webcontent:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105
ExecStop=/usr/bin/podman stop--ignore --cidfile %t/%n-cid -t 10
ExecStopPost=/usr/bin/podman rm--ignore -f --cidfile %t/%n-cid...output omitted...
|
On start, |
|
On stop, |
|
After |
In contrast, the following example shows the start and stop directives when you run the podman generate systemd command without the --new option:
[user@host ~]$podman run -d --name web -v /home/user/www:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105[user@host ~]$podman generate systemd --name web...output omitted...ExecStart=/usr/bin/podman startwebExecStop=/usr/bin/podman stop-t 10 web
|
On start, |
|
On stop, |
Use the systemctl command to control your containers.
Starting the container:
[user@host ~]$systemctl --user start container-webStopping the container:
[user@host ~]$systemctl --user stop container-webGetting the status of the container:
[user@host ~]$systemctl --user status container-web
Important
Containers managed with the systemctl command are controlled by systemd.
systemd monitors container status and restarts them if they fail.
Do not use the podman command to start or stop these containers.
Doing so may interfere with systemd monitoring.
By default, enabled systemd user services start when a user opens the first session, and stop when the user closes the last session.
For the user services to start automatically with the server, run the loginctl enable-linger command:
[user@host ~]$loginctl enable-linger
To enable a container to start when the host machine starts, use the systemctl command:
[user@host ~]$systemctl --user enable container-web
To disable the start of a container when the host machine starts, use the systemctl command with the disable option:
[user@host ~]$systemctl --user disable container-web
You can also configure containers that you want to run as root to be managed with Systemd unit files. One advantage of this approach is that you can configure those unit files to work exactly like normal system unit files, rather than as a particular user.
The procedure to set these up is similar to the one previously outlined for rootless containers, except:
You do not need to set up a dedicated user.
When you create the unit file with
podman generate systemd, do it in the/etc/systemd/systemdirectory instead of in the~/.config/systemd/userdirectory.When configuring the container's service with
systemctl, you will not use the--useroption.You do not need to run
loginctl enable-lingerasroot.
For a demonstration, see the YouTube video from the Red Hat Videos channel listed in the References at the end of this section.
In this chapter, you learned how to manually configure and manage containers from the command line on a single host, and how to configure Systemd so that containers start automatically with the server. This is useful at a very small scale and to learn more about containers.
However, in practice most enterprise deployments need more. The introduction to this chapter mentioned that Kubernetes is generally used to manage complex applications that consist of multiple cooperating containers. Red Hat OpenShift is a Kubernetes platform that adds a web-based user interface, monitoring, the ability to run containers anywhere in a cluster of container hosts, autoscaling, logging and auditing, and much more.
Discussing these tools is beyond the scope of this course. If you want to learn more, Red Hat Training offers other courses, starting with the free technical overview course Deploying Containerized Applications (DO080) and continuing with Red Hat OpenShift I: Containers & Kubernetes (DO180). For more information, visit https://learn.spidernet.pl/training.
You can also learn more about Kubernetes and Red Hat OpenShift from https://www.openshift.com. A number of resources are available there, including ways to try out OpenShift for yourself using tools like CodeReady Containers. See https://www.openshift.com/try for more information.
References
loginctl(1), systemd.unit(5), systemd.service(5), subuid(5), and podman-generate-systemd(1) man pages
Improved systemd integration with Podman 2.0
Managing Containers in Podman with Systemd Unit Files
For more information, refer to the Running Containers as Systemd Services with Podman chapter in the Red Hat Enterprise Linux 8 Building, Running, and Managing Containers Guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index#using-systemd-with-containers_building-running-and-managing-containers
