
Containers as services in Enterprise Linux 8

When implementing server services as containers, they are usually required to be run automatically when the server starts. At Enterprise Linux 8, we can create systemd units that run containers along with server startup and end container operation with shutdown. These units can be created even for containers launched in „rootless ” mode (without requiring […]
When implementing server services as containers, they are usually required to be run automatically when the server starts. At Enterprise Linux 8, we can create systemd units that run containers along with server startup and end container operation with shutdown. These units can be created even for containers launched in „rootless ” mode (without requiring the use of a privileged user level), thus increasing the security of the server and all infrastructure.
In addition to managing system services, systemd can also manage user services. Thanks to systemd services, users can create and manage unit files for their own services using commands systemctl
, without having to have access to the root account. However, to force the user-enabled services to start when the server is started and to stop these services when it is turned off, you must first run the command loginctl enable-linger
. You can use the command to read the current status loginctl show-user user_name
.
To define user services, you must first create a directory for storing unit files:
mkdir -p ~/.config/systemd/user/
The syntax for these files is the same as for system unit files. To control new user services, we can use the command systemctl
with the option user
. Running containers with this method is useful mainly for basic and small implementations that do not have to be scalable.
Creating the systemd unit file
First, create a container using EuroLinux resources and call it “elident”:
podman create -p 8080:80 --name elident eurolinuxid/cntident
From an existing container, command podman
can generate a systemd unit file in identification using the previously created name “elident”.
[eurolinux@el84 ~]$ cd ~/.config/systemd/user/
[eurolinux@el84 user]$ podman generate systemd --name elident --files --new
Let’s look at the systemd unit file generated in this way:
[eurolinux@el84 user]$ cat container-elident.service
# container-elident.service
# autogenerated by Podman 3.2.3
# Sun Oct 24 16:07:10 CEST 2021
[Unit]
Description=Podman container-elident.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
RequiresMountsFor=%t/containers
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/container-elident.pid %t/container-elident.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-elident.pid --cidfile %t/containe
r-elident.ctr-id --cgroups=no-conmon -d --replace -p 8080:80 --name elident eurolinuxid/cntid
ent
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-elident.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-elident.ctr-id
PIDFile=%t/container-elident.pid
Type=forking
[Install]
WantedBy=multi-user.target default.target
Command podman generate systemd
uses the container as a model to create a configuration file. After creating the file, we can delete the container, because systemd expects the container to be absent – all information necessary to create it is already included in the systemd unit file above.
Command podman generate systemd
uses the following options:
--name nazwa_kontenera
– specifies the name of the existing container to be used as a model to generate the unit file. Podman also uses this name to create the unit’s file name--new
– orders Podman to configure the systemd service to create a – container when the service starts and deletes it – when the service stops. The container is ephemeral in this mode. No options--new
, Podman will configure the service to run and stop an existing container without removing it--files
– orders Podman to generate the unit file in the current directory. Without this option, Podman displays the file on its standard output.
In our example (using options --new
) when the server starts, systemd executes the command podman run
to create and then launch a new container. When the server stops, systemd executes the command podman stop
to stop the container. After stopping the container, systemd removes the container by means of a command podman rm
.
Containers managed by command systemctl
are controlled by systemd. It monitors container status and restarts them if they fail. Do not use the command podman
to launch or retain these containers as this may interfere with systemd-based monitoring.
The systemd user services enabled by default start when the user opens the first session and stops when the user closes the last session (e.g. ssh).
In order for user services to start automatically with the server, let us now follow the aforementioned command loginctl enable-linger
.
Let the container run when the server starts, let’s use the command
systemctl --user enable container-nazwa_kontenera
, i.e. in our case:
[eurolinux@el84 ~]$ systemctl --user enable container-elident
Then restart the server.
After the restart, we should see the page resulting from the work of the elident container:
To turn off container startup at server startup, use the command systemctl
with the option disable
:
[eurolinux@el84 ~]$ systemctl --user disable container-elident
Management of containers launched from the root user level
Containers to be run from administrator level can also be configured to be managed using systemd unit files. The configured files will then work exactly like regular system unit files. The configuration procedure is similar to the one previously described for root-less containers, with the following differences:
- when configuring container service using
systemctl
do not use the option--user
- when the unit file will be created using the command
podman generate systemd
, execute this command in the / etc / systemd / directory instead of the ~ / .config / systemd / user directory - no need to run the command
loginctl enable-linger
.
Summary
Containerization is an important part of today’s technological solutions, and the system ability to monitor automatically launched, secure root-less containers is an advantage of Enterprise class systems. It is in these systems that Podman is the default containerization engine, and its installation is limited to entering the command: dnf install podman
. More information about Subman can be found in our earlier article Podman versus Docker – secure containerization.