Was sind Container?

Container dienen der Virtualisierung auf Betriebssystemebene und sind irgendwas zw. einer virtuellen-Maschine (VM) und einer chroot (wiki) Umgebung. Bei der Containervirtualisierung (wiki) wird keine Hardware emuliert – das würde man korrekter Weise dann VM nennen – sondern eine isolierte Umgebung (VE) bereit gestellt, in der Anwendungen laufen. Eine solche Anwendung kann der init-Prozess sein, dann würde ein ganzes Betriebsystems isoliert angeboten werden oder eben auch nur eine einzelne Anwendung. Für beides (App & OS) gilt, dass sie den Kernel des HOST-Systems und die ihm zur Verfügung stehenden Hardware Resourcen nutzen. Dies ist wiederum genau die Abgrenzung zur VM, bei der wie gesagt die Hardware emuliert wird auf der dann ein Kernel gestartet wird.

Resourcen: Eine VM (wiki) emuliert die Hardware und der Emulator weist dem Gast-System die System-Ressourcen des Hostsystems zu. Bei den Container weist der HOST-Kernel dem Container die System-Ressourcen zu. Technische Basis für die Einteilung der Ressourcen sind die Linux-Kontroll-Groups (aka cgroups) und die Kernel-Namespaces. D.h. im Gegensatz zu VMs, bei denen der Emulator die Ressourcen zuweist, basiert bei Containern die Zuweisung der System-Ressourcen auf einem Rechtemanagement im Linux-Kernel.

Bemerkung

Andere Betriebsysteme als Linux, wie z.B. MacOS oder MS-Windows verfügen in ihrem Kernel nicht über die erforderlichen Technologien wie cgroups oder Kernel-Namespaces, weshalb Container Implementierungen wie Docker auf diesen Betriebsystemen noch einen Hypervisor benötigen in dem letzlich ein Linux gestartet wird. Nachteil: es muss erst ein Linux auf diesen Plattformen emuliert werden, was i.d.R. zusätzliche Resourcen in Anspruch nimmt.

Isolierung: Der Container ist maximal gegen das Hostsystem abgesichert. So wird beispielsweise seitens des HOST-Kernels ein Container mit einer Benutzer- & Gruppen- ID (UID & GID) betrieben (ab Linux Kernel 3.12), die auf dem Hostsystem des HOST-Kernel keine Rechte hat. Selbst wenn es einem Benutzer im Container gelingt root Rechte zu erlangen, so beschränken sich diese nur auf den Container. Selbst in einem solchen worst-case Szenario kann dieser root aus dem Container keine Manipulation am Hostsystem vornehmen.

Ziel der Linux Container ist es, eine Umgebung bereit zu stellen, die so weit wie möglich einer Standard Linux Installation gleicht, ohne dass dafür ein seperater Kernel eingerichtet werden muss. Da sie aufgrund ihrer Architektur sozusagen bare-metal laufen – keine Emulation der Hardware – sind Container immer schneller und Ressourcen schonender als jeder Hypervisor einer VM es sein kann. Man darf aber auch nicht außer Acht lassen, dass die fehlende Hardware Emulation die Use-Cases für Container wiederum auch einschränkt.

Zusammengefasst kann man sagen, dass Container gut als auch resourcen-günstig skallieren aber hald‘ eben keine echten VMs sind ;) In Verbindung mit der snap Paketverwaltung hat man einen Werkzeugkasten zusammen, mit dem Aspekte wie Software-Test und Software-Deployment – zumindest für große Teile der Linux-Derivate/-Distributionen – einfacher und schneller bedient werden können als man das bisher konnte.

Die Idee solcher Container ist an sich nichts Neues. Es gab bereits 2000 die FreeBSD-Jails, diese hatten immer einige Sicherheitslücken und um sie unter Linux zu nutzen musste der Linux-Kernel gepatched werden. LXD baut auf dem Vanilla Kernel auf. Mit den cgroups des Vanilla Kernel und den Kernel-Namespaces kann LXC den Container robust vom Hostsystem isolieren.

Wie jede VM braucht auch ein Container ein initiales Image zum starten (der Begriff booten trifft hierbei nur bedingt zu). Die Images als auch die Container werden vom LXD verwaltet und über einen WEB-Service bereit gestellt (Remote-Images).

Mehr zu LXD siehe auch: Introduction to LXD projects und snapcraft LXD.