Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 13 Min.

Cloud Native Application Bundles für einfaches Container-Deployment: Pakete in den Wolken


Linux Magazin - epaper ⋅ Ausgabe 2/2020 vom 02.01.2020

Cloud Native Application Bundles beschreiben ein Paketformat, mit dem sich Applikationen in einer Microservice-Architektur leicht verteilen lassen. Wie funktioniert das in der Praxis?


Artikelbild für den Artikel "Cloud Native Application Bundles für einfaches Container-Deployment: Pakete in den Wolken" aus der Ausgabe 2/2020 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 2/2020

© Elnur Amikishiyev, 123RF


Container und kein Ende: Langsam, aber stetig dringen Docker & Co. in alle Ecken der Software-Landschaft vor. Für einige Unternehmen sind Container sogar der lange gesuchte Grund, um Teile der eigenen Legacy-Umgebung durch komplette Neuentwicklungen zu ersetzen. Wer das tut, der folgt dann auch den Mantras der Cloud-Ready-Gurus und entwickelt nicht länger große Monolithen. Stattdessen zerteilt er ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 2/2020 von Die Alleswisser. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Die Alleswisser
Titelbild der Ausgabe 2/2020 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 2/2020 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 2/2020 von Bericht von der VMworld 2019 in Barcelona: In Richtung Pazifik. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Bericht von der VMworld 2019 in Barcelona: In Richtung Pazifik
Titelbild der Ausgabe 2/2020 von Kernel 5.4: ExFAT in Staging, Lockdown-Modus: Neues Sperrgebiet. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kernel 5.4: ExFAT in Staging, Lockdown-Modus: Neues Sperrgebiet
Titelbild der Ausgabe 2/2020 von Sicher auf Kubernetes zugreifen: Fallen vermeiden. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Sicher auf Kubernetes zugreifen: Fallen vermeiden
Vorheriger Artikel
Aus dem Alltag eines Sysadmin: Dstat, Nethogs & Nload: Alles …
aus dieser Ausgabe
Nächster Artikel Eine eigene Suchmaschine bauen (Teil 4): Sucherfolg
aus dieser Ausgabe

Container und kein Ende: Langsam, aber stetig dringen Docker & Co. in alle Ecken der Software-Landschaft vor. Für einige Unternehmen sind Container sogar der lange gesuchte Grund, um Teile der eigenen Legacy-Umgebung durch komplette Neuentwicklungen zu ersetzen. Wer das tut, der folgt dann auch den Mantras der Cloud-Ready-Gurus und entwickelt nicht länger große Monolithen. Stattdessen zerteilt er seine App in viele kleine Häppchen und lässt diese über standardisierte Schnittstellen – meist APIs auf Basis des ReST-Prinzips – miteinander kommunizieren. Dieser Ansatz hat mehrere Vorteile.
Wohl der größte Vorteil: Erst auf dieser Basis wird agile Entwicklung überhaupt möglich. Einzelne Teile einer nach dem Prinzip der Mikroarchitektur gestrickten Applikation betreuen dann meist kleine Teams oder einzelne Entwickler, und die müssen sich eben nur um ihre Komponente kümmern. Das funktioniert, solange sie eine einmal definierte APISchnittstelle nicht ändern. Es ermöglicht separate Entwicklungszyklen der einzelnen Komponenten und erleichtert „release early, release often“ merklich. Ein weiterer elementarer Vorteil der Containerisierung ist, dass sich in Container verpackte Anwendungen sehr leicht in anderen Umgebungen ausrollen lassen – vorausgesetzt, dort steht dieselbe Container-Runtime bereit. Wer etwa auf einem nackten RHEL 8 Docker installiert, kann dort ein Docker-Image problemlos starten, das er zuvor auf seinem Ubuntu-PC erstellt hat. Schon betrachten nicht wenige Anwender Container als logische Fortführung von Paketmanagern, und Entwickler von Lösungen wie Snaps unter Ubuntu stoßen in eben dieses Horn.

