Anforderungen an Anwendungen

Cloud Foundry stellt besondere Anforderungen an Anwendungen, die auf der Plattform betrieben werden. Wann ist eine Anwendung also bereit für Cloud Foundry?

Um diese Frage zu beantworten, geben wir einen allgemeinen Überblick über die Aspekte, die Sie bei der Entwicklung und dem Betrieb von Anwendungen berücksichtigen sollten, damit diese optimal für die Cloud ausgelegt sind und das volle Potenzial von STACKIT Cloud Foundry nutzen können.

Weitere Details zu diesem Thema finden Sie in der offiziellen Cloud Foundry Dokumentation unter Aspekte für das Entwickeln und Betreiben einer App in der Cloud.

Cloud-native-Workload

STACKIT Cloud Foundry ist eine Cloud-native Platform as a Service (PaaS). Ihre Anwendung funktioniert daher am besten, wenn sie ebenfalls cloud-native ist.

Warum ist das wichtig?

Die Definition von Cloud-native der Cloud Native Computing Foundation lautet wie folgt:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniqüs enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes freqüntly and predictably with minimal toil.

[…]

In einer skalierenden Cloud-Umgebung muss Ihre Anwendung darauf ausgelegt sein, jederzeit gestartet und gestoppt zu werden, denn neue Instanzen können erzeugt und wieder entfernt werden, um Lastspitzen abzufangen. Wenn Sie Ihre Anwendung entsprechend entwickeln, profitieren Sie von den genannten Vorteilen: Sie ist skalierbar und dadurch resilienter, da sich bei Bedarf leicht mehrere neue Instanzen starten lassen. Außerdem lassen sich Anwendungen ohne komplexe Zustände besser verwalten und beobachten. Die einfache und vorhersehbare Erstellung neuer Anwendungsinstanzen ermöglicht zudem eine weitgehende Automatisierung von Deployments.

Was bedeutet cloud-native?

Grundsätzlich sollten Sie bei der Entwicklung Ihrer App einige Punkte berücksichtigen. Ein verbreitetes Muster für Cloud-native-Apps ist Twelve-Factor App. Es beschreibt zwölf zentrale Faktoren über den gesamten Entwicklungslebenszyklus Ihrer Software hinweg und ist auch für den Einsatz mit STACKIT Cloud Foundry ein empfohlenes Muster.

Einige Punkte dieser Liste sind für den Betrieb in der Cloud wichtiger als andere. Beispielsweise ist es für die Bereitstellung auf Cloud Foundry nicht zwingend erforderlich, den Anwendungscode in einer Versionsverwaltung abzulegen. Dagegen ist es sehr wichtig, dass Ihre Anwendung zustandslos ist.

Ihre Anwendung muss daher nicht in jeder Hinsicht streng cloud-native sein oder alle Empfehlungen von Twelve-Factor App erfüllen, sie sollte aber mindestens cloud-ready sein, um auf Cloud Foundry zu laufen.

Cloud-ready

Damit Ihre Anwendung cloud-ready ist, sollten Sie während der Entwicklung einige Punkte berücksichtigen. Sie muss nicht alle Aspekte des Twelve-Factor-App-Musters erfüllen. Mindestens sollte sie jedoch einige grundlegende Richtlinien einhalten. So kann die Anwendung nicht nur auf Cloud Foundry, sondern auch auf anderen Cloud-Plattformen bereitgestellt werden.

Einschränkungen von Anwendungsinstanzen

Einzelne Instanzen von Anwendungsprozessen oder Ausführungen (Tasks) können bis zu 32 GB RAM und bis zu 6 GB ephemeren lokalen Speicher nutzen, einschließlich zusätzlicher Prozesse (Sidecars).

Wenn nichts anderes angegeben ist, wird ein einzelner Webprozess mit 256 MB RAM und 512 MB ephemerem lokalem Speicher angenommen. Diese Werte können Sie zum Beispiel über die Manifest-Datei anpassen.

Nicht auf das lokale Dateisystem schreiben

Da Ihre Anwendungen in Containern laufen, ist ihr lokales Dateisystem nicht persistent. Sobald ein Container gestoppt wird oder abstürzt, wird der Speicher anderen Containern zugewiesen. Das bedeutet: Wenn eine Anwendung Daten lokal speichert und der Container durch ein Update oder einen Absturz neu bereitgestellt wird, gehen alle lokal abgelegten Daten verloren.

Außerdem wird das lokale Dateisystem eines Containers nicht zwischen allen Instanzen geteilt. Wenn eine Anwendung Daten lokal ablegt, kennt nur diese eine Instanz diese Daten. Wenn Benutzer danach die Seite neu laden und auf eine andere Instanz geroutet werden, ist kein Zugriff mehr auf diese Daten möglich.

Statt Daten lokal zu persistieren, können Sie Data Services aus dem Marketplace oder Volumes as a Service aus dem STACKIT Portal nutzen. Mehr dazu erfahren Sie unter Service-Instanz erstellen.

Keine Top-Level-Domains für Cookies verwenden

