App-Umgebungen

Jede Ressource einer App gehört zu genau einer Umgebung. Die Seite einer Umgebung enthält, was ihre Ressourcen gemeinsam nutzen: die Nodes, die sie verwenden dürfen, die Variablen und Secrets, die jeder Workload erhält, die Wartung für alle ihre Routen und die Übernahme aus einer oder in eine andere Umgebung. Öffnen Sie sie über die Registerkarte Overview oder den Block Environments der Registerkarte Settings der App.

Erlaubte Nodes

Eine Umgebung erstellt Ressourcen nur auf den Nodes, die sie erlaubt. Eine neue Umgebung erlaubt keinen. Verwenden Sie Allow node auf der Seite der Umgebung, um einen Node hinzuzufügen; die Registerkarte Nodes der App zeigt die erlaubten Nodes jeder Umgebung.

Die Regel gilt überall, nicht nur in der Konsole: Die REST API, MCP und der KI-Assistent verweigern es, einen Container, ein Deployment, ein Compose-Projekt, eine verwaltete Datenbank, einen verwalteten Speicher, eine Route oder ein Pages-Projekt der Umgebung auf einem Node zu erstellen, den sie nicht erlaubt, und dasselbe gilt für Migration, Workload Availability und die Wiederherstellung eines Backups in eine neue Datenbank. Erlaubt die Umgebung keinen Node des benötigten Typs, wird die Anfrage mit „no allowed node“ abgelehnt; nennt sie einen Node, der nicht erlaubt ist, mit „node not allowed“.

Einen Node aus der Liste zu entfernen ist jederzeit erlaubt. Die Bestätigung zeigt, wie viele Ressourcen der Umgebung dort laufen; sie laufen weiter, es können dort aber keine neuen mehr erstellt werden.

Variablen und Secrets

Der Block Variables legt Werte fest, die jeder Container, jedes Deployment und jeder Compose-Dienst der Umgebung erhält. Secrets funktionieren genauso, sind aber nur schreibbar: Nach dem Speichern werden nur ihre Schlüssel und der Zeitpunkt ihrer letzten Änderung angezeigt. Beide werden verschlüsselt gespeichert. Eine Umgebung enthält bis zu 200 Schlüssel mit Werten von jeweils bis zu 32 KiB, und ein Schlüssel ist entweder eine Variable oder ein Secret, nicht beides. Pages-Projekte erhalten keine Variablen.

Ist ein Schlüssel an mehreren Stellen gesetzt, gewinnt der spezifischere Wert, vom niedrigsten zum höchsten:

1. das eigene ENV des Images;
2. Variablen der Umgebung;
3. Secrets der Umgebung;
4. die eigenen Umgebungsvariablen der Ressource (bzw. die Variablen des Compose-Projekts);
5. die eigenen Secrets der Ressource.

Die Registerkarte Environment eines Containers kennzeichnet die Schlüssel, die aus der Umgebung stammen. Die Werte der Umgebung werden niemals in die eigenen Einstellungen der Ressource kopiert, daher ändert eine spätere Änderung, was die Ressource erhält. Ein Compose-Dienst erhält jeden Schlüssel der Umgebung, den er nicht selbst setzt; die Werte werden nicht in die Compose-Datei geschrieben.

Save oder Save and recreate

Laufende Workloads starten nicht neu, wenn Sie die Werte der Umgebung ändern. Nach Save gibt der Hinweis an, wie viele Workloads die neuen Werte bei ihrer nächsten Neuerstellung oder ihrem nächsten Deployment erhalten.

Um sie sofort anzuwenden, verwenden Sie More → Save and recreate N workloads. Dabei werden die Workloads nacheinander neu erstellt: Container werden neu erstellt, Deployments durchlaufen ihren normalen Rollout, und Compose-Projekte werden angewendet. Der Dialog zeigt den Fortschritt jedes Workloads und hält beim ersten Fehler an, den er benennt; die nachfolgenden Workloads werden nicht angerührt.

Ein Workload, der in eine andere Umgebung wechselt, erhält die Werte der neuen Umgebung bei seiner nächsten Neuerstellung, und die Schlüssel der alten Umgebung werden entfernt. Ein Workload, der aus der App herausgenommen wird, verliert die Schlüssel der Umgebung bei seiner nächsten Neuerstellung.

Wartung

Maintenance auf der Seite der Umgebung versetzt alle Routen der Umgebung auf einmal in Wartung: Sie liefern die Wartungsseite (HTTP 503), bis Sie sie wieder ausschalten. Die eigene Wartungseinstellung jeder Route bleibt erhalten und gilt danach wieder. Der Block zeigt Off, Maintenance oder wie viele Routen ihre eigene Wartung aktiviert haben, während der Schalter der Umgebung aus ist.

Maintenance for the whole app auf der Registerkarte Settings der App bewirkt dasselbe für jede Route jeder Umgebung und überschreibt den Schalter jeder Umgebung; die Seite der Umgebung zeigt dann Overridden by the app. Das Ausschalten stellt den eigenen Zustand jeder Umgebung wieder her.

Betroffen sind nur Routen, die an einen Upstream weiterleiten, wie beim eigenen Schalter der Route. Die Seite einer Route zeigt, woher ihre Wartung stammt.

Zugangscode für die Wartung

Um eine Person durchzulassen, während die Routen in Wartung sind, öffnen Sie das Aktionsmenü der Umgebung (oder der App) und wählen Sie Create Maintenance Access Code. Der Code ist 5 Minuten gültig und öffnet jede Route dieser Umgebung (bzw. der gesamten App), die in Wartung ist, einmal. Geben Sie ihn nur an die Person weiter, die Zugriff benötigt. Die Routen müssen auf einem Ingress Node laufen, der Zugangscodes unterstützt, und ein Code funktioniert nie, solange die App isoliert ist. Wie ein Code eingegeben wird, steht unter Access Lists und Wartung.

Übernehmen

Der Block Promote führt in einer anderen Umgebung genau das aus, was in dieser läuft, ohne etwas neu zu bauen. So gelangt ein getestetes staging nach production.

1. Wählen Sie auf der Seite der Quellumgebung Promote to <environment>. Bei mehr als zwei Umgebungen wählen Sie zuerst das Ziel.
2. Schritt 1 listet auf, was in der Quelle läuft und wie es sich im Vergleich zum Ziel verhält: Same, Changed oder Not promotable mit dem Grund. Schalten Sie ab, was nicht übernommen werden soll.
3. Schritt 2 zeigt, was im Ziel für jeden Eintrag geschieht.
4. Bestätigen Sie. Die Einträge laufen nacheinander; ein Fehler stoppt die anderen nicht. Der Dialog zeigt den Fortschritt jedes Eintrags.

Was übernommen wird:

• Container und Deployments: das Image über seinen Digest, sodass das Ziel Byte für Byte dasselbe Image ausführt. Ein Deployment verwendet seinen normalen Rollout. Ein in Git gebautes Image wird als dasselbe Build-Artefakt übernommen, ohne neuen Build.
• Compose-Projekte: die Compose-Datei der Quellrevision, wobei das Image jedes Dienstes auf den Digest festgelegt wird, der in der Quelle läuft. Das Ziel behält seine eigenen Variablen und Secrets.
• Pages-Projekte: das aktive Deployment der Quelle wird in das Zielprojekt kopiert und dort aktiv.

Datenbanken, Speicher, ihre Daten und ihr Schema werden niemals übernommen.

Ressourcen werden anhand des Namens gepaart: derselbe Name oder der Quellname ohne ein abschließendes -<environment> (shop-api-staging in staging wird mit shop-api in production gepaart). Eine Quellressource ohne Partner wird als nicht im Ziel vorhanden aufgeführt. Ein Paar unterschiedlicher Typen, etwa ein Deployment und ein Container, kann nicht übernommen werden.

Die Vorschau wird beim Bestätigen erneut geprüft; hat sich inzwischen etwas geändert, bittet Opfield Sie, sie erneut zu prüfen. Jede Übernahme wird auf der Registerkarte Activity der App mit den Änderungen erfasst, und der Block Promote der Umgebung zeigt, wann zuletzt etwas in sie übernommen wurde.

Berechtigungen

Das Verwalten erlaubter Nodes, Variablen, Secrets, Wartung und Zugangscodes erfordert die Rolle Developer auf der Umgebung (apps:env:manage). Das Übernehmen erfordert die Rolle Deployer auf der Zielumgebung (apps:promote). Die Wartung für die gesamte App erfordert die Rolle Operator auf der App. Die Seite der Umgebung selbst erfordert apps:view auf der Umgebung; ein Benutzer, der die Umgebung nur über ihre Ressourcen sieht, wird zur App-Seite zurückgeleitet. Siehe Berechtigungen für Apps.