Ein neues Ökosystem

Wie es allerdings so läuft mit neuer Technik, dauert es eine Weile, bis sich ein Standard-Toolset herauskristallisiert. Vor diesem Effekt sind auch Container nicht gefeit. In der Anfangsphase etwa war Docker der unangefochtene Platzhirsch. Praktisch holte das mittlerweile in weiten Teilen an Mirantis verkaufte Unternehmen im Alleingang Container aus ihrer Schmuddelecke und machte sie salonfähig.
Es stellte sich allerdings schon bald heraus, dass, wer Docker als Fundament für Applikationen nutzt, eine Logik braucht, um die verschiedenen Container einer Applikation zentral zu verwalten. Im Zeitalter der Cloud muss zudem ein passendes Framework auch gleich den Betrieb von Docker-Containern in ganzen Flotten physischer oder virtueller Systeme möglich machen – nur so ist Skalierbarkeit gegeben. Schnell traten Lösungen wie Kubernetes auf den Plan, während die eigentlichen Containerformate eher in den Hintergrund rückten. Kubernetes etwa lässt sich heute ebenso gut mit CRI-O anstelle von Docker betreiben. Von außen bemerkt man dabei kaum einen Unterschied (wie bei OpenShift, Abbildung 1).
Da stellt sich die Frage: Wie lässt sich ein möglichst generisches und doch hinreichend effektives Format definieren, um Container zu verteilen? Wer sich in der Linux-Welt auskennt, der weiß, dass RPM und DEB seit Jahrzehnten eng definierte Standards sind. Wer für ein Programm also ein DEB-Paket baut und sich an die Regeln hält, kommt zuverlässig zu einem guten Paket.
Anders war das bisher bei Containern. Das fiel 2018 auch Docker und Microsoft auf, die sich zusammen daran machten, die Malaise zu beseitigen. Heraus kam CNAB (Abbildung 2), das Container Native Application Bundle. Vor einigen Monaten haben die Entwickler ihren Schützling offiziell unter der Versionsnummer in die Freiheit entlassen. Grund genug, CNAB genauer auf den Zahn zu fühlen: Was legt der Standard fest, was nicht, und wie profitieren Admins und Entwickler von CNAB?

Was zu tun ist

Um die Idee hinter CNAB zu verstehen, hilft es, sich die Arbeiten im Leben eines Container-Entwicklers zu vergegenwärtigen. Bei einer Applikation, die aus vielen kleinen Komponenten besteht, hat der Entwickler es auch mit vielen kleinen Containern zu tun. Wie er diese entwickelt, dazu macht CNAB erst einmal keinerlei Vorgaben.
Auch bei DEB spielt es erst einmal keine Rolle, auf welche Art und Weise das Paket entsteht. Wichtig ist die Kompatibilität zu jener Version des DEB-Standards, die der Paketentwickler in dessen Metadaten angibt. So, wie sich bei RPM und DEB bestimmte Toolchains herauskristallisiert haben, die heute überwiegend für den Paketbau zum Einsatz kommen, passiert das auch bei Containern.
Etliche Male hat Linux-Magazin bereits darüber berichtet, dass eine umfassende Integration in ein CI/ CD-Werkzeug einen zwingenden Bestandteil einer validen Container-Story ausmacht. Macht der Entwickler sich ganz am Anfang seiner Arbeit die Mühe, diese einmal aufzusetzen, zahlt sich das immer und immer wieder aus: Die für den Bau eines Images nötigen Befehle stehen etwa in einem Dockerfile, das in einem Git-Verzeichnis liegt. Ändert sich an diesem Dockerfile oder sonst irgendwo im Repo ein Detail, triggert die Git-Umgebung per Hook-Applikation selbst den Neubau des Abbilds. GitLab hat als Beispiel sogar eine eigene Docker-Registry an Bord, in die es neue Images auf Wunsch hochlädt. Eine Schwalbe macht noch keinen Sommer, und ein Abbild noch keine in einer Microservices-Architektur ausgerollte Applikation. Das hat eine Vielzahl von Gründen. Einer davon ist, dass der Admin es hier eben nicht mit nur einem Container zu tun hat, sondern mit mehreren, die es in der Regel in einer bestimmten Art und Weise auszurollen gilt.
Wie bei normalen Paketen auch, gibt es zwischen Containern oft Abhängigkeiten. Zum Teil fällt die Komplexität bei Containern

