© Olga_i/Shutterstock.com
Effiziente Cloud-Entwicklung mit Open-Source-Tools

Vom toten Pferd absteigen …


Die Aufgaben eines Programmierers zur Erstellung von Cloud-native-Anwendungen sind durch die veränderte Laufzeitumgebung vielfältiger, als es bei klassischen Umgebungen bisher der Fall war. In diesem Artikel wird gezeigt, wie man sich das Leben als Cloud-Entwickler erleichtern kann.

Damit eine Anwendung in Kubernetes betrieben werden kann, muss sie vorher als Docker Image paketiert werden, um sie anschließend in Kubernetes deployen zu können. Für das Kubernetes Deployment sind verschiedene Manifest-Dateien notwendig, mit denen die erforderlichen Kubernetes-Objekte angelegt werden. Erst jetzt kann mit dem Test der Anwendung in der Cloud-Umgebung begonnen werden. Bei Bugs oder neuen Features der Anwendung wiederholt sich dieser Kreislauf.

In den letzten Jahren ist eine Menge an Open-Source-Tools entstanden, die einem die Arbeit als Cloud-Entwickler erleichtern sollen. Einige dieser Tools wurden leider bereits wieder eingestellt. Um nun einen hilfreichen Mix an Tools zu finden, wird dieser Artikel die einzelnen Teilschritte aufgreifen und anhand exemplarisch ausgewählter Tools zeigen, wie man sich das Leben als Cloud-Entwickler komfortabler gestalten kann. Dabei steht die prototypische Entwicklung einer neuen Cloud-Anwendung im Vordergrund, d. h. es wird auf eine passenden CI/CD-Pipeline verzichtet. Was aber nicht bedeuten soll, dass eine solche Pipeline nicht notwendig wäre. Fast alle der vorgestellten Tools können ebenso gut in einer CI/CD-Pipeline eingesetzt werden, womit sie eine gute Basis für den Aufbau einer entsprechenden Pipeline sein können.

Einzelschritte bei der Cloud-Entwicklung

Der typische Ablauf bei der Entwicklung einer Cloud-native Anwendung besteht aus den folgenden Teilschritten:

  1. Entwicklung der Anwendung

  2. Erstellung des Docker Image

  3. Kubernetes Deployment

  4. Test und Debugging der Anwendung in Kubernetes

Während der Entwicklungsphase wiederholen sich diese Teilschritte zyklisch und fordern vom Entwickler einiges an Wissen und Erfahrung, um die notwendigen Teilergebnisse zu erstellen. Das Aufgabenspektrum reicht dabei von der Erstellung eines sogenannten Dockerfiles, aus dem das Docker Image erstellt werden kann (oder eine proprietäre Form der Definition des gewünschten Docker Image), bis hin zur Erstellung der passenden Kubernetes-Objekte in Form von Manifest-Dateien.

Auch der Betrieb der Anwendung in der Cloud bringt einiges an neuen Anforderungen mit sich, wie beispielsweise das veränderte Routing, die Verwendung von Environment-Variablen zur Konfiguration der Anwendung oder den Einsatz von Kubernetes Volumes zur Speicherung von Daten. Erst wenn die Zwischenergebnisse all dieser Teilschritte korrekt ineinandergreifen, funktioniert die Cloud-Anwendung fehlerfrei. Werden diese Schritte in einer frühen Projektphase manuell ausgeführt, birgt der Ablauf großes Potenzial an Fehlerquellen. Oft wird ein Teilschritt vergessen, wie beispielsweise das erneute Erstellen des Docker Image auf Basis der geänderten Anwendung. Diesen Fehler erkennt man dann erst wieder beim nächsten Test der Anwendung in der Cloud-Umgebung, da das Docker Image noch die alte Version der Anwendung enthalten hat. Der Einsatz nachfolgender Tools kann bei der Fehlervermeidung sehr hilfreich sein, was sich durchaus positiv auf die sogenannte Developer Experience auswirkt.

Cloud First?

