Cloud Foundry als Basis wirklich unabhängiger Services

Anwendungen einfach in jeder Cloud betreiben mit Cloud Foundry
Keine Kommentare

Microservices-Architekturen sind in aller Munde, und selbst so mancher Fachbereich fängt an, sie als Basis neuer Anwendungen zu fordern. Das Ganze muss man dann nur noch in der Cloud bereitstellen, und schon kann man ganz schnell und ohne lästige IT-Prozesse, Hardwarebeschaffung oder Betriebsstrukturen Wünsche erfüllen. Oder?

In der Realität sieht das dann doch etwas anders aus. Neben dem Erstellen der eigentlichen Anwendung wird noch die konkrete Laufzeitumgebung benötigt. Die verschiedenen Cloud-Anbieter bieten hier proprietäre Lösungen an, bei denen man an bestimmte Technologien oder auch den Betreiber gebunden ist. Schon früh im Projekt erfolgt oft die Festlegung auf eine spezifische Zielumgebung. Die unterschiedlichen Dienstleister bringen dabei oft ihre präferierte Variante mit. Dieses Festlegen auf Anbieter und Technologie versucht Cloud Foundry nun zu umgehen. Cloud Foundry ist Open Source und eine Platform-as-a-Service-(PaaS-)Lösung  auf Basis einer Diego-Architektur, mit der sich native Cloudanwendungen schnell und einfach entwickeln, verteilen und skalieren lassen. Cloud Foundry stellt selbst nur den erforderlichen Softwarestack zur Verfügung, der dann von verschiedenen Anbietern genutzt wird. Unter cloudfoundry.org findet man eine Liste der aktuellen zertifizierten und nicht zertifizierten Anbieter einer Cloud Foundry-Plattform. Die SAP Cloud Platform oder Pivotal Cloud Foundry sollen hier besonders hervorgehoben werden, da man für seine PaaS-Lösung einen Infrastrukturanbieter aus verschiedenen Optionen (AWS, Google, OpenStack, Azure etc.) auswählen kann. Im Rahmen dieses Artikels wird die Application Runtime in den Fokus gestellt. Parallel dazu gibt es noch eine Container-Runtime, die für den Betrieb von Kubernetes-Clustern geschaffen wurde. Auch Docker Images lassen sich über Cloud Foundry betreiben.

Die Kommandozeile als gemeinsame Sprache

Die Unabhängigkeit in der Verwendung von verschiedenen Cloud-Anbietern ist bei Cloud Foundry also prinzipiell gegeben. Für die Steuerung der eigenen Anwendungen und Services haben die verschiedenen Anbieter entsprechende Oberflächen geschaffen. Cloud Foundry bietet außerdem ein eigenes CLI-Programm, mit dem alle notwendigen Aufgaben direkt erfüllt werden können. Das CLI besitzt oft mehr Funktionen als die Oberflächen der Hersteller.

Tabelle 1 zeigt die wichtigsten Befehle. Soll eine Anwendung auf einer Cloud-Foundry-Plattform bereitgestellt werden, muss man sich natürlich erst einmal anmelden. Dazu registriert man sich vorher beim gewünschten Dienstanbieter und sucht dort den erforderlichen API-Endpunkt. Je nach Anbieter und Rechenzentrum gibt es unterschiedliche Endpunkte. Während des Log-ins über das CLI werden alle notwendigen Daten abgefragt und der angegebene API-Endpunkt wird gespeichert. Will man einen anderen Endpunkt haben, muss man ihn hier explizit wechseln. Eine Abfrage des Endpunkts erfolgt danach nicht mehr. Gerade wenn man mit vielen Plattformen experimentiert, sollte man darauf achten, dass immer der richtige Endpunkt gewählt ist.

