Betriebssyteme, die nur eine Plattform zur Ausführung von Containern zur Verfügung stellen, gibt es einige. Zu den bekanntesten gehören sicherlich CoreOS, RancherOS oder Atomic [1]. Letzteres unterstützt seit kurzem auch den Betrieb von sogenannten System-Containern. Um besser zu verstehen, was hiermit gemeint ist, lohnt sich ein Blick auf eine typische Container-basierte Infrastruktur, in der Kubernetes als Orchestrierungsframework und Docker als Container-Runtime zum Einsatz kommen.
Kubernetes erfordert ein eigenes Netzwerk zum Betrieb der Container und Pods. Dieses wird in den meisten Fällen durch den Service flannel [2] zur Verfügung gestellt. Host-System und Container verwenden dann IP-Adressen aus diesem Netzwerk. Als Backend-Datenspeicher verwendet flannel den Service etcd [3]. Sollen nun beispielsweise diese beiden Services als Container-Anwendungen laufen, so steht man vor einem klassischen Henne-Ei-Problem, da beide Services eine aktive Container-Runtime voraussetzen. Diese wiederum benötigt das von flannel erzeugte Overlay-Netzwerk und flannel selbst benötigt den etcd-Service. Aus diesem Grund werden die beiden Services in den meisten Fällen über den regulären Paketmanager der eingesetzten Distribution als Teil des Container-Betriebssystems ausgeliefert.
Es gibt noch weitere Beispiele, in denen Anwendungen wegen solcher Abhängigkeiten nicht als Container zur Verfügung gestellt werden können. Dabei ist es aber gerade das Ziel einer Container-Plattform, den Paketumfang möglichst gering zu halten und die benötigten Services stattdessen in Containern zu betreiben.
Das Atomic-Projekt hat für dieses Abhängigkeitsproblem nun eine Lösung gefunden, indem es die Installation sogenannter System-Container ermöglicht. Diese setzen spezielle Images voraus, in denen einige zusätzliche Dateien enthalten sein müssen, die
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.