In Anlehnung an die Bedeutung des Begriffs Cloud First, d. h. die Programmierung einer Anwendung mit sehr starkem Fokus auf den Betrieb in der Cloud, sollte sich der Entwickler auch möglichst frühzeitig mit den Erfordernissen der Cloud-Plattform auseinandersetzen. Zum einen muss der neue Ablauf in Fleisch und Blut übergehen, zum anderen muss man sich mit den neu zu erstellenden Artefakten auseinandersetzen. Um eine Anwendung in Kubernetes betreiben zu können, sind als Minimum ein Kubernetes Service und ein Kubernetes Deployment anhand der passenden Manifest-Dateien zu erstellen.

Jede Laufzeitumgebung hat ihre Besonderheiten, das gilt natürlich auch für Kubernetes. Je früher man sich damit vertraut macht, desto weniger wird man in kritischen Situationen davon überrascht werden. Auch der Test und das Debugging der Anwendung sollten möglichst früh in der Cloud stattfinden, um sicherzustellen, dass keine versteckten Abhängigkeiten zu Tools oder Einstellungen der lokalen Entwicklungsumgebung existieren. Seinen lokalen Entwicklungsrechner analog der Cloud-Umgebung einzurichten, ist schwierig, wenn nicht sogar unmöglich. Der einzige Ansatz, der hier empfohlen werden kann, ist der Einsatz einer lokalen Kubernetes-Umgebung. Mit

  • Minikube [1]

  • Docker Desktop [2]

  • Minishift [3]

  • CodeReady Containers [4]

existieren einige Umgebungen, die auf einem ausreichend starken Entwicklungsrechner betrieben werden können. Die ersten beiden Vertreter der Liste basieren auf reinem Kubernetes, die beiden letzten Umgebungen auf OpenShift. Minishift sollte zum Einsatz kommen, wenn OpenShift < 4.x benötigt wird, und CodeReady Containers, das seit Oktober 2019 existiert, muss bei OpenShift > Version 4.x verwendet werden. All diese lokalen Cloud-Umgebungen bieten sehr gute Dienste für den Fall, dass man keinen Zugriff auf einen echten Kubernetes-Cluster hat oder einfach mal schnell lokal etwas ausprobieren will.

Codegenerierung

Wer erste Erfahrungen mit der Java-basierten Cloud-Entwicklung machen will, kann sich mit Spring Initializr [5] oder mit MicroProfile Starter [6] ein Grundgerüst für die Cloud-Anwendung generieren. Bei Spring Initializr bekommt man leider nur sehr wenig Code-Snippets generiert, dafür kann man zwischen Maven und Gradle auswählen. MicroProfile Starter hingegen generiert für jede ausgewählte MicroProfile-Spezifikation einen passenden Sample-Code. Leider basieren die generierten Projekte nur auf Maven. Obwohl MicroProfile nur als Beta verfügbar ist, kann der Einsatz trotzdem empfohlen werden.

Erzeugung des Docker Image

Nachdem die Basis für die Cloud-Entwicklung gelegt worden ist, kommt nun der erste neue Schritt: die Erstellung des Docker Image. Hierfür müssen ein paar Entscheidungen vorab getroffen werden:

  • Darf der Docker Daemon zur Erzeugung des Docker Image eingesetzt werden?

  • Welche Basis soll für die Beschreibung des Docker Image verwendet werden? Das klassische Docker File oder eine proprietäre toolbasierte Beschreibung?

  • In welcher Build-Umgebung erfolgt die Erzeugung des Docker Image? In der Cloud-basierten CI/CD-Pipeline oder auf einem dedizierten Build-Server?

  • Soll die Erstellung des Docker Image im Anschluss an den Build-Prozess der eigentlichen Anwendung ebenfalls mit Maven/Gradle oder mittels eines separaten Tools erfolgen?

All diese Fragen sollten im Hinblick auf die gewünschte Build-Pipeline möglichst zu Anfang eines Projekts geklärt werden.

Die Verwendung des Docker Daemon bringt Vor- und Nachteile mit sich. Zum einen stellt er das passende REST API für Docker zur Verfügung, was es den Toolherstellern leichter macht, mit Docker zu kom...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang