Suchen

Cloud-agnostische Softwareentwicklung, Teil 2 Ausfallsicherheit mit Cloud Foundry

| Autor / Redakteur: Filipe Martins & Anna Kobylinska / Stephan Augsten

Cloud Foundry verspricht Entwicklern die Flexibilität Cloud-agnostischer Anwendungsportabilität, den Heiligen Gral der Hochverfügbarkeit. Doch die Befreiung vom Vendor-Lock-In erfordert Disziplin und neue Ansätze der Qualitätssicherung.

Firma zum Thema

Für mehr App-Robustheit: Das Chaos Toolkit hilft bei der Automatisierung von Chaos-Engineering-Experimenten.
Für mehr App-Robustheit: Das Chaos Toolkit hilft bei der Automatisierung von Chaos-Engineering-Experimenten.
(Bild: chaosIQ)

Die „Cloudifizierung“ der Softwareentwicklung ist ein zweischneidiges Schwert. Das Pay-as-you-go-Finanzierungsmodell hat es Unternehmen ermöglicht, ihre IT-Kapazitäten bedarfsgerechter zu skalieren. Doch die Kehrseite dieser Medaille ist die Gefahr des Vendor-Lock-Ins an den Cloud-Provider: eine dauerhafte Abhängigkeit von den APIs des IaaS-Anbieters.

Die Portabilität von Softwarecode zwischen verschiedenen Cloud-Umgebungen ist für viele Unternehmen aus diesem Grunde nicht verhandelbar. Die quelloffene Plattform Cloud Foundry schafft vielerorts Abhilfe, unter anderem bei der nordamerikanischen Tochter der deutschen T-Mobile. T-Mobile USA hat sich für ihre branchenunübliche Innovationskraft einen Namen gemacht: der „Un-carrier“ (also etwa „Nicht-Netzbetreiber“).

Konzentration aufs Wesentliche: In Cloud Foundry kümmert sich der Entwickler „nur“ um die eigene App und ihre Daten.
Konzentration aufs Wesentliche: In Cloud Foundry kümmert sich der Entwickler „nur“ um die eigene App und ihre Daten.
(Bild: Cloud Foundry)

Die Entwicklung Cloud-nativer, infrastrukturagnostischer Apps in Cloud Foundry folgt einigen klaren Design-Richtlinien. Solange Entwickler diese Grundsätze einhalten, können Apps, die in unterstützten Frameworks geschrieben wurden, in Cloud Foundry oft einfach unverändert laufen und den Infrastrukturunterbau bedarfsgerecht (sogar in Nahezu-Echtzeit) wechseln. So kommen Entwickler in den Genuss infrastrukturagnostischer Anwendungsausführung.

Cloud-native Anwendungen in der Storage-Zwickmühle

Der lokale Dateisystemspeicher einer VM oder eines Containers ist isoliert und kurzlebig. Somit läuft auch jede Instanz einer Cloud-nativen Anwendung in einer eigenen, isolierten Umgebung ab. Das lokale Dateisystem einer Instanz ist für die anderen Instanzen der App unzugänglich.

Cloud-native Anwendungen sollten daher niemals Daten auf den lokalen Speicher der jeweiligen Instanz schreiben. Wenn die Anwendung dennoch auf den lokalen Speicher schreibt, können diese isolierten Daten jederzeit verloren gehen. Sollte nämlich eine App-Instanz abstürzen oder angehalten werden, werden ihre Infrastrukturressourcen freigegeben.

Alle Änderungen an dem lokalen Datenspeicher seit der Initialisierung der jeweiligen Instanz gehen zu diesem Zeitpunkt unwiederbringlich verloren. Denn bei der Neuinitialisierung der Instanz startet die App immer mit einem neuen sauberen Festplattenimage neu (nicht mit einer Replika des letzten Zustands des lokalen Speichers!). Obwohl eine Cloud-native App lokale Dateien durchaus schreiben kann, gehen diese also bei jedem Neustart der App verloren.

Cloud-Foundry- oder kurz CF-Apps sollten aus diesem Grunde vorzugsweise einen gemeinsam genutzten Datenspeicher wie Amazon S3 oder eine Datenbank (etwa MongoDB, MySQL oder Postgres) als einen CF-Service abonnieren. In einem Szenario, in dem verschiedene Instanzen der betreffenden CF-Anwendung Daten miteinander austauschen sollen, empfiehlt sich ein Messaging-Dienst wie RabbitMQ oder ein Cache wie Redis.

