LXC/Incus-Systemcontainer: Was sie sind und wann sie statt eines Anwendungscontainers sinnvoll sind

Worum es geht

Incus, dokumentiert auf linuxcontainers.org und 2023 als Fork von LXD entstanden, ist ein Verwaltungswerkzeug für Systemcontainer und virtuelle Maschinen. Beide werden über dieselbe Abstraktion, die „Instanz“, und denselben Befehlssatz gesteuert. Laut Dokumentation führt ein Systemcontainer ein vollständiges Betriebssystem mit Init-System und mehreren Diensten aus und nicht bloss eine einzelne Anwendung. Dieses Modell hat LXC bekannt gemacht, und Incus führt es fort. Anwendungscontainer (das übliche Modell von Docker/Podman) bündeln dagegen einen Prozess samt Abhängigkeiten, in der Regel ohne Init-System im Container.

Warum es wichtig ist

Die beiden Modelle eignen sich für unterschiedliche Aufgaben. Ein Systemcontainer verhält sich wie eine leichtgewichtige, schnell startende VM: Man kann sich per ssh verbinden (oder die Konsole nutzen), mehrere langlebige Dienste darin betreiben, OS-Paketupdates darin einspielen und ihn weitgehend wie einen kleinen eigenständigen Rechner behandeln. Dabei teilt er sich den Kernel mit dem Host, startet daher typischerweise innerhalb weniger Sekunden und verursacht weniger Overhead als eine vollständige VM. (Für ein SSH-Login muss wie auf jedem Rechner ein SSH-Server im Container installiert sein.) Ein Anwendungscontainer ist dagegen für genau eine Aufgabe pro Container gedacht, wird als Einheit orchestriert und ersetzt, und der Zustand liegt ausserhalb. Wer einen Systemcontainer nur für einen Webserver-Prozess wählt, handelt sich Komplexität ein, die ein Podman-/Docker-Container einfacher bewältigen würde. Wer umgekehrt eine Anwendungscontainer-Engine für eine vollständige Legacy-Umgebung mit mehreren Diensten einsetzt, arbeitet gegen die Annahmen des Werkzeugs.

So wird es angewendet

• Zugriff: Der incus-Client benötigt Root-Rechte oder die Mitgliedschaft in der Gruppe incus-admin, um den lokalen Server vollständig zu steuern (die Gruppe incus gewährt ein eingeschränktes Projekt pro Benutzer).
• Instanz erstellen und prüfen: incus launch images:debian/12 mycontainer startet einen Systemcontainer aus einem veröffentlichten Image (mit --vm entsteht stattdessen eine virtuelle Maschine); incus list zeigt alle Instanzen mit Typ, Zustand und Adressen.
• Shell öffnen: incus exec mycontainer -- bash führt einen Befehl im Container aus; incus console mycontainer verbindet mit der Instanzkonsole (nützlich, solange das Netzwerk noch nicht läuft; Trennen mit Ctrl+a q), und incus console mycontainer --show-log gibt das Konsolenlog aus.
• Vor riskanten Änderungen einen Snapshot anlegen: incus snapshot create mycontainer before-upgrade, danach mit incus snapshot restore mycontainer before-upgrade zurückrollen. Wie jeder Snapshot liegt er im eigenen Storage-Pool der Instanz und ist kein unabhängiges Backup; dafür schreibt incus export mycontainer /backup/mycontainer.tar.gz einen Tarball, der sich auf anderen Speicher verschieben lässt.
• Incus (oder LXC direkt) einsetzen, wenn eine betriebssystemartige, persistente Umgebung mit mehreren Diensten gewünscht ist, die den Host-Kernel teilt; Podman/Docker einsetzen, wenn die Deployment-Einheit ein einzelner, aus einem Image gebauter Prozess ist.

Stolpersteine

• Annahme, ein Systemcontainer sei eine Sicherheitsgrenze, die einer VM gleichwertig ist: Er teilt den Kernel mit dem Host, daher beeinträchtigen Kernel-Schwachstellen die Isolation wie bei jeder Container-Technik. Container sind standardmässig unprivilegiert (UID-Mapping); security.privileged=true hebt dieses Mapping auf und sollte bei nicht vertrauenswürdigen Workloads vermieden werden.
• Unbeaufsichtigte Paket-Upgrades in vielen Systemcontainern ohne dieselbe Patch-Disziplin wie auf dem Host: Jeder Container ist ein kleines Betriebssystem, das eigene Wartung braucht.