Befehl Kurzbeschreibung
cf login Anmelden an der entsprechenden Cloud-Plattform; wurde bisher noch keine Anmeldung durchgeführt, werden alle notwendigen Parameter abgefragt
cf push Die Daten einer Anwendung werden über den Cloud Controller in den Blobstore kopiert, das entsprechende Buildpack wird zum Bauen verwendet und ein Droplet erstellt. Das Droplet wird direkt in der nötigen Anzahl an Instanzen ausgeführt (wenn gewünscht).
cf buildpacks Listet alle in der Plattform vorhandenen Buildpacks auf. Die Reihenfolge zeigt gleichzeitig die Priorität einzelner Buildpacks.
cf marketplace Über dieses Kommando werden alle Dienste aufgelistet, die ein Nutzer in seiner Organisation bzw. auf seinem Space verwenden kann. Zu jedem Service können dabei die entsprechenden Versionen und Service-Pläne (Kosten) abgefragt werden.
cf services Listet alle Service-Instanzen auf, die dem eigenen Space zugeordnet sind. Die Instanziierung erfolgt dann über die Kommandos create-service; update-service; delete-service.
cf service Zu jeder Service-Instanz können weitere Informationen abgefragt werden. Zum Beispiel kann gezeigt werden, welche Anwendung den Service nutzt. Zum Binden des Service mit einer Anwendung kommen die Befehle bind-service; unbind-service zum Einsatz.
cf scale Weist einer Anwendung neue Ressourcen zu (Arbeitsspeicher, Plattenplatz oder Anzahl der Instanzen); bei Bedarf kann hier auch direkt ein Neustart forciert werden.
cf logs Zeigt die aktuellsten Logeinträge zu einer Anwendung an.
cf events Zeigt die aktuellsten Events zu einer Anwendung an.
 Eine vollständige Liste aller Befehle findet man unter Cloud Foundry CLI

Tabelle 1: Wichtige Befehle des Cloud Foundry CLI

Wie bekommt man nun die eigene Anwendung in die Cloud, und welche Programmiersprache sollte verwendet werden? Abbildung 1 zeigt vereinfacht den entsprechenden Ablauf. Über das CLI werden beim Aufruf des push-Befehls alle Informationen zur Anwendung an Cloud Foundry übertragen. Der Cloud-Foundry-Controller sucht das entsprechende Buildpack aus. Ein Buildpack definiert, wie aus den Quelldateien eine fertige Anwendung gebaut werden soll. Das Ergebnis des Bauens ist ein sogenanntes Droplet, das gespeichert und über die Diego-Schicht in die einzelnen Zellen/Container verteilt wird. Das Droplet enthält die fertige lauffähige Anwendung mit allen notwendigen Bibliotheken. Zum Beispiel kann eine dynamische Webanwendung im Droplet einen kompletten Tomcat-Server mit zugehöriger Applikation enthalten. Das Buildpack erstellt also aus einer losen Sammlung von Artefakten eine ausführbare Anwendung.

Abbildung 2 zeigt die in der SAP Cloud Platform vorhandenen Buildpacks. Die automatische Auswahl des Buildpacks erfolgt mithilfe der übermittelten Inhalte. So wird zum Beispiel für eine Node.js-Anwendung nach der Datei packages.json gesucht. Die Position der Buildpacks in der Auflistung bestimmt gleichzeitig deren Priorität. Es wird immer das Buildpack verwendet, das sich als Erstes zuständig fühlt. Die Verwendung eines Buildpacks kann aber auch im push festgeschrieben werden. Welcher Mechanismus für das Bauen der Anwendung verwendet wird, ist wiederum durch die Buildpacks definiert (zum Beispiel Maven oder Gradle für Java-Anwendungen). Theoretisch können für beliebige Programmiersprachen eigene Buildpacks definiert werden, jedoch gibt es hier bei den verschiedenen Anbietern kein einheitliches Vorgehen zur Einspielung von eigenen Buildpacks.

Abb. 1: Ablauf der Bereitstellung einer Anwendung

Abb. 1: Ablauf der Bereitstellung einer Anwendung

 

Abb. 2: Buildpacks der SAP Cloud Platform

Abb. 2: Buildpacks der SAP Cloud Platform

