cloudCamp − Diese Sessions haben uns begeistert

Für viel Applaus sorgte die Session von Alexander Block über kluctl. Das Open-Source-Tool hilft dir bei komplexen Deployments. Für viele Teilnehmer löst es ein Problem, das sie schon aus vielen Projekten kennen. Wo genau kluctl hilft, verrät Alex persönlich. Wir haben ihn nach seiner Session zum Tool befragt: 

Was ist die Idee hinter kluctl. Warum hast du das Tool entwickelt?

Alexander Block: kluctl ist das Ergebnis jahrelanger Erfahrungen mit Deployments, die gegen mehrere Umgebungen und Cluster gerichtet sind. Es haben sich immer wieder die gleichen Anforderungen gezeigt und keines der vorhandenen Tools war in der Lage diese vernünftig abzubilden ohne auf Glue-Code (z. B. in Form von Bash) zurückzugreifen.

In welchen Situationen hilft dir kluctl bei der Arbeit?

Alexander: kluctl hilft dir, wenn deine Deployments komplexer sind als die üblichen Beispiele und Tutorials, die man im Netz findet. Und wirklich komplex werden Deployments erst, wenn sie für unterschiedliche Umgebungen unterschiedlich ausgeprägt sein müssen (z. B. Resourcen, DNS, externe Anbindungen, Ingresse, ...). Hier zeigt kluctl seine volle Stärke, da das Konzept von − „Umgebungen“ vollständig, praktisch und flexibel integriert ist. Aber auch simple Deployments sind einfach umzusetzen, da kluctl auch dort großen Mehrwert z. B. durch diff und dry-run Features bietet.

Wie starte ich mit kluctl?

Alexander: Am besten man geht durch die Tutorials, speziell das Tutorial zur Microservices Demo. Danach sollte man die grundlegenden Konzepte von kluctl verstanden haben und selber eigene Deployments aufsetzen können. Als nächstes kann man sich je nach Bedarf durch die Referenz Dokumentation arbeiten.

Der Umgang mit Containern und Container-Images ist in der Cloud Native-Community mittlerweile ja eigentlich ein alter Hut. Allgemein bekannt ist allerdings nicht, wie genau Container-Images, und die Registries, die für deren Bereitstellung genutzt werden (beispielsweise also der Docker Hub), unter der Haube funktionieren.

Martin Helmich hatte sich für ein (internes) Projekt näher mit den dafür nötigen Dateiformaten und Schnittstellen auseinandergesetzt und gab in seiner Session einen kurzen Überblick über das OCI Image Format (welches spezifiziert, wie genau ein Container-Image aufgebaut sein muss) und die OCI Distribution Specification (die vorgibt, wie die HTTP-API einer Container-Registry auszusehen hat).

Im Hands-On-Teil zeigte sich, wie man – ausgerüstet mit diesem Wissen – mit ein paar Zeilen Go-Code seine eigene Container Registry aus dem Boden stampfen kann. Da man hier völlige Kontrolle darüber hat, wie die Image-Manifeste und die einzelnen Layer entstehen, bietet eine selbst implementierte Registry Möglichkeiten zur Image-Bereitstellung, die mit der altbekannten Kombination aus „docker build“ und „docker push“ unvorstellbar wären – beispielsweise, um potentiell zehntausende verschiedene Container-Images nach Anwenderspefizikation on-demand und ohne separaten Build-Schritt zu generieren.

Das Ganze hat natürlich seinen Preis – die gewonnenen Möglichkeiten werden mit der enormen Komplexität bezahlt, mit der sich die Maintainer so eines selbstgebauten Softwarekonstrukts herumschlagen müssen. Dementsprechend wurde in der abschließenden Diskussionsrunde hart aber fair diskutiert, ob der ganze Ansatz „vollkommener Wahnsinn“ oder „eigentlich doch ganz cool“ ist. Auch wenn sich die Teilnehmer in dieser Frage nicht einig waren, steht für Martin fest: „Mach den Mist nur, wenn du tatsächlich einen Anwendungsfall dafür hast, den du mit der ,normalen' Docker-Registry nicht bedienen kannst.“