Container und ihre Weiterentwicklung

Software::Container

Container und ihre Weiterentwicklung

Red Hats Sicherheitsexperte Daniel J. Walsh berichtet über die Weiterentwicklung bei Containern aus der Sicht von Red Hat.

Von Ferdinand Thommes

www.GlynLowe.com

Container

Auf dem Höhepunkt des Hype um Container war Daniel J. Walsh einer der Ersten, die öffentlich den Finger auf eine Schwachstelle bei Containern legte: die Sicherheit. Seither ist viel geschehen auf diesem Gebiet und vieles davon bei Red hat. Walsh schaut zurück auf die Integration von Containern in das Geschäftsmodell bei Red Hat.

Walsh begann 2013 mit der Bereitstellung von Docker für Red Hat Enterprise Linux (RHEL). Eine der ersten Hürden dabei war, ein »Copy On Write«-Dateisystem (COW) zu erstellen, das mit den Ebenen eines Docker-Images umgehen kann. Aus dieser Problemstellung entstanden COW-Implementationen für Device Mapper, Btrfs und OverlayFS. Für RHEL wird derzeit noch Device Mapper eingesetzt, der Umstieg auf OverlayFS rückt jedoch näher.

Mit der Frage, mit welchen Werkzeugen Container unter RHEL erstellt werden sollten, wurden die Lösungsansätze schnell komplex und problembehaftet. Hinzu kam das Problem, dass jede neue Docker-Version Regressionen schuf und Werkzeuge unbrauchbar machte. Zu diesem Zeitpunkt verwendete Docker Linux-Container (LXC) zum Erstellen von Containern. Weder LXC noch das bei Red Hat zu der Zeit verwendete Libvirt-LXC erwiesen sich als für die Zukunft praktikable Lösungen.

Auf der ersten DockerCon im Jahr 2014 stellten viele Firmen und Projekte Werkzeuge vor, um mit größeren Mengen an Containern umzugehen. Darunter war auch Google mit der Vorstellung von Kubernetes. Hier waren Googles Erfahrungen mit der Orchestrierung ihrer riesigen Infrastruktur eingeflossen. Red Hat schloss sich der Entwicklung von Kubernetes an, das heute eines der größten Projekte auf GitHub ist.

CoreOS, Mitstreiter und Konkurrent von Docker, entwickelte zu dieser Zeit eine eigene Runtime namens rkt (Rocket) sowie die Standard-Container-Spezifikation AppContainer (appc), die beschreibt, wie Container mit Applikationen umgehen. Docker reagierte, öffnete sich der Open-Source-Gemeinschaft und rief die Open Container Initiative (OCI) ins Leben. OCI erarbeitet in der Folge zwei Spezifikationen. Die OCI Runtime Specification will die Konfiguration und die Werkzeuge zum Erstellen und Ausführen von Containern standardisieren. Die OCI Image Format Specification basiert auf dem Format der Docker-Images und legt fest, wie Container-Images generell aufgebaut sind.

Von dieser Standardisierung profitierte auch Kubernetes, das von CoreOS einige Patches zur Unterstützung der Container-Runtime Rocket erhielt. Die Kubernetes-Entwickler entschieden sich allerdings, die Einbindung dieser und künftiger Runtimes sauber per API vorzunehmen. Heraus kam die API-Protokoll-Spezifikation Container Runtime Interface (CRI). Red Hat machte sich nun im Rahmen des Projekts Atomic an die Erweiterung der Werkzeuge zur Handhabung von Container-Images. So gab es zu der Zeit für Docker keine Möglichkeit, die Informationen über das Image aus der JSON-Datei auszulesen, ohne das ganze Image herunterzuladen.

Da Docker die Red-Hat-Patches nicht annahm, um die Docker-CLI nicht zu verkomplizieren, entschied sich Red Hat, die Werkzeuge selbst in Atomic-CLI zu integrieren. So entstand Skopeo, das die Handhabung vom Images in entfernten Container-Registries verbessert. Später wurde im Projekt Atomic der Atomic Host eingeführt, ein Betriebssystem mit atomaren Updates und Applikationen in Containern nach dem OCI Image Format. Ein Henne-Ei-Problem bezüglich Applikationen, die in Containern ausgeliefert werden sollen, aber eigentlich schon laufen müssen, bevor der Container-Runtime-Daemon startet, konnte mithilfe von Systemd gelöst werden.

So lernte Atomic-CLI, Container beim Systemstart selbst zu starten, ohne dazu eine Runtime zu benötigen. Um etwa beim Systemstart den Daemon »etcd« zu starten, kann der Befehl atomic install --system etcd ausgeführt werden, der per Skopeo das etcd-OCI-Image herunterlädt, woraufhin eine Systemd-Unit zum Start des Images erstellt wird.

Wo Walsh derzeit die Innovation am meisten gebremst sieht, ist bei den Methoden zur Erstellung von Container-Images. Der Großteil der Images wird mit Docker-Build und den Anweisungen in einem Dockerfile erstellt. Docker nimmt aber seit Jahren keine Patches mehr für Dockerfile an. Walsh sieht Dockerfile heute als unzulängliches Format, das einige nie gelöste Probleme mitschleppt. Auf der DevConf.cz 2017 wurde deshalb von Red Hat Buildah vorgestellt, eine Sammlung von CLI-Befehlen, die Dockerfile nachahmen, ohne wie dieses auf eine laufende Runtime angewiesen zu sein.