Automatischer Image-Bau mit Tanzu Build Services

Höher, schneller, weiter

Gefühlt ist dies schon immer das Mantra der IT. Gerade im Bereich der Hardware ist sehr deutlich sichtbar, wie die Zahlen um Speicherplatz oder CPU-Takt durch die Decke gehen. Auch die Applikationsentwicklung unterliegt dem Druck immer schneller, immer besser zu werden. Allerdings ist dies auf den ersten Blick nicht immer so deutlich ersichtlich.

Stellen wir uns vor, wir haben als Unternehmen gerade eine App veröffentlicht, die bei den Usern sehr gut ankommt. Kurze Zeit später bringt unser stärkster Konkurrent eine sehr ähnliche App heraus, allerdings mit mehr Funktionen, was bei uns zu sinkenden Nutzerzahlen führt. Das ist natürlich inakzeptabel. Doch wie lange brauchen wir, um diesen Funktionsunterschied aufzuholen? Mit jedem weiteren Tag in dieser Situation verlieren wir Geld. Und genau das ist der Druck, unter dem die Entwicklungsabteilungen stehen.

Die Herausforderung

Um die eben beschriebene Situation zu lösen, gilt es viele Herausforderungen zu meistern. Eine davon ist die Frage, wie aus dem geschriebenen Quellcode eine echte Applikation wird. Auch die Antwort dieser Frage besteht aus vielen Teilschritten: angefangen von vermeintlich einfachen Aufgaben, wie dem Bedarf an einer Umgebung, in der der Quellcode kompiliert werden kann, über Fragen zu technischen Abhängigkeiten der Applikation im Betrieb, bis hin zur Pflege und Updates der Laufzeitumgebung vom Betriebssystem und benötigten Frameworks.

All das muss man nicht nur ein oder zwei Mal bewältigen, sondern unzählige Male. Zusätzlich müssen verschiedene Programmiersprachen (Python, Java, Go, PHP, …) unterstützt werden. Da die Applikationsentwicklung oft den Microservice-Prinzipien folgt, ist die Verwendung von Containern ebenfalls nahezu alternativlos. Stark vereinfacht bedeutet dies, dass sobald jemand ein git commit erstellt, ein neues Container-Image gebaut werden muss. Zu Zeiten von virtuellen Maschinen ist das aber undenkbar. Doch auch der Bau von guten Container-Images ist alles andere als trivial. Zusätzlich stellt sich die klassische Frage: „In wessen Zuständigkeitsbereich fällt das? Operations? Development?“
Die Situation schreit also geradezu nach Automatisierung!

Wir brauchen also folgendes:

1. Eine Methode, um die Sprache des Quellcodes automatisch zu erkennen und den dafür entsprechenden Compiler zu wählen.
2. Eine Umgebung, in der Quellcode kompiliert werden kann. Diese sollte gehärtet sein (immerhin verwenden wir sie in Produktion). Um Ressourcenverschwendung zu minimieren, sollte sie nur laufen, wenn es auch etwas zu tun gibt.
3. Vorlagen für die Laufzeitumgebung, welche wir mit möglichst wenigen Schritten an die Anforderungen der jeweiligen Applikation anpassen können. Selbstverständlich ebenfalls gehärtet und automatisiert.

Das Ganze sollte nach Möglichkeit nicht auf einer stark verwobenen Bash-/Powershell-/… Skriptsammlung basieren. Nicht, weil sie den Zweck nicht erfüllen könnten (da draußen gibt es wahre Meister, derartige Konstrukte zu entwickeln), sondern, weil sie immer extrem individuell sind. Daher sollte man sich auf die Suche nach einer universellen Lösung konzentrieren.

Tanzu Build Services

