Systemd is now the default service manager on nearly all Linux distributions, which makes it a logical choice for...
deploying Linux containers. It provides a convenient standard for controlling programs and services, as well as managing resource allocation and mounting file systems.
In fact, some people think that systemd is becoming too diverse of a tool, and there's some truth to this criticism. Multipurpose, do-everything style applications are somewhat contrary to the generic Linux philosophy of creating applications to do one thing and do it very well. However, as a sophisticated service manager that many administrators rely on, it only makes sense to consider using systemd to deploy and manage Linux containers as well.
What exactly is a Linux container?
A container is basically a Linux service that runs in an isolated environment on top of the Linux kernel. Services running in one container are not accessible from other containers because of sophisticated security features, such as Linux kernel namespaces and chroot.
Linux containers have been around for some time, thanks to Virtuozzo and LXC. However, with the emergence of Docker in recent years, Linux containers have gained significant interest, and many vendors and distributions are now focusing on container management. With so many specialized projects around, the question is whether it makes sense for systemd to deploy and manage containers.
How systemd Linux containers work
Let's dig deeper into Linux-based containers. As mentioned before, a container is a service that runs in an isolated secure environment, with dedicated resources on top of a Linux kernel. These containers are portable, meaning they can run on any Linux distribution. Systemd is a service manager that enables these services and can manage the components, such as cgroups and chroot environments, which enable the isolation containers rely on.
In systemd, nspawn is the component that can be used to start containers. It's a relatively new approach that was introduced into the systemd release that came with Red Hat Enterprise Linux 7.1.
To create an nspawn container, the systemd-nspawn@.service has to be enabled, which runs against a dedicated environment where the container service is started from. To do so, you would need a command, such as:
yum -y --releasever=7Server --installroot=/var/lib/container/minirhel7 install systemd passwd yum redhat-release-minimal
Next, nspawn must be pointed to the specific directory, using the following command:
systemd-nspawn -D /var/lib/container/minirhel7
This lays the foundation and creates the container environment from which you can run commands, such as "passwd" to set the root password. In the second part of this article, I'll describe a step-by-step procedure for how you can create containers with systemd-nspawn on Red Hat Enterprise Linux 7.1
The big question is whether there is a need for systemd Linux containers when there are so many other services already. I think there is a need. I don't think the ideal approach to creating Linux containers exists yet. Docker has seen a lot of interest lately, but it lacks options to integrate it properly into an OpenStack cloud environment. Ubuntu has launched an alternative, using the LXD project, but that may not provide the final answer either.
In the current IT landscape where the perfect Linux container doesn't exist, it only makes sense for systemd to give it a try as well. After all, systemd is already taking care of all the ingredients that are needed to build a container, so why not join them together in an attempt to provide an alternative solution?
What's the difference between application containerization and LXC?
Docker ushers in new era for containers
How does container technology fit in the cloud picture?
Find out if container technology is right for your business