sogar deutlich höher aus als bei Paketsystemen, denn es müssen nicht nur bestimmte Container parallel laufen. Stattdessen gilt es, auch ihre Konfiguration aufeinander abzustimmen. Und rollt man Container im Kontext eines Flottenorchestrierers wie Kubernetes aus, hat auch der noch eigenen Informationsbedarf im Hinblick auf verschiedene Parameter, die bereits beim Rollout beachtet sein wollen.

Abbildung 1: Docker scheiterte auch deshalb, weil ihm Managementfunktionen fehlten.


CNAB liefert die Metadaten

Als Kleber, der verschiedene Docker-Images im laufenden Zustand sowie ihre Konfiguration zusammenhält, fungieren Metadaten sowie ein Werkzeug, das diese interpretiert und umsetzt. Genau hier

kommt CNAB ins Spiel: Der Terminus ist – für viele Anwender sicher verwirrend – sowohl die Bezeichnung des definierten Standards als auch der Überbegriff für die damit verbundenen Werkzeuge. Nichtsdestotrotz ergibt es aber durchaus Sinn, Standardformat und Tools getrennt zu betrachten.
Die beiden Initiatoren des Cloud Native Application Bundles, Microsoft und Docker, sehen in CNAB in erster Linie einen Paketstandard, der die Formate und Metadaten festlegt, um Applikationen in Containern zu verteilen. CNAB richtet sich dabei an all jene Administratoren, die im Wust der verschiedenen Dienste und APIs rund um Container in den vergangenen Jahren den Überblick zu verlieren drohten.

Abbildung 2: Cloud Native Application Bundle ist ein Format, um Container-Anwendungen zu paketieren.


Abbildung 3: Duffle ist die Referenzimplementierung für CNAB, um fertige CNAB-Bundles zu bauen .


© Deislabs

Tatsächlich hat man es als Admin ja mit etlichen APIs und Tools zu tun: Docker auf der Kommandozeile, Kubernetes mit seinen gefühlt Hunderten Tools und Werkzeugen und diverse Zusatzdienste wie Terraform oder CloudFormation erfreuen sich der Gunst der Anwender. Sie alle kommen mit eigenen Metadatenformaten daher, die der Admin sich aneignen muss, will er über sie Applikationen ausrollen. Am einfachsten rollt man eine Applikation indes aus, indem man sie in einen großen Docker-Container packt und per Docker Hub verteilt, auch wenn das nicht sonderlich flexibel ist.
Der CNAB-Standard tritt an, Ordnung in die Kombination aus verfügbaren Tools und Standards zu bringen. CNAB beschreibt deshalb ein Metadatenformat, das die Nuancen vieler verschiedener Laufzeitumgebungen abstrahiert (darunter Terraform, CloudFormation, Kubernetes oder Docker Compose) und unter einer gemeinsamen Domain Specific Language (DSL) nutzbar macht. Obwohl Kubernetes aktuell das Containerwerkzeug der Stunde ist, richtet CNAB sich nicht nur an Kubernetes-Fans – wohl nicht zuletzt, weil auch Docker die Finger mit im Spiel hat und mit Docker Swarm ein Konkurrenzprodukt zu Kubernetes anbietet.

Geeignet für verschiedene Umgebungen

Beim Cloud Native Application Bundle geht die Abstrahierung so weit, dass es sogar möglich ist, verschiedene Dienste einer Applikation auf verschiedenen Plattformen auszurollen. Während manche Komponenten dann in Kubernetes laufen, siedeln sich andere in BOSH oder Rancher an. Praktisch dürfte man solche Einsatzszenarien zwar nicht besonders häufig antreffen, aber dass sie möglich sind, zeigt, wie erfreulich flexibel CNAB ausgelegt ist.