Hier kommen die Tanzu Build Services (TBS – https://tanzu.vmware.com/build-service) ins Spiel. Hierbei handelt es sich um eine Lösung von VMware, die genau die zuvor beschriebenen Herausforderungen adressiert. Die Tanzu Build Services sind in VMware’s Tanzu Portfolio zwar bei den Development-Tools zu finden, in der Realität stellen sie aber genau die Schnittstelle zwischen Betrieb und Entwicklung dar. Man könnte sie also als DevOps-Tool bezeichnen.

Die Tanzu Build Services selbst basieren auf den im OpenSource-Umfeld bekannten Cloud-Native Buildpacks. Diese wurden ursprünglich von Heroku und Pivotal entwickelt und nun durch VMware um zusätzliche Teile erweitert. Die klassischen Funktionen sind dabei jedoch ebenfalls erhalten geblieben. Was genau der Mehrwert der Tanzu Build Services gegenüber der reinen OpenSource Lösung ist, sehen wir weiter unten.

Die Bestandteile

(Cluster) Stack

Ein Stack beinhaltet die Basis-Container-Images, welche sowohl für die Build-Umgebung (zum Kompilieren des Quellcodes) als auch für die Run-Umgebung (zur Ausführung der Applikation) verwendet werden. Stacks bestehen also immer aus zwei Basis-Images. VMware stellt hier zwei verschiedene Basis-Images zur Verfügung. Abhängig vom jeweiligen Verwendungszweck gibt es sie in verschiedenen Ausbaustufen:

Ubuntu 18.04 (Bionic Beaver)

tiny

• Go apps
• Java GraalVM Native Images

base

• Java apps
• .NET Core apps
• Go apps inkl. verschiedener C-Libraries
• Node.js
• Python / Ruby Apps mit wenigen native-Extensions

full

• Python / Ruby Apps mit vielen native-Extensions
• PHP
• Node.js
• …

Microsoft Windows Server Core LTSC 2019

• NET Framework Applikationen
• .NET Core Apps mit Abhängigkeiten zum Windows Betriebssystem

Theoretisch ist es allerdings auch möglich, eigene Images hinzuzufügen.

ClusterStores

Der ClusterStore beinhaltet die verschiedenen Buildpacks, welche zur Verwendung freigegeben werden sollen. Die Tanzu Build Services haben bereits eine Sammlung verschiedener Buildpacks an Board, wie z.B. Java, Nodejs, Go, PHP, nginx und httpd. Auch hier ist es möglich, weitere Buildpacks hinzuzufügen. Dabei ist es egal, ob sie aus anderen Quellen stammen oder sogar selbst gebaut sind.

(Cluster)Builder

Bei dem Builder handelt es sich eher um einen Prozess, als um eine Komponente. Hier laufen Stack und Buildpack zusammen, um das Image zu bauen und dieses letztendlich in eine Container-Registry zu pushen. Zusätzlich überwacht der Builder permanent sowohl das Git Repository, in dem der Sourcecode liegt, als auch die Base-Images im Stack. Sollte sich bei einem der beiden eine Änderung ergeben (z.B. eine CVE Hotfix im Base-Image oder eine neue App-Version), wird automatisch ein neues Image gebaut.

(Container)Images

Bei dem Image handelt es sich um das fertigstellte Container-Image, welches in die Container Registry gepusht wurde und nun auf seinen Einsatz wartet.

Tanzu Build Services – Mehrwert

Wie bereits oft erwähnt, sind die Cloud-Native-Buildpacks OpenSource. Nun könnte man dazu tendieren, diese vermeintlich kostenlose Variante zu nutzen. Technisch wäre dieser Ansatz auch durchaus valide. Gleichzeitig erhöht es den Aufwand deutlich. Denn das würde bedeuten, dass sowohl die Buildpacks als auch die Stacks entweder selbst entwickelt werden müssten oder man sich eine vertrauenswürdige Quelle dafür suchen müsste, welche all das bietet, was benötigt wird.

VMware hingegen bietet bereits von Haus aus sehr viele Buildpacks zur Verwendung an.
Diese werden auch kontinuierlich aktualisiert. Die ebenfalls von VMware bereitgestellten Stacks sind nicht nur grundlegend gehärtet, sondern werden mehrfach monatlich gepatcht. Zusätzlich dazu gibt es Support im Problemfall.

Die Frage ist also, haben wir genug Personen in unseren Teams, welche sowohl die Zeit als auch die Kenntnisse haben, sich um diese Themen zu kümmern? Und das nicht nur temporär zur initialen Einrichtung, sondern durch die ganze Laufzeit hinweg.

Fazit

Zurück zum fiktiven Szenario vom Anfang. Selbstverständlich haben wir die die besten Entwicklungsteams und diese sind sehr schnell darin, erforderliche Anpassungen im App-Quellcode vorzunehmen. Leider ist die App damit noch nicht in Produktion aktualisiert.

Die Tanzu Build Services bieten eine gute Möglichkeit genau hier anzusetzen und den Build-Prozess gleichzeitig zu vereinfachen und zu automatisieren. Das führt letzten Endes zu einem schnelleren Go-To-Market.

Da die Tanzu Build Services keine VMware spezifischen Anforderungen an die darunterliegende Plattform haben, sind sie potenziell für jede CNCF-konforme Kubernetes-Umgebung interessant. Egal ob Rancher, OpenShift oder selbst gebaut.