FAQ

Wir möchten Ihnen die Informationen bereitstellen, die Sie benötigen, um STACKIT Cloud Foundry optimal zu nutzen. Dieser FAQ-Bereich beantwortet häufige Fragen. So finden Sie schneller Lösungen und verbessern Ihre Nutzungserfahrung. Wir empfehlen Ihnen, diese FAQ zu prüfen, bevor Sie unser Support-Team kontaktieren, da Sie die gesuchte Antwort möglicherweise bereits hier finden.

• Allgemeine Informationen

  Alle erweitern

  Mein Service funktioniert nicht. Wo bekomme ich Hilfe?

  Erstellen Sie ein Incident im STACKIT Help Center.

  Wie ändere ich die Quota meiner Organisation?

  1. Öffnen Sie das STACKIT Portal.
  2. Navigieren Sie zu Runtime > Cloud Foundry.
  3. Wählen Sie Ihre Organisation in der Liste aus, um zur Seite Overview zu gelangen.
  4. Klicken Sie auf der Kachel Quota auf Edit.
  5. Wählen Sie im Dropdown-Menü den gewünschten Quota-Type aus.
  6. Klicken Sie auf Save, um die Änderungen zu übernehmen.

  Ich habe eine Frage, die in der Dokumentation nicht beantwortet wird.

  Erstellen Sie gerne eine Service Request im STACKIT Help Center.

• Apps

  Alle erweitern

  Welche Limits gelten für Apps in STACKIT Cloud Foundry?

  Die Limits für einzelne App-Prozessinstanzen und Tasks finden Sie auf der Seite Anforderungen an Anwendungen.

  Wie kann ich schnell auf den zuletzt funktionierenden App-Container zurückrollen, wenn ein neuer Push fehlschlägt?

  Wenn Ihre App nach dem Push nicht funktioniert und keine Zeit bleibt, Anpassungen vorzunehmen oder eine ältere Version zu pushen, zum Beispiel weil sich externe Abhängigkeiten oder das Buildpack geändert haben, können Sie jederzeit auf den zuletzt funktionierenden Container-Build zurückgehen. Dieser wird als Droplet bezeichnet (hochgeladener App-Code wird als Package gespeichert, das zusammen mit dem Buildpack zur Erstellung des Droplets verwendet wird):

  cf droplets [APP_NAME] # auf die Droplet-GUID des zuletzt erfolgreichen Builds achten

  cf set-droplet [APP_NAME] [DROPLET_GUID] # tauscht die Container-Images direkt aus

  Wie kann ich eine ältere Buildpack-Version oder ein anderes Community-Buildpack von GitHub mit einem bestimmten Tag verwenden?

  Sie können ein bestimmtes Cloud Foundry Community-Buildpack mit offizieller GitHub-URL und Versions-Tag wie folgt angeben:

  https://github.com/cloudfoundry/java-buildpack.git#v4.61.0

  Mit dem CLI-Befehl cf buildpacks können Sie alle aktuell unterstützten, integrierten Buildpacks auflisten.

  Bitte beachten Sie, dass dies nur vorübergehend genutzt werden sollte, da veraltete Buildpacks nicht empfohlen sind. Vollständigen STACKIT Cloud Foundry Support erhalten Sie nur für die integrierten Buildpacks.

  Das Staging meiner App schlägt beim Herunterladen von Abhängigkeiten fehl. Wie kann ich das beheben?

  Das Staging der App schlägt beim Herunterladen von Abhängigkeiten mit error: 400, Bad Request, error: 405 Forbidden, read udp ...: i/o timeout, read: connection reset by peer (oder ähnlichen Fehlern) fehl.

  Die Standard-Buildpacks von Cloud Foundry sind nicht gecacht und müssen während des Anwendungs-Stagings Abhängigkeiten aus dem Internet herunterladen. Wenn diese Abhängigkeiten nicht verfügbar sind, schlägt das Staging fehl. Für solche Szenarien bieten wir auch lokal verfügbare Offline-Buildpacks an. Diese gecachten Buildpacks enthalten alle notwendigen Abhängigkeiten, sodass der Staging-Prozess erfolgreich abgeschlossen werden kann, ohne etwas aus dem Internet herunterzuladen. Weitere Details finden Sie im How-to Offline-Buildpacks verwenden.

• Veraltete Komponenten

  Alle erweitern

  Warum schlägt der Push meiner Java-Spring-Boot-App in letzter Zeit fehl?

  Bitte beachten Sie bei Updates bestehender Spring-Boot-Java-Apps seit März 2024, dass die veralteten Spring Cloud Connector und Spring Auto Reconfiguration zugunsten der Bibliothek java-cfenv in Spring Boot Version 3 entfernt wurden. Ältere Spring-Boot-Versionen sind davon nicht betroffen.

  Warum schlägt der Push meiner App mit angepasstem Buildpack in letzter Zeit fehl?

  Für alle Apps wird empfohlen, die neuesten Buildpack-Versionen zu verwenden, die mit der Plattform bereitgestellt werden, da ältere Community-Buildpacks veraltete Container-Basis-Images nutzen können. Ein Beispiel für ein veraltetes Container-Basis-Image ist der Stack linuxfs3, der seit April 2024 schrittweise von der Plattform entfernt wird.

  Abkündigung des Cloud Foundry Stacks cflinuxfs3 und Migration zu cflinuxfs4

  Bitte beachten Sie bei Updates bestehender Spring-Boot-Java-Apps seit März 2024, dass die veralteten Spring Cloud Connector und Spring Auto Reconfiguration zugunsten der Bibliothek java-cfenv in Spring Boot Version 3 entfernt wurden. Ältere Spring-Boot-Versionen sind davon nicht betroffen.

  Die STACKIT Cloud Foundry Runtime verwendet Stacks, also vorgefertigte Root-Dateisysteme, die zusammen mit Anwendungscode und Buildpacks die Grundlage für den Aufbau des Anwendungscontainers bilden. Der Stack in der STACKIT Cloud Foundry Umgebung basiert auf einem Linux-System und heißt cflinuxfs(x).

  Stacks erhalten regelmäßig Updates, um Sicherheitsprobleme und Schwachstellen zu beheben. Ihre Anwendungen übernehmen diese Verbesserungen über neue Releases und Versionsupdates der STACKIT Cloud Foundry Runtime.

  Derzeit laufen in der STACKIT Cloud Foundry Umgebung einige Anwendungen noch auf dem Stack cflinuxfs3, der auf Ubuntu Bionic Beaver 18.04 basiert. Dieser Stack wurde im Dezember 2022 abgekündigt und sollte im Juni 2024 aus der STACKIT Cloud Foundry Umgebung entfernt werden. Diese Änderung betrifft alle, die Buildpack-basierte Anwendungen in der STACKIT Cloud Foundry Umgebung betreiben.

  Der Nachfolger cflinuxfs4, basierend auf Ubuntu Jammy Jellyfish 22.04, ist inzwischen der Standard-Stack in der STACKIT Cloud Foundry Umgebung. Das bedeutet, dass alle neuen Anwendungen diesen Stack automatisch nutzen.

  Bereits bestehende Anwendungen auf dem Stack cflinuxfs3 sind von dieser Änderung zunächst nicht direkt betroffen. Es wird jedoch empfohlen, sie gemäß der folgenden Anleitung auf den neuen Stack umzustellen. Nach der Entfernung des alten Stacks kann Ihre App nicht mehr funktionieren, wenn sie mit cflinuxfs4 nicht kompatibel ist.

  Um Funktionalität und die Einhaltung von Sicherheitsstandards in der STACKIT Cloud Foundry Umgebung sicherzustellen, müssen Sie Ihre Anwendungen auf cflinuxfs4 migrieren. Wir empfehlen, so früh wie möglich mit Tests auf dem neuen Stack zu beginnen, damit mögliche Probleme rechtzeitig behoben werden können.

  Umstellung auf cflinuxfs4

  Um cflinuxfs4 mit bestehenden Anwendungen zu verwenden, können Sie die Anwendung pushen und den Stack manüll festlegen:

  cf push [APP_NAME] -s cflinuxfs4

  Alternativ können Sie den Stack im App-Manifest anpassen. Siehe dazu die Cloud Foundry Dokumentation.

  Fallback auf cflinuxfs3

  Sie können cflinuxfs3 für eine Übergangszeit weiterhin verwenden. Wenn Sie beim Einsatz des neuen Stacks Probleme feststellen, können Sie beim Push Ihrer Anwendung mit dem Parameter “-s” auch manüll auf cflinuxfs3 zurückwechseln:

  cf push [APP_NAME] -s cflinuxfs3

  cflinuxfs3 wird nach Juni 2024 dauerhaft entfernt. Danach ist ein manüller Wechsel zurück auf cflinuxfs3 nicht mehr möglich. Weitere Informationen zu Stacks finden Sie in der Cloud Foundry Dokumentation.

  Ihren aktuell verwendeten Stack ermitteln

  Mit der CF CLI

  Wenn Sie nicht sicher sind, auf welchem Stack Ihre Anwendungen aktuell laufen, können Sie dies über die CF CLI ermitteln. Führen Sie folgenden Befehl aus:

  cf app [APP_NAME]

  Die Ausgabe zeigt Informationen zur angegebenen Anwendung an. Darin finden Sie auch eine Zeile, die mit “stack:” beginnt, gefolgt vom Namen des aktuell verwendeten Stacks.

  Wenn hier cflinuxfs3 angezeigt wird, verwendet Ihre Anwendung noch den abgekündigten Stack. Wenn cflinuxfs4 aufgeführt ist, nutzt Ihre Anwendung bereits den neuen Stack, und es sind keine weiteren Maßnahmen erforderlich.

  Mit dem Stack Auditor Plugin

  Die CF CLI unterstützt die Verwendung von Drittanbieter-Plugins. Um zu prüfen, welche Stacks Ihre Anwendungen nutzen, können Sie das Stack Auditor CLI Plugin verwenden und Anwendungen für jede Org auflisten, auf die Sie Zugriff haben. Weitere Informationen finden Sie in der Stack-Auditor-Dokumentation.

  Mit jq

  Alternativ können Sie mit dem Tool jq und der CF CLI diese Informationen über die CF APIs abfragen.

  Mit jq können Sie das folgende Skript ausführen, um einen Überblick über Stack und Buildpacks aller Anwendungen innerhalb einer Cloud Foundry Org zu erhalten:

  cf curl "/v3/apps?per_page=5000&include=space.organization" | jq '(.included.spaces | INDEX(.guid)) as $spaces | (.included.organizations | INDEX(.guid)) as $orgs | [ .resources[] | {app: .name, org:$orgs[$spaces[.relationships.space.data.guid].relationships.organization.data.guid].name ,space: $spaces[.relationships.space.data.guid].name , lifecycle} ]'

  Wenn Sie gezielt nach cflinuxfs3 filtern möchten, um Anwendungen mit manüllem Migrationsbedarf anzuzeigen, verwenden Sie:

  cf curl "/v3/apps?per_page=5000&include=space.organization" | jq '(.included.spaces | INDEX(.guid)) as $spaces | (.included.organizations | INDEX(.guid)) as $orgs | [ .resources[] | select(.lifecycle.data.stack == "cflinuxfs3") | {app: .name, org:$orgs[$spaces[.relationships.space.data.guid].relationships.organization.data.guid].name ,space: $spaces[.relationships.space.data.guid].name , lifecycle} ]'

  Vor der Migration prüfen

  Um sicherzustellen, dass Ihre Anwendung auf dem neuen Stack korrekt funktioniert, empfehlen wir, sie vor der Migration zu testen. Pushen Sie dazu Ihre Anwendung einmal separat mit neuem Namen und eigener Route:

  cf push [APP_NAME] -s cflinuxfs4

  Wenn Ihre Anwendungen vorkompilierte Binärdateien verwenden oder enthalten, müssen diese möglicherweise neu kompiliert werden. Ein Beispiel sind Anwendungen, die von Binärbibliotheken wie openssl oder Python abhängen, da cflinuxfs4 auf neuere Versionen setzt als cflinuxfs3.

  Wenn alles wie erwartet funktioniert hat, können Sie mit Ihren produktiven Apps fortfahren und den Stack einfach im cf push-Befehl oder im Cloud Foundry Manifest festlegen. Um ein unbeabsichtigtes Zurückfallen auf cflinuxfs3 zu vermeiden, stellen Sie sicher, dass auch Ihre Continuous-Deployment-Automatisierung Anwendungen mit cflinuxfs4 bereitstellt.

  Risiken und Folgen

  Wenn die Anwendungen bereits liefen, führt der Neustart zu einer kurzen Downtime.

  Wenn Sie das Blue-Green-Deployment-Verfahren nutzen, werden Ihre Anwendungen automatisch auf cflinuxfs4 bereitgestellt. Das funktioniert nur, wenn Sie die nicht verwendeten blauen oder grünen Anwendungen löschen. Weitere Informationen finden Sie in der Cloud Foundry Dokumentation zu Blue-Green Deployment.

  Sie können auch die Rolling-App-Deployment-Methode verwenden, um Ihre Anwendungen ohne Downtime zu aktualisieren. Weitere Informationen finden Sie in der Cloud Foundry Dokumentation zu Rolling Deployment. Wenn Ihre Anwendungen jedoch mit dem Stack cflinuxfs4 nicht kompatibel sind, kann es sein, dass sie nicht mehr funktionieren und nicht neu gestartet werden können.

  Migration von Spring Cloud Connectors und Spring Auto Reconfiguration zu java-cfenv

  Mit der Veröffentlichung von Java Buildpack v4.49 wurden Spring Cloud Connectors und Spring Auto Reconfiguration abgekündigt. Diese Komponenten dienten dazu, Zugangsdaten aus Service-Bindings in Spring-Apps einzubinden. Sie wurden zugunsten der Bibliothek java-cfenv abgelöst.

  In den Buildpack-Versionen v4.51 und v4.52 war die abgekündigte Bibliothek standardmäßig deaktiviert, konnte jedoch über folgende Umgebungsvariable wieder aktiviert werden:

  JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '{enabled: true}'

  Version v4.62 (veröffentlicht im September 2023) ersetzt die abgekündigte Auto-Reconfiguration-Bibliothek durch die neue Bibliothek java-cfenv, allerdings nur für Spring-Boot-3-Anwendungen. Spring-Boot-2-Anwendungen erhalten die abgekündigte Bibliothek weiterhin bis zum End-of-Life von Spring Boot 2 am 24. August 2025. Java Buildpack v4.62 ist seit März 2024 Teil unseres Plattform-Releases.

  Mehr Informationen finden Sie unter Migration auf java-cfenv.

  Ist Ihre App betroffen?

  • Betroffen sind nur Apps, die das Java Buildpack > v4.61 verwenden.
  • Die Bibliothek java-cfenv ist noch nicht als User-Dependency in der App eingebunden.
  • Betroffen sind alle Spring-Boot-Apps ab Version >= 3, die aktiv eine der folgenden Dependencies verwenden:
    • org.springframework.boot:spring-boot-starter-cloud-connectors
    • org.springframework.cloud:spring-cloud-core
    • org.springframework.cloud:spring-cloud-connectors-core
    • org.springframework.cloud:spring-cloud-cloudfoundry-connector
    • org.springframeworkcloud:spring-cloud-spring-service-connector
    • org.cloudfoundry:java-buildpack-auto-reconfiguration

  Betroffene Apps funktionieren nicht mehr korrekt, nachdem folgendes env gesetzt wurde:

  Über CLI

  cf set-env <APP> JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '{enabled: false}'

  Oder in manifest.yml unter env:

    JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '{enabled: false}'

  • Dazu zählen zum Beispiel Apps, die erwarten, dass das Cloud-Profil automatisch durch Spring gesetzt wird.
  • Dazu zählen auch Apps, die auf das cf env nicht über vcap.foo.etc, sondern über cloud.foo.etc zugreifen.

  Was müssen Sie tun?

  Das hängt von der jeweiligen App ab. Bei manchen Apps reicht es aus, einige Dependencies in pom.xml oder build.gradle zu ändern. Bei anderen Apps ist eine explizitere Instanziierung des Clients für den jeweiligen Service erforderlich. Die folgenden Punkte dienen als Orientierung.

  Auf den letzten Container-Build (Droplet) zurückgehen

  Wenn Ihre App nach dem Push nicht funktioniert und keine Zeit bleibt, sie anzupassen oder kurzfristig die unten beschriebene vorherige Java-Buildpack-Version anzugeben, können Sie jederzeit auf den zuletzt funktionierenden Container-Build zurückgehen. Dieser wird als Droplet bezeichnet (hochgeladener App-Code wird als Package gespeichert, das zusammen mit dem Buildpack zur Erstellung des Droplets verwendet wird):

  cf droplets <APP_NAME> # auf die Droplet-GUID des zuletzt erfolgreichen Builds achten

  cf set-droplet <APP_NAME> <DROPLET_GUID>

  Vorübergehende Nutzung des vorherigen Java Buildpacks v4.61.0

  Sie können ein bestimmtes Cloud Foundry Community-Buildpack mit offizieller GitHub-URL und Versions-Tag wie folgt angeben:

  https://github.com/cloudfoundry/java-buildpack.git#v4.61.0

  Mit dem CLI-Befehl cf buildpacks können Sie alle derzeit unterstützten integrierten Buildpacks auflisten.

  Bitte beachten Sie, dass dies nur vorübergehend genutzt werden sollte, da veraltete Buildpacks nicht empfohlen sind. Vollständigen STACKIT Cloud Foundry Support erhalten Sie nur für die integrierten Buildpacks.

  java-cf-env

  Einer der wichtigsten Schritte ist, die betroffenen Dependencies zu entfernen und eine neue hinzuzufügen:

  implementation 'io.pivotal.cfenv:java-cfenv-boot:2.4.0'

  Die Dokumentation der Bibliothek finden Sie auf GitHub.

  Wir empfehlen außerdem diesen Spring-Artikel (verwenden Sie bitte die aktuelle Version der Bibliothek).

  Damit können Sie die übliche Syntax in application.yml nutzen, um auf das CF env zuzugreifen, zum Beispiel:

  ${vcap.services.myservice.credentials.etc:#{"default_valü"}}

  Es ist weiterhin möglich, über die Annotation @Valü auf das CF env zuzugreifen (als Best Practice ist jedoch der Weg über application.yml vorzuziehen).

  @Valü("${vcap.services.myservice.credentials.password}") private String
  password;

  Zusätzlich stellt die Bibliothek eine Reihe von EnvironmentPostProcessors bereit, um die Funktion der Cloud Connectors so weit wie möglich nachzubilden (siehe Verwendung mit Spring Boot). Dazu gehören Prozessoren für folgende Service-Typen:

  • RabbitMQ (nur AMQP, kein Stomp oder MQTT)
  • Redis

  Spring Cloud Profile

  Spring Auto Reconfiguration hat für die App das Cloud-Profil gesetzt.

  Wenn das Profil weiterhin benötigt wird, kann es weiterhin über die CF CLI oder das Manifest gesetzt werden:

  Über CLI

  cf set-env <APP> SPRING_PROFILES_ACTIVE cloud

  Oder in manifest.yml unter env:

  env:
    SPRING_PROFILES_ACTIVE: cloud

• Zugriff

  Alle erweitern

  Warum funktioniert der SSH-Zugriff auf meine App nicht?

  Stellen Sie sicher, dass Sie eine der dokumentierten Möglichkeiten für den Zugriff auf Ihre App über die cf CLI oder den nativen SSH-Befehl nutzen. Der Zugriff über die Web-UI-Console wird nicht unterstützt. Seit April 2024 ist der SSH-Zugriff auf neu bereitgestellte Apps standardmäßig deaktiviert. Sie können ihn mit folgendem Befehl wieder aktivieren: cf enable-ssh [APP_NAME]. Weitere Details finden Sie in der offiziellen Open-Source-Cloud-Foundry-Dokumentation.

  Mein Service-Account (technische User-ID) zeigt im Bereich Zugangsdaten ein veraltetes Ablaufdatum, funktioniert aber weiterhin. Ist das ein Problem?

  Im Jahr 2023 wurde die automatische Ablaufzeit für Service-Accounts beziehungsweise technische Benutzerzugangsdaten auf Wunsch mehrerer Kunden deaktiviert. Bereits zuvor erstellte Zugangsdaten zeigen das Feld expiryDate weiterhin an, da es zusammen mit den Zugangsdaten gespeichert wird und nicht entfernt werden kann, außer die Zugangsdaten werden rotiert, wie in dieser Anleitung beschrieben: Passwortrotation durchführen.

  Können wir die Client-IP-Adresse im HTTP-Header "X-Forwarded-For" zur Zugriffskontrolle verwenden?

  Wir raten dringend davon ab, den HTTP-Header “X-Forwarded-For” für sicherheitsrelevante Zwecke zu verwenden. Stattdessen stellen wir den HTTP-Header “STACKIT-CF-Trusted-IP” bereit. Dieser enthält die Client-IP-Adresse, wie sie von unserem Load Balancer gesehen wird.

  Bitte beachten Sie: Die in “STACKIT-CF-Trusted-IP” enthaltene IP-Adresse kann von der erwarteten Client-IP-Adresse abweichen. Ein Beispiel dafür ist die IP-Adresse des letzten Proxy-Servers vor unserem Load Balancer.

• Web-UI-Konsole

  Alle erweitern

  Wird die Web-UI vollständig unterstützt?

  Die Web-UI-Console mit ihren Einschränkungen wird vom STACKIT Cloud Foundry Team nicht unterstützt und kann zugunsten von Integrationen in das STACKIT Portal und die STACKIT APIs perspektivisch eingestellt werden. Nutzen Sie bei Problemen mit der Web-UI bitte die obigen FAQs für alternative Wege zum Zugriff auf Ihre App-Logs oder für den Zugriff auf App-Container per SSH.

  Ich versuche, eine App aus einem lokalen Ordner oder aus GitHub/GitLab zu deployen, aber es schlägt fehl.

  Beim Deployment einer App aus einem lokalen Ordner oder aus GitHub/GitLab tritt folgender Fehler auf: Failed to deploy app! Reason: Failed dü to !

  Dabei handelt es sich um ein bekanntes Problem, für das es derzeit keinen verbindlichen Zeitrahmen für eine Behebung gibt. Verwenden Sie in der Zwischenzeit bitte den Cloud Foundry CLI-Befehl “cf push”.