Metadaten und Invocation Image

Wie soll man sich als Admin oder Entwickler ein CNAB-Bundle vorstellen? Es gilt der übliche Grundsatz, dass auch CNAB nur mit Wasser kocht, sodass der Grundaufbau des Formats die meisten Admins gar nicht überraschen dürfte. Im Wesentlichen bekommt man es mit zwei Dateien zu tun: In einer YAML-Datei steht die Bundle Definition, die alle relevanten Metadaten enthält. Zu ihr gesellt sich ein Invocation Image, das der Installation der eigentlichen Container dient. Das Invocation-Image ist also eine Art Metadienst, dessen Aufgabe nur darin besteht, anhand der Information der Bundle-Definition die tatsächlichen Container auszurollen.
Eine eingebaute Qualitätskontrolle haben Microsoft, Docker und Firmen wie HashiCorp dem neuen Format auch spendiert: Es unterscheidet zwischen „well formed“ und „complete“. Als well formed gilt eine CNAB-Applikation, wenn sowohl die Bundle-Definition als auch die benötigten Images dem CNAB-Standard folgen. Sie darf sich zudem complete nennen, wenn sie entweder alle benötigten Komponenten in das Paket integriert („thick bundle“) oder wenn die Bundle-Definition alle externen Abhängigkeiten korrekt auflistet und diese sich auflösen lassen („thin bundle“). Letzterer Ansatz dient offensichtlich dazu, Plattenplatz zu sparen, macht das Ausrollen von CNAB-Bundles aber auch abhängig von externen Faktoren wie einer funktionierenden InternetVerbindung.
Wer schon einmal Pakete im RPM- oder DEB-Format gebaut hat, der weiß: Es gibt mittlerweile eine Armada von Hilfswerkzeugen, die einem unter anderem das Schreiben der Metadatendatei für das jeweilige Paket abnehmen. Die meisten Debian-Pakete etwa setzen dabei auf die Debhelper-Suite, um Arbeitsschritte wie das automatische Erstellen der Metadatenbeschreibung automatisch zu erledigen. Da überrascht es nicht, dass Microsoft, Docker & Co. zusammen mit dem CNAB-Standard gleich auch mehrere Werkzeuge veröffentlicht haben, die Anwendern die Nutzung von CNAB erleichtern sollen.
Drei dieser Werkzeuge spielen eine wichtige Rolle: Bei Duffle handelt es sich quasi um die Referenzimplementierung eines Werkzeugs, das Pakete nach CNABDefinition bauen kann. Zu ihm gesellt sich Porter, das sich um Duffle herumlegt und auf Wunsch Installer-Pakete erzeugt, die im Hintergrund dann das CNAB-Format nutzen. Zu guter Letzt gibt es noch Docker App, das auf Basis von Docker Compose und des CNAB-Standards wiederverwendbare Images baut, die sich hinterher sogar per Docker Hub verteilen lassen.

Duffle als gutes Beispiel

In dieselbe Richtung geht Duffle (Abbildung 3), das sich selbst ganz ungeniert als die Referenzimplementierung des CNAB-Formats bezeichnet. Es stellt dem Entwickler eine Vielzahl von Funktionen zur Verfügung, um CNAB-Pakete zu bauen. Sich in Duffle einzuarbeiten und zur ersten nutzbaren App in paketierter Form zu kommen ist nicht kompliziert. Nach der Installation von Duffle sorgt ein »duffle init« dafür, dass die lokale Entwicklungsumgebung das Licht der Welt erblickt. Im nächsten Schritt legt der Admin einen Ordner für seine Applikation an, die zwei Dateien und einen Ordner enthält: In »bundle.json« trägt er jene Metadaten ein, die CNAB nicht automatisch erraten kann, wie etwa den Namen der Maintainer eines CNAB-Bundles. Ähnliche Informationen notiert der Admin auch in der Datei »duffle.json«, die ausschließlich Duffle dient und später im CNAB-Bundle nicht mehr vorkommt. Der Ordner »cnab/« enthält alle Dateien, die für das Erstellen des Images nötig sind: Hier findet sich im Falle des trivialen Hello-World-Beispiels von Duffle [1] etwa das Dockerfile, das aus einem generischen Container einen Hello-World-Container macht. Im Ordner »app/« liegen zudem Dateien, die im Dockerfile in den Container zu kopieren sind – nur hier sucht Duffle danach.

Hat der Admin die Konfigurationsdateien des Containers angelegt, gestalten sich die folgenden Schritte trivial: Per »duffle build« legt er das CNAB-Bundle für das Hello-World-Paket an, das sich anschließend in der Docker-Registry des Hosts wiederfindet. Dann lässt sich die Applikation als CNAB-Bundle mittels »duffle install« ausrollen, und am Ende hat man einen fertigen Container auf Docker-Basis. Richtig gelesen: Duffle funktioniert aktuell ausschließlich mit Docker und benötigt auf dem jeweiligen Host, auf dem es ausgerufen wird, Docker als CLI.

Porter als Multiplattformwerkzeug

Nicht aus dem Hause Docker, sondern von Microsoft kommt die zweite Referenzimplementierung für CNAB: Porter [2]. Zwar hat man bei Microsoft in den vergangenen Jahren einige Ressourcen investiert, um Docker auf Windows zum Laufen zu bekommen, und das durchaus mit Erfolg. Primär will man in Redmond aber aus nachvollziehbaren Gründen Kunden auf die eigene Cloud lotsen. Was läge da näher, als ein Werkzeug zu bauen, das Entwicklern und Admins die Möglichkeit bietet, CNAB-Bundles direkt für Azure & Co. zu bauen? Genau in diese Kerbe schlägt Porter (Abbildung 4).
Das Prinzip funktioniert so: Erneut schreibt der Admin eine Datei, die die Metadaten des CNAB-Bundles enthält. Diese ist aber nicht identisch mit der im Bundle benötigten »bundle.json«: Vielmehr nutzt Porter die Metadatendatei später, um eben jene zu generieren. Wer übrigens JSON nicht mag, darf sich bei Porter über das etwas weniger verklammerte YAML freuen.
In der YAML-Datei hinterlegt der Entwickler alle relevanten Details. Er gibt etwa Namen und Version des CNABBundles an, legt aber auch fest, welches Invocation Image zum Einsatz kommen soll. Bei den sogenannten Mixins handelt es sich um eine Art Modul, über die sich Support für Containerumgebungen einbinden lässt. Es gibt sie – Überraschung! – beispielsweise für Azure, aber eben auch für AWS oder für ganz andere Umgebungen wie Terraform.
Anders als Duffle versteht Porter sich auf den Umgang mit den verschiedenen As-a-Service-Diensten der Clouds. Wer etwa in einem CNAB-Bundle ein MySQL braucht, kann die MySQL-Ressourcen von Azure oder AWS einbinden. Installiert man das CNAB-Bundle per Porter hinterher in einer Umgebung, startet es automatisch die nötige Datenbank.
Gleichzeitig funktioniert mit Porter auch der Rollout in Kubernetes, weil einer der unterstützten Mixins der Kubernetes-Manager Helm ist. Wer also auf einen Kubernetes-Cluster in Azure ein Wordpress ausrollen möchte, das direkt auch mit einer MySQLDatenbank in Azure redet, trägt all diese Details unmittelbar in einer Porter-Metadatendatei ein.

Per Porter zum Bundle