Mit dem push wird die Anwendung auch gleichzeitig gestartet, was bei Bedarf aber verhindert werden kann. Der dargestellte Ablauf ist dabei unabhängig von der gewählten Implementierungstechnologie oder dem Cloud-Anbieter.

Die Anwendung läuft nun in der Cloud, aber welche Anforderungen werden eigentlich an ihre Entwicklung gestellt?

Grundlage einer Anwendung: die Twelve-Factor App

Die Basis für die Umsetzung bilden die Prinzipien der Twelve-Factor App [4]. Abbildung 3 zeigt die zwölf Kriterien, an denen sich Cloud-Foundry-Anwendungen orientieren sollten. Diese Merkmale haben einen direkten Einfluss auf die Architektur von Cloud-Foundry-Plattformen und führen zu bestimmten Umsetzungsmustern. Auf einige der Punkte soll hier näher eingegangen werden.

III. Config – store config in the environment: Alles, was sich zwischen Umgebungen (Produktion, Test etc.) unterscheidet, darf nicht im Code-Repository abgelegt werden. Alle erforderlichen Konfigurationen sollen als Umgebungsvariablen abgelegt werden. Die Namen der Variablen sind dabei so zu wählen, dass sie keinen Rückschluss auf die Umgebung liefern, aber ihre Bedeutung einfach ersichtlich wird. Abbildung 4 zeigt eine von Cloud Foundry automatisch angelegte Umgebungsvariable (am Beispiel IBM Bluemix). Diese Variable bezieht sich direkt auf die Regel

IV. Backing services – Treat backing services as attached resources: Ein Backing Service ist dabei eine beliebige Ressource, welche die Anwendung über ein Netzwerk bezieht. Es ist dabei unerheblich, ob die Ressource lokal oder remote vorhanden ist. Ihr Austausch sollte jederzeit ohne Anpassung der Anwendung möglich sein. Beispiele für Ressourcen wären Datenbanken, Mail- oder Caching Services. Im gerade genannten Beispiel sieht man die Konfiguration für eine angebundene Cloudant-Datenbank. Die Parameter für Services werden immer unter der Variable VCAP_SERVICES abgelegt. Je nach verwendeter Programmiersprache gibt es bereits fertige Bibliotheken, die Dienstinformationen direkt aus dieser Variable verwenden. Im Java-Umfeld kann zum Beispiel auf den Spring Cloud Spring Service Connector zurückgegriffen werden.

Abb. 3: Kriterien der Twelve-Factor App

Abb. 3: Kriterien der Twelve-Factor App

 

Abb. 4: Umgebungsvariable in IBM Bluemix (Screenshot von [6])

Abb. 4: Umgebungsvariable in IBM Bluemix (Screenshot von hier)

Ein weiteres wichtiges Kriterium ist VI. Process – Execute the app as one or more stateless processes: Die Anwendung muss in der Lage sein, auf verschiedenen parallelen Serverinstanzen zu laufen; sie arbeitet deshalb zustandslos. Jede Anfrage wird als neuer Request gewertet. Zustände werden durch die Verwendung von Backing Services persistiert. In Cloud-Foundry-Umgebungen läuft dazu jede Anwendungsinstanz in genau einem Prozess. Wird mehr Rechenleistung benötigt, wird dies über die Anzahl der Instanzen definiert. Alle vorhandenen Anwendungsinstanzen teilen sich dabei die zur Verfügung stehenden CPU-Kapazitäten. Somit kann keine Anwendungsinstanz die CPUs zum Einfrieren bringen. Arbeitsspeicher und Speicherplatz einer Anwendungsinstanz können flexibel definiert werden.

Beim Logging (XI. Logs – Treat logs as event streams) werden alle Nachrichten immer auf den Standard Output Stream geschrieben. Es erfolgt kein Logging in das Filesystem oder gegen einen spezifischen Service. Cloud-Foundry-Plattformen kümmern sich dann um das Sammeln der Logs und stellen entsprechende Möglichkeiten zur Auswertung zur Verfügung. Die Logs werden zentral gesammelt. Wenn man die Einträge mit einer eindeutigen ID (Correlation id) versieht und sie für Nutzeranfragen konsistent verwendet, lassen sich Prozessabläufe über verschiedene Services hinweg analysieren. Gerade bei der Behebung von Fehlern ist das sehr hilfreich.

Komponenten einer Cloud-Foundry-Plattform

Damit die Anwendungen und Dienste ausgeführt werden können und dabei für unterschiedliche Aspekte des Lebenszyklus fertige Lösungen existieren, werden verschiedene Komponenten in der Architektur zum Einsatz gebracht. Abbildung 5 zeigt alle beteiligten Bausteine einer Cloud-Foundry-Umgebung. Auch wenn einzelne Cloud-Anbieter hier eigene Erweiterungen zur Verfügung stellen, findet man die Grundstrukturen immer wieder. Der erste Einstiegspunkt in eine Anwendung ist der Router. Alle Anfragen werden über diese Komponente geleitet. Der Router weiß, wo eine spezielle Anwendung bzw. ein spezieller Service zu finden ist. Wenn der Weg zur Anwendung bekannt ist, muss geprüft werden, ob der aktuelle Nutzer überhaupt eine Berechtigung zur Verwendung hat.

Die Komponente User Account and Authentication (UAA) prüft die Anmeldedaten des Nutzers unter Verwendung des OAuth-2.0-Protokolls über den Log-in-Server. Gleichzeitig werden die Berechtigungen auf einzelne Dienste und Ressourcen verifiziert. Das Deployment der Anwendungen erfolgt über den Cloud Controller, der sicherstellt, dass die notwendige Anzahl an Instanzen der Anwendungen gestartet ist. Er triggert das Diego Brain zum Stagen und Ausführen der Applikationen in den erforderlichen Diego-Zellen. Das sind die virtuellen Maschinen, in denen eine einzelne Anwendungsinstanz (oder auch ein Docker Image) läuft. Die Komponenten nsync, Cell Reps und BBS monitoren die einzelnen Zellen und ihren Zustand. Wenn erforderlich, werden Instanzen durch diese Komponenten automatisch gestartet oder gestoppt. Im Fehlerfall einer Instanz wird diese somit ohne Notwendigkeit einer Nutzeraktion aufgeräumt und neu gestartet.

Abb. 5: Komponenten der Cloud-Foundry-Architektur

Abb. 5: Komponenten der Cloud-Foundry-Architektur

Im Kern der Architektur stehen der Blobstore und die Diego App Execution (Laufzeitumgebung der Diego-Zelle). Der Blobstore ist ein Repository für große Dateien, in dem alle relevanten Informationen abgelegt werden. Dazu zählen die Anwendungsdaten, die Buildpacks und die fertigen Droplets. Wird eine neue Anwendungsinstanz erzeugt, wird das Droplet aus dem Blobstore geholt und in der Diego App Execution zur Ausführung gebracht.

Der Mehrwert und leider auch die Unterschiede der verschiedenen Plattformanbieter entstehen über die bereitgestellten Services. Ein Service ist ein Stück Software, das über den Marktplatz zur Verfügung gestellt wird. Jeder Service kann in verschiedenen Varianten zu unterschiedlichen Kosten angeboten werden. Beispiele für Services sind u. a. Datenbank-/Messaging-Systeme oder komplexe Dienste, die Adressdaten validieren oder Steuerinformationen für globale Anwendungen anbieten. Services werden von den Cloud-Anbietern oder Drittdienstleistern bereitgestellt. Abbildung 6 zeigt einen Auszug der Services im SAP Cloud Platform Cockpit. Möchte eine Anwendung einen Service nutzen, nimmt der Service Broker die entsprechende Anfrage entgegen und legt eine Instanz des Service an. Diese Instanz kann dann an verschiedene Anwendungen gebunden werden. Der Router wird über die Bindungen der Services zu Anwendungen informiert. Die relevanten Service-Daten werden automatisch in die entsprechende Umgebungsvariable geschrieben. Bei mehrstufigen Umgebungen (Development, Test, Produktion etc.) legt man so je eine Instanz pro Umgebung an. Für die Anwendung ist es transparent, welcher Umgebung der Service zugeordnet ist.

DDD Summit 2018

Event Storming für Domain-Driven-Design

mit Nicole Rauch (Softwareentwicklung und Entwicklungscoaching)

Der Nachrichtenaustausch unterhalb der einzelnen VMs geschieht über HTTP(S). Zwei Komponenten kommen beim Speichern temporärer Nachrichten und Daten zum Einsatz: Das Diego Bulletin Board System (BBS) speichert Informationen, die oft aktualisiert oder entfernt werden, zum Beispiel der Anwendungsstatus. Der Consul Server sichert langlebige Kommunikationsdaten wie IP-Adressen. Über den NATS Messaging Bus werden die Routeninformationen an die verschiedenen Router verteilt. In der letzten Schicht sind die Komponenten für Metriken und Logging definiert. Der App Log Aggregator unterstützt den Logging-Ansatz für eine Twelve-Factor App. Alle relevanten Loginformationen und Metriken werden gesammelt und konsolidiert. Die Anwendungen selbst, das Deployment und auch die Cloud-Foundry-Komponenten sind Quellen für Lognachrichten. Neben der Unterstützung in der Analyse von Fehlern können über diese Komponente auch Rückschlüsse auf das Nutzungsverhalten von Anwendungen gezogen werden. Weitere Informationen zur Diego-Architektur sind hier zu finden.

Abb. 6: Service-Marktplatz in der SAP Cloud Platform (Screenshot von [8])

Abb. 6: Service-Marktplatz in der SAP Cloud Platform (Screenshot von hier)

Die grundlegende Architektur ist nun bekannt, und auch eine Anwendung läuft schon in der Cloud, aber wo wird eigentlich festgelegt, welche Ressourcen eine Anwendung nutzen kann? Die entsprechenden Informationen werden über die folgenden Stufen ermittelt:

  • Parameter beim Push über die Kommandozeile
  • Definition im Manifest der Anwendung
  • Aktuell verwendete Anwendungseinstellung
  • Standardwert des Cloud-Anbieters
  • Cloud-Foundry-Standardwert (aktuell 1 GB für Arbeitsspeicher und Plattenplatz)

Die gebräuchlichste Variante ist die Definition der Werte in der Datei manifest.yml. Listing 1 zeigt eine entsprechende Konfiguration. In einer Datei können mehrere Anwendungen beschrieben werden. Details zu den einzelnen Werten sind in Tabelle 2 aufgezählt. Alle Werte sind optional und müssen nicht spezifiziert werden. Die vollständige Dokumentation findet sich hier. In der Konfigurationsdatei gibt es auch Einträge für die Abfrage des Zustands einer Anwendung. Cloud Foundry versucht regelmäßig (alle 30 Sekunden) zu prüfen, ob eine Anwendung noch korrekt funktioniert, wobei drei verschiedene Varianten zum Einsatz kommen können. Als Standard findet eine Prüfung des Ports statt. Hier wird versucht, eine Verbindung zum zugeordneten Port der Anwendung aufzubauen.

Ist dies erfolgreich, geht Cloud Foundry davon aus, dass die Anwendung noch korrekt läuft. Alternativ kann der Prozess selbst geprüft werden (Parameter: process). Solange der Prozess noch existiert und nicht abgestürzt ist, gilt die Anwendungsinstanz als gesund. Das hat natürlich den Nachteil, dass Deadlock-Zustände nicht erkannt werden können. Die größte Flexibilität bietet ein HTTP Check (Parameter: http). Bei dieser Prüfung wird ein URL innerhalb der Anwendung aufgerufen, und dieser Aufruf muss innerhalb von einer Sekunde mit dem Statuscode 200 antworten. Als Entwickler kann man so spezifische Prüfungen zur Ermittlung des Zustands einbauen, muss jedoch immer im geforderten Zeitfenster für eine Antwort liegen. Welche Prüfung man wählt, hängt vom Typ der Anwendung ab. Eine reine Scheduler-Applikation, die nicht auf Request von außen achtet, wird man sicherlich nicht über HTTP monitoren wollen.

---
applications:
- name: sample-app
  memory: 526M
  disk_quota: 1024M
  instances: 5
  path: target/sample-app.war
  buildpack: sap_java_buildpack
  health-check-type: http
  health-check-http-endpoint: /health

  services:
  - postgres-sample-app
  - uaa-sample-app
  
  routes:
  - route: mysampleapp.info
  
  env:
  - CUSTOMVAR: samplevalue
Konfiguration Kurzbeschreibung
name Jede Anwendung muss einen Namen haben. Steht der Name nicht in der manifest.yml, muss er beim Push mit angegeben werden.
memory  Arbeitsspeicher, der von einer Anwendungsinstanz benötigt wird.
disk_quota Plattenplatz, der von einer Anwendungsinstanz benötigt wird.
instances Anzahl der Instanzen, die standardmäßig verwendet werden sollen. Diese Angabe kann zur Laufzeit flexibel angepasst werden.
path Pfad zur Anwendung, die Cloud Foundry ausführen soll.
buildpack Angabe zum Buildpack der Anwendung; dieser Wert sollte angegeben werden, wenn man die Auswahl nicht dem Cloud-Foundry-Mechanismus überlassen möchte. Außerdem kann hier auch ein Repository angegeben werden, das ein individuelles Buildpack enthält.
health-check-type Angabe, wie der Zustand einer Anwendungsinstanz ermittelt werden soll. Die Werte port, process und http sind möglich. Der Standardwert ist port.
health-check-endpoint Für den Health Check Type http muss der zugehörige Endpunkt konfiguriert werden.
services Auflistung der Service-Instanzen, die von der Anwendung verwendet werden.
routes Angabe aller Routen, über die die Anwendung erreicht werden kann. Die Routeninformationen werden für den Router angelegt, wenn sie noch nicht existieren. Jede Anwendung muss über einen eindeutigen Routeneintrag verfügen. Über den Parameter random-route: true kann die Definition einer Route komplett Cloud Foundry überlassen werden.

Tabelle 2: Parameter in der „manifest.yml“

Strukturierung von Anwendungen

Ein wichtiger Aspekt in der Verwendung von Cloud Foundry fehlt noch. Bisher sind keine Gesichtspunkte der Anwendungsstrukturierung und Sicherheit näher betrachtet worden. Den obersten Einstieg bildet die Organisation. Eine Organisation bündelt die Aktionen einer spezifischen Anwendergruppe und kann zum Beispiel Unternehmensstrukturen oder Anwendungen abbilden. Auf einer Organisation können globale Einstellungen vorgenommen oder auch Rechte vergeben werden, eine Organisation kann jedoch keine Anwendungen oder Services ausführen. Unterhalb einer Organisation sind sogenannte Spaces definiert.

Ein Space beinhaltet konkrete Services und Applikationen. Über einen Space könnte man verschiedene Anwendungsstufen abbilden. Zum Beispiel definiert man pro Anwendung eine Organisation und unterhalb jeder Organisation gibt es je einen Space für Entwicklung, Test, QA und Produktion. Nutzer der Plattform werden über Useraccounts abgebildet. Diese Nutzer können durch Cloud Foundry verwaltet oder über einen Authentifizierungsprovider (LDAP oder SAML) eingebunden werden. Rollen und Rechte können Nutzern dann innerhalb einzelner Organisationen, Spaces, Anwendungen oder auch Services zugewiesen werden.