Cloud Foundry verwendet Wildcard-Domains als Routen für Ihre Anwendung. Wenn Sie in Ihrer Anwendung Cookies einsetzen und diese auf der obersten Domain-Ebene verfügbar machen, kann jede andere Anwendung innerhalb dieser gemeinsamen Domain darauf zugreifen.

Sie verwenden zum Beispiel Tracking-Tools wie Google Analytics und stellen Ihre Anwendung über die URL my-app.apps.01.cf.eu01.stackit.cloud bereit. Wenn Sie nun das Domain-Attribut Ihres Cookies auf *.stackit.cloud setzen, kann jede Anwendung darauf zugreifen, die unter another-app.apps.01.cf.eu01.stackit.cloud gehostet ist. Setzen Sie die Cookie-Domain daher immer auf die spezifischste Domain Ihrer Anwendung und nicht auf eine weiter gefasste, gemeinsam genutzte Domain.

Port-bezogene Hinweise

Alle Anwendungen laufen in isolierten containerisierten Prozessen, die von der Cloud Foundry Komponente Diego orchestriert werden. Benutzer können auf Ihre Anwendungen nur über eine zugewiesene Route zugreifen. Cloud Foundry erlaubt HTTP-Anfragen auf diese Routen über die Ports 80 und 443. Diego leitet anschließend alle eingehenden Anfragen über die Routen an die Anwendungscontainer auf Port 8080 weiter. Deshalb müssen Sie Ihre Anwendung im Container auf Port 8080 bereitstellen.

Mehr dazu finden Sie in der offiziellen Cloud Foundry Dokumentation zu Routen und Domains.

Rechnen Sie damit, dass Anwendungsinstanzen gestoppt werden

Beim Herunterfahren oder Ausrollen von Updates kann es erforderlich sein, dass Cloud Foundry Ihre Anwendungsinstanzen stoppt oder neu startet. In diesen Fällen sendet Cloud Foundry ein einmaliges Termination-Signal und wartet 10 Sekunden, damit sich Ihre Anwendung kontrolliert beenden kann. Nach Ablauf dieser 10 Sekunden wird die Anwendung zwangsweise beendet.

Ihre Anwendung sollte das Termination-Signal empfangen und entsprechend verarbeiten, damit sie innerhalb der 10-sekündigen Grace-Period sauber herunterfahren kann.

Bei Updates und beim Herunterskalieren stellt Cloud Foundry sicher, dass eine neue Instanz Ihrer Anwendung gestartet wird, bevor das Termination-Signal an die alten Instanzen gesendet wird.

Verwenden Sie beim Push von Quellcode eine .cfignore-Datei

Wenn Sie Ihren Quellcode nach Cloud Foundry pushen, werden automatisch alle Dateien in dem Verzeichnis hochgeladen, aus dem Sie den Push ausführen. Nutzen Sie beim Hochladen eines Build-Artefakts das Path-Argument, um nur das Artefakt hochzuladen, das Sie für das Deployment benötigen. Wenn Sie stattdessen Quellcode hochladen möchten, können Sie die Datei .cfignore verwenden. Das ist eine normale Textdatei, in der Sie alle Dateien oder Unterverzeichnisse angeben, die vom Upload ausgeschlossen werden sollen. Sie funktioniert analog zu einer .gitignore-Datei.

Führen Sie mehrere Instanzen Ihrer Anwendung aus

Bei Updates oder unerwarteten Plattformfehlern kann es vorkommen, dass Cloud Foundry Ihre Anwendungsinstanz zwangsweise beendet. Um Verfügbarkeit und Resilienz zu erhöhen und zu vermeiden, dass Ihre Anwendung für Benutzer vorübergehend nicht erreichbar ist, sollten Sie immer mehrere Instanzen Ihrer Anwendung betreiben.

Mit unserem App Autoscaler Service können Sie außerdem einen Bereich mit Mindest- und Höchstanzahl an Instanzen definieren und Regeln festlegen, wann hoch- oder herunterskaliert werden soll.

Mit Buildpacks containerisieren

Buildpacks können Ihre Anwendung in einen Container paketieren. Da sie Teil des Cloud Foundry Ökosystems sind, sind sie für den Einsatz in Cloud Foundry stark optimiert und erkennen Framework sowie Runtime Ihrer Anwendung zuverlässig und konfigurieren diese entsprechend. Sie folgen dem umfangreich getesteten, opinionated Ansatz von Cloud Foundry und sind daher die empfohlene Methode zur Containerisierung.

Sie können auch eigene Custom Buildpacks erstellen und verwenden, die auf Ihre spezifischen Anforderungen zugeschnitten sind. Mehr dazu erfahren Sie unter Container und Buildpacks.

Weiterführende Informationen

• Aspekte für das Entwickeln und Betreiben einer App in der Cloud
• Die Cloud-native-Definition der Cloud Native Computing Foundation
• Twelve-Factor-App-Muster
• Die Cloud Foundry Dokumentation zu Routen und Domains
• Die Cloud Foundry Dokumentation zu Diego
• Die Cloud Foundry Dokumentation zum App-Container-Lifecycle
• Container und Buildpacks