Hat man die »porter.yaml« für das eigene Projekt gebaut, gestaltet sich der Rest der Arbeit einfach: Per »porter build« erstellt man das Bundle, das sich hinterher etwa auch in eine OCI-kompatible Container-Registry wie Docker Hub oder in eine lokale Instanz von Quay laden lässt. Von dort kann man es mittels »porter install« lokal auch ganz leicht wieder ausrollen.
Von der Handhabung ähnelt »porter« dem Kommando »docker« durchaus. Anders als bei Docker bekommt man bei Porter aber eben das komplette Bundle, das durchaus auch Ressourcen in vielen verschiedenen Cloud-Umgebungen parallel ausrollen kann. Hier tritt klar zutage, wie praktisch CNAB als Format doch tatsächlich ist.

Docker App

Nicht unerwähnt bleiben soll die dritte Referenz für CNAB, die wieder aus dem Hause Docker kommt. Im Gegensatz zu Duffle, das lokale Bundles bauen möchte, ist Docker App [3] als Docker-Gegenstück zu Porter gedacht, allerdings mit deutlich geringerem Funktionsumfang (Abbildung 5).
Das Grundprinzip von Docker App ähnelt jenem von Porter: Mittels einer Metadatendatei beschreibt der Admin sein CNAB-Bundle, das aus diversen Docker-Images und ihrer jeweiligen Konfiguration zusammengesetzt sein darf. Dann legt er per »docker app« ein Bundle dieser App an, das die CNABSpezifikation erfüllt. Praktischerweise sorgt »docker app« aktiv dafür, dass das entstehende Bundle dem CNAB-Standard entspricht, und die Container-Registries nach OCI-Standard (wie Docker Hub) können bereits mit CNAB-Bundles umgehen. Das ist aus Admin-Sicht sehr praktisch, denn die erstellten CNAB-Bundles lassen sich auf diese Weise problemlos verteilen.

Abbildung 4: Porter entstammt der Microsoft-Feder und agiert wesentlich vielseitiger als Duffle.


Anders als Porter orientiert Docker App sich aber tatsächlich ausschließlich am Betrieb in Docker Swarm oder lokal mit Docker selbst. Die Anbindung an Kubernetes existiert über den dortigen Paket-Manager Helm ebenfalls. Damit lassen sich in Docker App gebaute Applikationen direkt in Swarm oder in einer Kubernetes-Umgebung ausrollen. Was hingegen fehlt, ist die Vielseitigkeit der Integration in unterschiedliche Kubernetes-Varianten oder in die Dienste der öffentlichen Cloud-Anbieter.
Wer etwa Kubernetes für eine Wordpress-Installation nutzen möchte, braucht dafür die erwähnte MySQL-Datenbank. Die lässt sich zwar auch in Kubernetes als Teil einer Applikation mit eigenem Container betreiben, doch bände sich der Admin auf diesem Weg eine zusätzliche Applikation ans Bein. Der Vorteil der As-a-Service-Angebote der Cloud-Anbieter ist ja gerade, dass man sich um bestimmte Basics solcher Applikationen – Replikation, Backups, Datenintegrität oder die Pflege des darunterliegenden Betriebssystems – gar nicht erst zu kümmern braucht. Docker App unterstützt das Einbinden solcher Dienste allerdings nicht und springt damit etwas zu kurz.
Unklar war zu Redaktionsschluss zudem, ob Docker App überhaupt eine Zukunft vergönnt ist: Nachdem das gesamte kommerzielle Geschäft von Docker an Mirantis gegangen ist, hat der neue Eigentümer erst mal den Stahlbesen bemüht: Nur Stunden nach der Ankündigung der Übernahme poppten auf Twitter Nachrichten auf, in denen ehemalige Docker-Entwickler nach Beschäftigungsmöglichkeiten suchten. Mirantis fährt eine harte Kubernetes-Strategie und dürfte an Docker App kein gesteigertes Interesse haben. Indes gibt es Unkenrufe, dass der Rest, der von Docker nun noch übrig ist, ja eine schöne Braut für Microsoft sein könnte. Auch das hieße für die Zukunft von Docker App aber vermutlich nichts Gutes, denn Microsoft hat ja schon das deutlich umfangreichere Porter. Wer aktuell also mit CNAB beginnt, wirft besser einen genauen Blick auf Porter und wartet ab, wie es für Docker App weiter geht.