Service-Broker in Cloud Foundry und Kubernetes

In Eigenregie: Erstellen eines Service-Brokers für standardmäßig nicht unterstützte Cloud-Dienste in Cloud Foundry.
In Eigenregie: Erstellen eines Service-Brokers für standardmäßig nicht unterstützte Cloud-Dienste in Cloud Foundry.
(Bild: Altoros)

Cloud-native Anwendungen vertrauen auf eine Vielzahl von Diensten im Pay-as-you-Go-Modell. Um diese Dienste in einer Cloud-Foundry-Anwendung nutzbar zu machen, besteht die Möglichkeit, sie über den sogenannten Marketplace der betreffenden CF-Bereitstellung zu veröffentlichen und hier durch die jeweilige Instanz der App abonnieren zu lassen.

Auf diese Weise bekommen Entwickler den Lebenszyklus der vielen Dienste einfacher in den Griff. Hierzu stehen aber mehrere Schritte auf dem Programm:

  • Erzeugen, Ausführen und Registrieren eines Service Brokers: Diese Komponente nutzt die Service Broker-API, um einen Service-Katalog der unterstützten Dienste den betreffenden Cloud Foundry-Anwendungen über den sogenannten Marketplace bereitzustellen und verwaltet den Lebenszyklus dieser Dienste (z.B. Datenbanken, Zertifikate oder Massenspeicher).
  • Registrieren der Service-Instanz: Um eine Instanz des betreffenden Dienstes ins Leben zu rufen, muss der Entwickler diese (nicht direkt, sondern) via die Service Broker-API anfordern.
  • Vorbereiten der CF-Apps für den Zugriff auf die betreffenden Services: Um eine Service-Instanz an die betreffende Instanz der CF-Anwendung zu binden, fügt Cloud Foundry die benötigten Anmeldeinformationen und sonstige Parameter für den betreffenden Cloud-Dienst in die Umgebungsvariable der jeweiligen Anwendung ein. Die App kann fortan entsprechende Aufrufe der benötigten Dienste selbst über die Service Broker-API tätigen.

Cloud Foundry unterstützt die OSBAPI (Open Service Broker API), einen quelloffenen, infrastrukturagnostischen Industriestandard für Service-Broker. Den Standard „spricht“ im Übrigen auch Kubernetes. So können Kubernetes und Cloud Foundry mit genau demselben Service-Broker kommunizieren.

OSBAPI hebt die Abhängigkeit der Entwickler in einem DevOps-Workflow von ihrem Ops-Team auf. Die Fähigkeit zur bedarfsgerechten Bereitstellung von Cloud-Diensten im Selbstbedienungsverfahren erhöht die Agilität und reduziert die Shadow-IT. Der wahre Wert der Broker-API besteht darin, dienstspezifische Lebenszyklusvorgänge von der Cloud-Plattform zu abstrahieren.

Bereitstellung von Cloud-Diensten an Cloud Foundry-Anwendungen

Die Bereitstellung eines Service-Abonnements lässt sich am einfachsten an einem konkreten Beispiel illustrieren. Die eine oder andere CF-Anwendung muss auf ein persistentes Netzwerkdateisystem zugreifen. Auch diese Zugriffe sollten mit Hilfe eines Service-Brokers über ein Service-Abonnement umgesetzt werden. In Cloud Foundry ist hierbei von Volume Services die Rede.

Um einen NFS-Dienst an eine CF-Anwendung namens dev-insider-app zu binden, genügt der Aufruf von:

cf bind-service dev-insider-app nfs_service_instance -c '{"uid":"1000","gid":"1000","mount":"/var/Dev-Insider-Volume","readonly":false}'

Diese Anweisung erlaubt die Ausführung der CF-App mit beliebigen Benutzerrechten der eigenen Instanz und die gleichzeitige Nutzung des NFS-Servers mit den spezifischen Berechtigungen des betreffenden Remote-Benutzers. Nach dem Herstellen der Bindung ist noch ein Aufruf von …

cf restage dev-insider-app

… erforderlich. Damit die App auf den Storage-Dienst jetzt zugreifen kann, muss sie einfach die zugehörigen Umgebungsvariablen korrekt einsetzen. Es handelt sich dabei um die Eigenschaften von „volume_mounts“ in der Ausgabe des Befehls:

cf env dev-insider-ap

Zum Beispiel:

