Vor 2 1/2 Jahren stellte Chef.io ein neues Projekt namens „Habitat“ vor und bis vor kurzem sah ich keinen Grund, dieses Projekt einzusetzen. Ich hielt es für überflüssig, da der Markt schon lange entschieden hätte, auf Container zu setzen und dementsprechend die Lösungen gewinnen werden, die sich um die (damaligen) Anführer der Bewegung drehten bzw. von diesen empfohlen oder entwickelt werden.
Also Docker, dazu Swarm. Alternativ Rancher, eventuell CoreOS. Und Kubernetes.
Wie es bisher ausging, ist bekannt: CoreOS und rkt sind tot, ebenso wie Docker Swarm. Der Swarm-Mode dümpelt noch im Docker-EE-Segment herum, ansonsten setzt Gott und die Welt auf Kubernetes.
Doch eine Sache ist bis heute nicht signifikant vorangekommen, nämlich das Bauen von Container-Images. Docker’s Buildkit hat zwar jüngst mal wieder ein paar nette experimentelle Features geliefert, wie z.B. ssh-agent zur Build-Zeit. Doch die grundlegende Dockerfile-Syntax wurde beibehalten und so richtig gute Alternativen gibt es nicht.
Und dann gibt es noch ein viel wichtigeres Problem: Externe Abhängigkeiten und Base-Images. Ich würde mal darauf tippen, dass 90% aller populären Container auf Docker-Hub auf Debian, Ubuntu oder Alpine Linux basieren und dann um proprietäre Repositories erweitert werden. So gut wie keiner baut sich selbst ein root Filesystem, gerade beim Einsatz einer privaten Registry ausserhalb der kommerziellen Docker-Hub-Angebote wie z.B. ECR, Azure’s Container Registry oder eine selbst gehosteten, muss man selbst regelmäßig dafür sorgen, dass die Base-Images aktualisiert und die eigenen Images neu gebaut oder gepatcht werden.
Weiterhin zeigen alle „etablierten“ Linux-Distributionen massive Schwächen beim Container-Einsatz. Sie sind schlicht nicht darauf ausgelegt. Bei Debian-basierten Dockerfiles sieht man die immer gleichen Patterns:
apt-get update; apt-get upgrade, apt-key adv –keyserver mit.wechselnder-erreichbarkeit.org… , add-apt-repository …; apt-get update; apt-get install –yes –no-install-recommends … rm -rf /var/lib/apt/lists/*
Nerv. Vergisst man mal etwas, ist das Image gleich 50MB größer. Dann gibt es mal ein neues gpg in Debian Stable und schon bricht apt-key adv — und überhaupt ist Debian uralt. Also am besten gleich ein Backports oder Unstable-Base-Image…Von Init-Systemen (systemd) oder Cron innerhalb von Containern möchte ich garnicht erst anfangen.
Regelmäßig hat man damit dann Probleme, kann Images nicht einfach (automatisiert) erfolgreich neu bauen, weil Pakete bereits wieder aus Backports oder 3rd-party-Repos verschwunden sind – besonders aggressiv ist das Chrome Repo von Google.
Alpine Linux ist zwar wunderbar einfach gehalten, die Paket-Definitionen sind Shellscripts mit einem definierten set an Variablen und Funktionen/Callbacks, hier ein Beispiel.
Doch auch hier macht man sich wieder vom Tooling und der Motivation weniger Dritter abhängig, dass bestimmte Versionen und Pakete auch brauchbar und ggf. zeitnah bereitgestellt werden. So gibt es z.B. bei Alpine kein Mono für die ARM-Architekturen, weshalb auch mein Multi-Arch-Docker-Image für OpenRA (Open-Source-Nachbau von Command & Conquer Red Alert) auf einem Debian Base image basiert (bzw. das offizielle Mono Image) und nicht zu Alpine gewechselt ist.
Hat man also wiederholt die selben Schmerzen erlebt und sich Alpine angeschaut und geht dann nochmal zu Chef’s Habitat, ist man erstaunt: Auch dort sind Paketdefinitionen („Pläne“) als Shellscript verfasst mit definierten Variablen und callbacks. Klar strukturiert, einfach. Eine Datei zzgl. ggf. Patches.
Die Ähnlichkeit zu Alpine ist unübersehbar, allerdings geht es bei Habitat nicht um das Zusammenstellen einer Distribution, sondern um das Zusammenstellen von Abhängigkeiten diverser OpenSource-Software um dann zusammen mit der eigenen Anwendungen ein immutable Artifact zu bilden..
Man macht sich also komplett unabhängig von Distributionen, erhält ein vollständig offenes Framework (das auf Rust setzt und daher auch nicht die organisatorische Google-Go-Dependency besitzt) um selbst die Dependencies zu bauen und zu pflegen – oder verlässt sich auf den bldr-Service von Chef, für den es natürlich kommerzielle Nutzungs- und Servicemodelle gibt.
Mit Habitat erstellte Pakete können für unterschiedliche Ziele exportiert oder paketiert werden, also auch Docker. Und sie enthalten einen Supervisor, der auch Healthchecks und Updates übernehmen kann.
Wer All-In auf managed Kubernetes-Lösungen von AWS, Google Cloud oder Azure geht und zudem primär Anwendungen in Go oder Java entwickelt, wird vermutlich das Problem nicht haben, nicht verstehen oder lange Zeit ignorieren können, weil es so gut wie keine low-level Abhängigkeiten ausserhalb des eigenen Runtimes gibt (dafür dann eben im Go/Java-Projekt 😉 oder man „einfach das Linux vom Cloud-Anbieter nutzt“.
Für alle anderen könnte es durchaus eine Möglichkeit sein, den erodierenden Universal-Distributionen zu entkommen und vergleichsweise ressourcenschonend wieder selbst die volle Kontrolle über alle Abhängigkeiten zu erlangen. Also vielleicht nochmal anschauen…
Update 10.02.2019
Ein Beispiel-Build war sehr ernüchternd und exportiert als Docker-Image über 220MB größer (~30%), als meine aktuelle Debian-Lösung. Habitat hat dafür, neben des eingebauten Supervisors inkl. Orchestrierung, auch gleich zwei OpenSSL installiert, dazu auch 2x kernel headers und zu allem auch Manpages, alle möglichen Timezones, Locales und Charmaps. Sicher kann man die von mir genutzten „core“-Abhängigkeiten aus Habitat auch alle forken und dann dementsprechend „kleiner“ machen, aber letztlich funktionieren die Debian/Alpine-Frickellösungen aktuell noch immer viel zu gut.