First Look at the UBI Init Base Images
Among its catalog of Universal Base Images (UBI), Red Hat provides a kind / flavor prefixed
ubi8-initimages contains the
systemdinitialization system, making them useful for building images in which you want to run
systemdservices, such as a web server or file server. […]
Cmdis set to
/sbin/init, instead of
bash, to start the
systemdInit service by default. It includes
processrelated commands (
ubi8does not. […]
ubi8-initignores normal signals to exit (
SIGKILL), but will terminate if it receives
The point seems to be—quick disclaimer: I’m not a specialist at all of this topic, just curious—that different communities have different opinions:
Upstream docker says any process can run as
PID 1in a container. And they have proven this by the thousands of docker-formatted container images that are present on their container image registry.
The systemd developers believe the opposite. They say you should always run an init system as
PID 1in any environment.
They state that
PID 1provides services to the processes inside the container that are part of the Linux API. […]
People building docker-formatted images have to build their own Init command for launching the container. They can’t simply use the systemd unit file just the way that the OS and packager intends. This is also part of the Linux Service API.
systemd expects a certain number of things, see Running systemd in a non-privileged container for the detail. A simple way to make it work is to run docker in privileged mode.
When the operator executes docker run –privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. — Docker run reference
So let’s try by installing and running an Apache HTTP server.
Now the Apache start page should be displayed in your preferred web browser at http://localhost.
From a docker image
By defining a simple docker image for that the advantage in terms of simplicity and standardisation are obvious.
We can check that the logs are written in the journal.
What is the problem?
The main one is that
journaldcontrols the output of containers, whereas tools like Kubernetes and OpenShift expect the containers to log directly to
stderr. So, if you are going to manage your containers via Orchestrator like these, then you should think twice about using systemd-based containers. Additionally, the upstream community of Docker and Moby were often hostile to the use of
systemdin a container.