"VCAP_SERVICES": {
   "nfs": [
      {
         "credentials": {},
         "label": "nfs",
         "name": "nfs_service_instance",
         "plan": "Existing",
         "provider": null,
         "syslog_drain_url": null,
         "tags": [
            "nfs"
         ],
         "volume_mounts": [
            {
               "container_dir": "/var/vcap/data/254e3b4a-4255-1cf4-b311-741dd79fce64",
               "device_type": "shared",
               "mode": "rw"
            }
         ]
      }
   ]
}

Das einzige Problem dabei: Das Mounten von NFS-Volumes im Verzeichnis einer CF-App kann die korrekte Initialisierung der Anwendung verhindern. Noch bevor die kompilierte App im Droplet abgelegt werden konnte, kümmert sich Cloud Foundry bereits um die Bereitstellung der Volumes.

Als Resultat daraus schreibt Cloud Foundry einen Teil des Droplets auf den bereits gemounteten Netzwerkspeicher und die Initialisierung der App schlägt fehl. Soll das Volume tatsächlich zwingend im Verzeichnis der CF-Anwendung gemountet werden, schafft ein Symlink Abhilfe. Der Trick: Der Symlink wird erst während der Initialisierung der App angelegt, nicht vorher. Zum Beispiel so:

cf push dev-insider-app -c "ln -s /var/Dev-Insider-Volume /app/volume1 && \$HOME/boot.sh"

Chaos Engineering für Cloud Foundry

Cloud-Nutzer wünschen sich mehr „Mobilität“ für ihren Anwendungscode, doch gerade verteile Microservice-Architekturen machen es nicht einfach. Mit dem Aufkommen von Microservices, verteilter Cloud-Architekturen und infrastrukturagnostischer Softwareentwicklung steigt der Bedarf nach einer neuen Art der Qualitätskontrolle: Cloud-agnostischer Ausfallsicherheit.

Chaos Engineering soll Abhilfe schaffen. Mit Hilfe entsprechender Chaos-Engineering-Toolkits können Entwickler die Widerstandsfähigkeit verteilter Anwendungen auf die Probe stellen und so teure Betriebsausfälle verhindern.

Die nordamerikanische Tochter von T-Mobile hat hierzu ein quelloffenes Chaos-Engineering-Tool namens Monarch für Cloud Foundry veröffentlicht, das als Plug-In im Chaos Toolkit (CTK) arbeitet. Chaos Toolkit kann Experimente mit verteilten Anwendungen auf AWS, Google Cloud Engine, Microsoft Azure, Cloud Foundry, Humio, Prometheus, Gremlin und in anderen Clouds automatisieren. Monarch simuliert Bandbreitenengpässe, Netzwerklatenz und Ausfälle von App-Instanzen auf Anwendungsebene.

Mit einer Software namens Turbulence++ von T-Mobile lassen sich unterschiedliche Ausfallszenarien einer CF-Anwendung in ein BOSH-System einpflegen (BOSH ist eine Toolchain für das Release-Engineering in Cloud Foundry.). So können Entwickler etwa die folgenden Desaster-Szenarien simulieren:

  • VM-Ausfall in einer von BOSH unterstützten IaaS-Umgebung
  • CPU/RAM/IO-Lasten
  • Netzwerkpartitionierung
  • Paketverlust und Netzwerklatenz

Für mehr App-Robustheit: Das Chaos Toolkit hilft bei der Automatisierung von Chaos-Engineering-Experimenten.
Für mehr App-Robustheit: Das Chaos Toolkit hilft bei der Automatisierung von Chaos-Engineering-Experimenten.
(Bild: chaosIQ)

Das Ganze hat zum Ziel, die Ausfallsicherheit von verteilten Anwendungen zu überprüfen und die Code-Qualität zu verbessern. Die quelloffenen Projekte Monarch und Turbulence++ sind auf GitHub verfügbar. Im Übrigen: Project Eirini und Project Quarks, die beiden neuesten Initiativen der Cloud Foundry-Gemeinde zur Integration in Kubernetes-dominierte Umgebungen, sollen die Entwicklererfahrung nicht beeinflussen.

Fazit

Durch die Konformität mit gewissen Design-Prinzipien können Unternehmen völlig Cloud-agnostische Softwarelösungen ins Leben rufen, zum Beispiel mit Cloud Foundry. Zum Testen der Ausfallsicherheit ist Chaos Engineering unvermeidlich.

(ID:46266273)