Für jede Organisation und jeden Space können Quotas hinterlegt werden, über die geregelt ist, welche System- und Serviceressourcen zur Verfügung stehen. Neben dem klassischen Speicherverbrauch wird so auch definiert, wie viele Instanzen eines Service nutzbar sind. Spaces können natürlich nicht mehr Ressourcen verbrauchen, als über Organisation angegeben wurde. Für die Berechtigungsvergabe existieren in Cloud Foundry fünf essenzielle Rollen:

  • Administrator besitzt alle Rechte auf einer Organisation/einem Space.
  • Manager kann Gruppen von Nutzeraccounts verwalten, hat aber kein Recht, Anwendungen zu deployen.
  • Auditor kann nur Informationen sehen, aber keine Veränderungen durchführen.
  • Billing erlaubt ähnlich Auditor nur lesende Zugriffe, jedoch sind die Inhalte noch weiter eingeschränkt. Diese Rolle ist primär für die Abwicklung/Prüfung der Abrechnung von verbrauchten Ressourcen relevant.
  • Developer kann die einzelnen Anwendungen deployen und Dienste konfigurieren.

Diese beschriebenen Strukturen werden von Cloud Foundry verwendet, um die Plattform zu managen. Für Berechtigungsmodelle innerhalb der Anwendung ist der Entwickler selbst zuständig. Die unterschiedlichen Cloud-Anbieter bieten hier aber meist auch entsprechende Unterstützung an. Gleichzeitig definieren Cloud-Anbieter manchmal noch Metastrukturen oberhalb der Organisation (zum Beispiel kennt die SAP Cloud Platform hier noch den Global Account und den Subaccount). Diese Strukturelemente können gerade bei großen Projekten oder in größeren Unternehmen sinnvoll zur Vereinfachung des Aufbaus der Hierarchien beitragen.

Zero-Downtime mit vertretbarem Aufwand

Die Cloud-Foundry-Architektur und der Twelve-Factor-Ansatz bieten optimale Voraussetzungen, um Anwendungen/Services ohne Downtime zu betreiben. Alte Anwendungsinstanzen können bei einer Aktualisierung ihre Arbeit noch beenden. Die neue Version wird als Droplet vorbereitet und kann direkt gestartet werden. Diese Art der Deployments wird auch als Blue/Green-, Black/Red- oder auch A/B-Deployment bezeichnet.

Es gibt von einer Anwendung immer zwei Versionen: die Vorgängerversion mit der aktuellen Version und die aktuelle Version mit der Nachfolgerversion. Der Router prüft, welche Version momentan die richtige für den Produktiveinsatz ist und leitet die Anfragen entsprechend weiter. Abbildung 7 zeigt grob den Prozess. Mit push wird eine neue Version in Produktion gebracht, die noch deaktiviert ist und dann aktiv gestartet wird. Die alte Version wird deaktiviert, wobei sie noch laufende Anfragen zu Ende bearbeitet. Sollten nach dem Wechsel Fehler auftreten, kann wieder auf die alte Version gewechselt werden. Treten keine Fehler auf, könnte die alte Version gelöscht werden. Sie kann aber so lange erhalten bleiben, bis eine neue Version eingespielt werden soll.

Abb. 7: Blue/Green-Deployment

Abb. 7: Blue/Green-Deployment

Fazit

Mit Cloud Foundry und den dazugehörigen Cloud-Anbietern gibt es eine stabile Basis, um unabhängige Anwendungen und Services zu betreiben. Für viele relevante Fragen des Anwendungsbetriebs (Monitoring, Logging, Zero-Downtime Deployment etc.) werden Antworten geliefert und man muss nicht das Rad neu erfinden. Bei konsequenter Beachtung der Prinzipien einer Twelve-Factor-Anwendung kann eine einfache Migration zwischen den Plattformen gelingen. Wie in der klassischen Anwendungsentwicklung, muss aber auch hier in der Implementierung darauf geachtet werden, dass man sich nicht doch in eine zusätzliche Abhängigkeit begibt. Zum Beispiel bieten verschiedene Anbieter Bibliotheken an, die das Implementieren vereinfachen, aber eben auch neue Abhängigkeiten schaffen. Bei Umsetzung von Microservices-Architekturen sollte man immer auch Cloud-Foundry-Umgebungen als Laufzeit in Betracht ziehen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -