Containerization
Since some years "Container" are on everyone’s lips. It’s a prominent subject of public dicsussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. And it didn’t take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks.
As we learn time and time again, one size does not fit all. A number of the advantages of containerization are widely agreed upon. But the needs and requirements in IT are so diverse that not all of them can be optimally realized by one implementation. Therefore, there are alternative container implementations with different application profiles. And containerization is not always helpful either.
Fedora Server supports and allows several alternatives that can be used depending on the local context and/or user’s requirement profile.
Containerization options in Fedora Server
A common feature of all container systems is the sharing of the host kernel and the use of kernel capabilities (e.g. cnames) to achieve a certain mutual isolation and autonomy.
They differ in implementation, architecture principles, toolset, runtime environment and community. A rough classification is the distinction between "system container" and "application container", roughly determined by the existence and scope of an init system.
Podman
Its characteristics are
-
Application container
-
Security enhancement: no root privileges and no central controlling daemon required
-
Optimized for the interaction of multiple, coordinated containers (a "pod"), each dedicated to a specific task and cooperating with others to accomplish a complex overall task (e.g. customer management with connection to a specific database system). Reinforces the architecture principle: one and only one application per container.
-
Binary compatible container image as Docker, mutually usable
-
Free open source software
Podman is natively supported by Fedora Server and the recommended solution for application containers.
Docker
Its characteristics are
-
Application container
-
Dependent on a daemon with ROOT privileges
-
Huge trove of pre-built containers for all sorts of software
-
Mixture of a free community edition and a commercial product
Docker releases it own Community Edition for various distributions. Therefore there is no native support for Fedora Server, but a vendor repository maintained for Fedora.
LXC (libvirt)
Its characteristics are
-
System container, kind of "lightweight virtual machine"
-
Administration of container runtimes supported by Libvirt management routines for virtual machines as well as by Cockpit libvirt module
-
Container runtime solely dependent on kernel capabilities, no own toolset
-
Creation of a container disk image is not considered a task of libvirt, but a matter for the administrator. It includes composing a xml-based descriptor file. Therefore, the toolset is rated as somewhat "rough".
-
Free open source software
Libvirt LXC is natively supported by Fedora Server (via libvirt as default virtualization tool)
LXC (linux containers)
Its characteristics are
-
System container
-
One of the first implementations of containers and the "progenitor" of (meanwhile emancipated) Docker and Podman
-
Complete toolset, container images, community. Its designated successor is LXD (see next).
-
Free open source software
Linux Container’s LXC is natively supported by Fedora Server (in its LTS versions)
LXD (linux containers)
Its characteristics are
-
System container, kind of "lightweight virtual machine"
-
LXC with advanced toolset
-
Complete versatile toolset, including container images and active supportive community.
-
Free open source software
LXD is not natively supported by Fedora Server, but there is a COPR project available, Additionally there is vendor support for Fedora by a third party package manager.
systemd-nspawn container
Its characteristics are
-
System container as a "lightweight virtual machine" and also configurable as a kind of application container (with a stub init system)
-
Toolset highly integrated into systemd system management and thus a strong simplification of administration and maintenance.
-
Both technically stringent and systematic documentation as well as stringent naming and structuring of the toolset, which facilitates administration.
-
Rather new development and currently still somewhat rough SELinux support (so far its weakest point).
-
Free open source software
The systemd-nspawn container is natively supported by Fedora Server.
Want to help? Learn how to contribute to Fedora Docs ›