Anforderungen an Anwendungen

Cloud Foundry stellt einige besondere Anforderungen an Anwendungen, die auf der Plattform gehostet werden.

Wann ist eine Anwendung Cloud Foundry-Bereit?
Dazu erhalten wir einen allgemeinen Überblick über Überlegungen, wie Anwendungen so gestaltet und betrieben werden können, dass sie hochgradig Cloud-optimiert sind und das volle Potenzial der STACKIT Cloud Foundry nutzen.

Weitere Details zu diesem Thema finden Sie auch in den offiziellen Cloud Foundry-Dokumentationen unter Considerations for Designing and Running an App in the Cloud.

Cloud Native Workload

Unsere Cloud Foundry ist eine Cloud Native Platform as a Service, daher funktioniert Ihre Anwendung am besten, wenn sie auch Cloud Native ist.

Wieso ist das wichtig?

The Cloud Native Computing Foundations Definition für cloud native ist die folgende:

Cloud-native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und hybriden Clouds zu erstellen und auszuführen. Container, Service-Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs sind Beispiele für diesen Ansatz.

Diese Techniken ermöglichen lose gekoppelte Systeme, die widerstandsfähig, verwaltbar und beobachtbar sind. In Kombination mit einer robusten Automatisierung ermöglichen sie es Ingenieuren, mit minimalem Aufwand häufige und vorhersehbare Änderungen vorzunehmen, die sich stark auswirken.

[…]

In einer skalierenden Cloud-Umgebung muss Ihre Anwendung damit rechnen, dass sie jederzeit gestartet und gestoppt wird - denn neue Instanzen können erzeugt und zerstört werden, um Lastspitzen abzudecken. Wenn Sie Ihre Anwendung so entwerfen, dass sie mit dieser Belastung umgehen kann, ergeben sich die genannten Vorteile: Sie ist skalierbar und damit belastbarer, da Ihre Anwendung ohne Probleme mehrere neue Instanzen erzeugen kann. Und es ist einfacher, Anwendungen zu verwalten und zu beobachten, die nicht verschiedene komplexe Zustände aufweisen, in denen sie sich befinden könnten. Das einfache und vorhersehbare Erzeugen neuer Anwendungen gibt Ihnen auch die Möglichkeit, die Bereitstellung zu automatisieren usw.

Was ist Cloud Native?

Im Allgemeinen müssen Sie bei der Gestaltung Ihrer App einige Überlegungen anstellen. Ein gängiges Muster für Cloud Native Apps ist die Twelve Factor App. Es listet 12 wichtige Faktoren rund um den Entwicklungslebenszyklus Ihrer Software auf und ist auch ein empfohlenes Muster für die Verwendung mit STACKIT Cloud Foundry.

Einige der Punkte auf der Liste sind wichtiger, wenn es nur darum geht, Ihre Anwendung in der Cloud zu betreiben, andere sind weniger wichtig. Es ist zum Beispiel nicht notwendig, den Code Ihrer Anwendung in einer Revisionskontrolle zu speichern, um sie in Cloud Foundry bereitzustellen. Auf der anderen Seite ist es aber sehr wichtig, dass Ihre Anwendung zustandslos ist.

Daher muss Ihre Anwendung nicht zwingend Cloud-nativ sein oder allen Empfehlungen der Zwölf-Faktor-App folgen, sondern muss lediglich Cloud-fähig sein, um auf Cloud Foundry zu laufen.

Cloud Foundry-fähig

Damit Ihre Anwendung Cloud-fähig wird, müssen Sie bei der Entwicklung Ihrer Anwendung einige Überlegungen anstellen. Sie muss nicht alle Punkte des Zwölf-Faktoren-App-Musters befolgen. Aber zumindest muss die Anwendung ein paar einfache Richtlinien befolgen. So kann die Anwendung nicht nur auf Cloud Foundry, sondern auch auf anderen Cloud-Plattformen eingesetzt werden.

Limitierungen von Applikationsinstanzen

Einzelne Instanzen von Applikationsprozessen oder Ausführungen (Tasks) können bis zu 32 GB RAM und bis zu 6 GB flüchtigen lokalen Festplattenspeicher konsumieren inklusive weiterer Prozesse (Sidecars).

Wenn nichts weiter angegeben wird, dann wird von einem einzigen Web-Prozess mit 256 MB RAM und 512 MB flüchtigen lokalen Festplattenspeicher ausgegangen. Die Werte können u.a. mithilfe der Manifest-Datei geändert werden.

Nicht in das lokale Dateisystem schreiben

Da Ihre Anwendungen in Containern ausgeführt werden, bleibt ihr lokales Dateisystem nicht dauerhaft erhalten. Sobald der Container gestoppt wird oder abstürzt, wird der Speicher anderen Containern zugewiesen. Das bedeutet, wenn eine Anwendung Daten im lokalen Dateisystem ablegt und der Container aufgrund einer Aktualisierung oder eines Absturzes neu bereitgestellt wird, gehen alle lokal gespeicherten Daten verloren.

Außerdem wird das lokale Dateisystem eines Containers nicht von allen Instanzen gemeinsam genutzt. Das heißt, wenn eine Anwendung Daten im lokalen Dateisystem vorhält, weiß nur diese eine Instanz davon. Wenn der Benutzer dann die Seite auffrischt und zu einer der anderen Instanzen weitergeleitet wird, ist der Zugriff auf die Daten nicht mehr möglich.

