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 runto create and then launch a new container. When the server stops, systemd executes the command podman stopto 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 systemctldo 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.

blank Authors

The blog articles are written by people from the EuroLinux team. We owe 80% of the content to our developers, the rest is prepared by the sales or marketing department. We make every effort to ensure that the content is the best in terms of content and language, but we are not infallible. If you see anything that needs to be corrected or clarified, we'd love to hear from you.