Abbildung 5: Docker App baut aus Docker-Containern CNAB-Bundles, doch ist seine Zukunft alles andere als gesichert.


CNAB und Kubernetes?

Sinnvoll ist, die Beziehung zwischen CNAB und Kubernetes noch einmal unter die Lupe zu nehmen. Wie eingangs erwähnt, ist Kubernetes aktuell zweifelsfrei der einzige echte Shootingstar am Container-Himmel. Docker hat das im November schmerzlich zu spüren bekommen: Über Wochen hinweg hielten sich die Gerüchte, das Unternehmen stehe quasi vor dem Bankrott. Ein Ende fanden die Spekulationen erst, als Mirantis das Geschäft von Docker Enterprises übernahm. Mirantis fährt jedoch einen rigorosen Pro-Kubernetes-Kurs, und Docker war neben Microsoft eine der zentralen Triebfedern hinter CNAB. Da stellt sich die Frage, ob Docker den Ausstieg aus CNAB plant und inwiefern die Nutzung von CNAB-Paketen im Kubernetes-Kontext überhaupt Sinn ergibt. Denn schließlich hat auch Kubernetes einen eigenen Paketmanager namens Helm, der CNAB in vielerlei Hinsicht ähnelt.
Ob und wieweit CNAB und Kubernetes sich sinnvoll ergänzen können, hängt von der Frage ab, wie homogen Admins und Entwickler ihre Container-Erfahrung gestalten. Wer Kubernetes auf Blech oder in einer Cloud selbst betreibt, hat ein zentrales Problem nicht, das CNAB adSysadmin ressiert: Er hantiert im Normalfall nicht ständig mit verschiedenen Toolchains und verschiedenen Zielen für das Deployment seiner Container. Stattdessen stehen in einem solchen Anwendungsfall die Kubernetes-APIs zur Verfügung, die alle relevanten Aufgaben abwickeln, die Installation von Paketen via Helm inbegriffen.
Eine Daseinsberechtigung erlangt CNAB hingegen, wenn man eben nicht nur über die nativen Kubernetes-APIs in eine lokale Kubernetes-Instanz deployen möchte. Wer etwa Terraform nutzt oder die Kubernetes-Dienste von AWS, Azure oder Google in deren jeweiligen Clouds verwenden will, sieht sich bereits mit mehreren Werkzeugen konfrontiert. Hier helfen CNAB-Bundles, weil sie diese Komplexität wegabstrahieren. Der Admin nutzt dieselben Bundles für alle Plattformen mit einer einheitlichen Schnittstelle.

Fazit

An und für sich ist CNAB eine gute Idee. Zwar existiert für Container schon ein Paketmanager in Form von Helm, doch der ist Kubernetes-spezifisch und außerhalb des Container-Orchestrierers nicht zu verwenden. Wäre CNAB ab Werk darauf ausgerichtet, besser mit Kubernetes und Helm zu kooperieren, sodass etwa Helm CNAB-kompatible Bundles bauen und nutzen könnte, entstünde eine richtig praktische Toolchain. Stattdessen existieren die beiden Standards eher parallel. Porter bietet ein gutes Beispiel für Kubernetes-Integration Marke Eigenbau per CNAB, doch der Weisheit letzter Schluss ist das eher nicht. Obendrein steht die Zukunft von CNAB auf der Kippe, denn einem der beiden Hauptprotagonisten – Docker – ist gerade erst der kommerzielle Dampf ausgegangen. Zwar treiben mittlerweile nicht mehr nur Microsoft und Docker den Standard voran, doch ob sich der Wegfall von Docker so einfach kompensieren lässt, muss sich erst noch herausstellen.

(jcb)

Infos

[1] Duffle: [https:// github.com/cnabio/duffle]

[3] Docker App: [https:// github.com/docker/app]