Statt Daten im lokalen Dateisystem zu persistieren, können Sie Datendienste vom Marktplatz oder Volumes als Dienst aus dem STACKIT Portal nutzen. Mehr dazu unter Step 4: Create a Service Instances.

Verwenden Sie die Top-Level-Domänen nicht für Cookies

Cloud Foundry verwendet Wildcard-Domänen als Route für Ihre Anwendung. Wenn Sie in Ihrer Anwendung Cookies verwenden und diese auf der höchsten Domänenebene zugänglich machen, kann jede andere Anwendung in dieser gemeinsamen Domäne darauf zugreifen.

Sie könnten zum Beispiel Tracking-Tools wie Google Analytics oder ähnliches verwenden und Ihre Anwendung über die URL my-app.apps.01.cf.eu01.stackit.cloud offenlegen. Wenn Sie nun das Domain-Attribut Ihres Cookies auf *.stackit.cloud setzen, kann eine Anwendung, die in another-app.apps.01.cf.eu01.stackit.cloud gehostet wird, darauf zugreifen. Daher müssen Sie die Domäne auf die höchste Domäne einstellen, die Ihrer Anwendung zugewiesen ist.

Port Überlegungen

Alle Anwendungen laufen auf isolierten containerisierten Prozessen, die von der Cloud Foundry-Komponente Diego orchestriert werden. Benutzer können nur über eine zugewiesene Route auf Ihre Anwendungen zugreifen. Die Cloud Foundry erlaubt HTTP-Anfragen an diese Routen auf den Ports 80 und 433. Diego leitet dann alle eingehenden Anfragen über die Routen an die Anwendungscontainer auf Port 8080 weiter. Daher müssen Sie Ihre Anwendung innerhalb des Containers über Port 8080 offenlegen.

Sie können in der offiziellen Cloud Foundry Dokumentation über Routen und Domains mehr erfahren.

Rechnen Sie damit, dass Ihre Anwendungsinstanzen heruntergefahren werden

Beim Herunterfahren oder Ausrollen von Updates muss Cloud Foundry Ihre Anwendungsinstanzen möglicherweise anhalten oder neu starten. In diesen Fällen sendet Cloud Foundry ein einzelnes Beendigungssignal aus und wartet 10 Sekunden, bis Ihre Anwendung ordnungsgemäß heruntergefahren ist. Nach Ablauf der 10 Sekunden wird die Anwendung zwangsweise heruntergefahren.

Ihre Anwendung sollte das Beendigungssignal akzeptieren und entsprechend behandeln, um innerhalb der 10 Sekunden Wartezeit ordnungsgemäß herunterzufahren.

Bei Aktualisierungen und Verkleinerungen stellt Cloud Foundry sicher, dass eine neue Instanz Ihrer Anwendung gestartet wurde, bevor das Beendigungssignal an die alten Instanzen gesendet wird.

Verwenden Sie eine.cfignore-Datei bei einem Push von Quellcode

Wenn Sie Ihren Quellcode in die Cloud Foundry übertragen, werden automatisch alle Dateien in dem Verzeichnis hochgeladen, aus dem Sie die Übertragung vorgenommen haben. Verwenden Sie das Pfad-Argument, wenn Sie ein Build-Artefakt in die Cloud Foundry hochladen, um nur das Artefakt hochzuladen, das Sie für die Bereitstellung benötigen. Wenn Sie Quellcode hochladen möchten, können Sie die Datei .cfignore verwenden. Dies ist eine normale Textdatei, die alle Dateien oder Unterverzeichnisse auflistet, die Sie von der Übertragung ausschließen möchten. Sie funktioniert genauso wie die üblichen .gitignore-Dateien.

Führen Sie mehrere Instanzen ihrer Applikation aus

Bei Aktualisierungen oder unerwarteten Fehlern der Plattform muss Cloud Foundry Ihre Anwendungsinstanz möglicherweise zwangsweise herunterfahren. Um die Verfügbarkeit und Ausfallsicherheit Ihrer Anwendung zu erhöhen und sicherzustellen, dass sie nicht für Ihre Benutzer vorübergehend unerreichbar ist, sollten Sie immer mehrere Instanzen Ihrer Anwendung ausführen.

Mit unserem App Autoscaler Service können Sie auch eine Reihe von minimalen und maximalen Instanzen der Anwendung definieren und Regeln festlegen, wann sie auf- und wieder herunter skaliert werden soll.

Containerisieren Sie mit Buildpacks

Buildpacks können Ihre Anwendung in einen Container verpacken. Da sie Teil des Cloud Foundry-Ökosystems sind, sind sie stark für den Einsatz innerhalb von Cloud Foundry optimiert und erkennen und konfigurieren das Framework und die Laufzeit Ihrer Anwendung sicher. Sie folgen dem umfangreich getesteten, meinungsbildenden Ansatz von Cloud Foundry und sind daher der empfohlene Containerisierungsansatz.

Sie können auch benutzerdefinierte Buildpacks erstellen und verwenden, die Ihren spezifischen Anforderungen entsprechen. Mehr darüber erfahren Sie in CloudFoundry Container und Buildpacks.

Weiterführende Informationen

• Considerations for Designing and Running an App in the Cloud.
• Die Cloud Native Computing Foundations Definition for Cloud Native
• Twelve Factor App Pattern
• The Cloud Foundry Doc über routes and domains
• The Cloud Foundry Doc über Diego
• The Cloud Foundry Doc über App Container Lifecycle
• CloudFoundry Container und Buildpacks