Landscape Lifecycle

Eine Landscape ist eine Deployment-Konfiguration deiner Anwendung und ihrer Architektur, definiert durch die ci.yml-Datei. Sie legt fest, welche Services ausgeführt werden, wie sie miteinander verbunden sind und wie Ressourcen zugewiesen werden. Jede Landscape-Instanz verfügt über eine zugehörige Workspace—dein Cockpit für die Interaktion mit dieser spezifischen Landscape. Dieser Artikel führt dich durch den vollständigen Lebenszyklus einer Landscape, von der ersten Erstellung bis zur Löschung.

Initiale Erstellung​

Wenn du eine neue Workspace erstellst, ist diese zunächst mit einer leeren Landscape verbunden—außer der Workspace selbst werden noch keine Ressourcen bereitgestellt, unabhängig davon, ob du ein neues Projekt startest oder ein bestehendes klonst:

• Neue Projekte: Deine Landscape wartet auf eine ci.yml-Konfiguration, die festlegt, was deployt werden soll.
• Bestehende Projekte: Selbst wenn du ein Git-Repository klonst, das bereits eine ci.yml enthält, werden die Landscape-Ressourcen erst bereitgestellt, wenn du sie synchronisierst (siehe Provisioning Resources).
• Deine Workspace kann verwendet werden, um Build- und Prepare-Schritte für deine Anwendung auszuführen.
• Du kannst die Cloud IDE verwenden, um Dateien zu bearbeiten, einschließlich der ci.yml, und Änderungen in Echtzeit zu testen.

Bereitstellung von Ressourcen​

Sobald du eine ci.yml-Datei definiert hast, stellt das Synchronisieren der Landscape alle in deiner Konfiguration angegebenen Ressourcen bereit:

• Pods und Replicas für deine Runtime-Deployments
• Managed Services (z. B. Datenbanken, Caches, Message Queues)
• Virtuelle Maschinen
• Landscape-Router für Netzwerkregeln und Routing-Konfiguration
• Alle anderen Ressourcen, die in der ci.yml referenziert werden

So provisionierst oder aktualisierst du deine Landscape:

1. Navigiere zum Execution Manager in deiner Workspace.
2. Klicke auf die Schaltfläche Sync, um deine ci.yml-Konfiguration anzuwenden.

Codesphere instanziiert dann alle definierten Ressourcen und verbindet sie über das private Netzwerk.

Runtime-Operationen​

Bestimmte Runtime-Typen (wie Codesphere Reactives und Container Runtimes) unterstützen eine feinere Steuerung als nur das Synchronisieren:

Start, Stop und Restart​

Diese Runtimes ermöglichen es dir, die Ausführung innerhalb des Pods zu steuern, ohne die Ressourcen zu deprovisionieren:

• Start: Beginn der Ausführung deiner Anwendung innerhalb des bereitgestellten Pods.
• Stop: Ausführung anhalten, während der Pod und seine Ressourcen weiterhin zugewiesen bleiben.

Diese Operationen werden über den Execution Manager in deiner Workspace verwaltet.

Off-When-Unused​

Viele Runtime-Typen unterstützen ein off-when-unused-Konfigurationsflag:

• Obwohl der Service synchronisiert ist, überwacht er die Aktivität und fährt automatisch herunter, wenn er im Leerlauf ist.
• Wenn eine URL-Anfrage oder eine Anfrage über das Workspace-Cockpit eingeht, startet der Service automatisch neu.
• Das Workspace-Cockpit selbst wird genau nach diesem Prinzip deployt, sodass es immer verfügbar ist, wenn du es brauchst, aber im Leerlauf keine Ressourcen verbraucht.
• Dies funktioniert nahtlos aufgrund des persistenten Volumes, das mit jeder Landscape verbunden ist und deinen Anwendungszustand bewahrt.

Ideale Anwendungsfälle für off-when-unused:​

• Entwicklungsumgebungen: Entwickler benötigen ihre Umgebung nur, während sie aktiv damit arbeiten, nicht 24/7
• Staging-/Testumgebungen: Tests erfolgen in Schüben, nicht kontinuierlich
• Interne Tools und Admin-Panels: Werden nur sporadisch über den Tag verteilt genutzt
• Demo-Umgebungen: Nur während Kunden-Demos oder Testphasen aktiv
• Preview-Deployments: Feature-Branch-Deployments, die nur gelegentlich überprüft werden

Dies hilft, den Ressourcenverbrauch zu optimieren und dabei sofortige Verfügbarkeit bei Bedarf zu gewährleisten.

Aktualisieren deiner Landscape​

Eine Landscape-Version sollte immer an einen bestimmten Git-Zustand gebunden sein, der mit dem Dateisystem synchronisiert ist. Dies umfasst die ci.yml, Konfigurationsdateien und jeglichen ausgeführten Code.

Updates während Entwicklung & Testing​

Während der Entwicklung kannst du direkte Änderungen am Dateisystem vornehmen (tatsächliche Codeänderungen bei der Arbeit mit reaktiven Services oder Konfigurationsänderungen wie in der ci.yml für andere Runtimes):

1. Bearbeite Dateien in der Cloud IDE oder im Terminal.
2. Führe die Build- und Prepare-Schritte aus (falls zutreffend)
3. Wenn du bereit bist, führe Sync für die Landscape aus, um Konfigurationsänderungen anzuwenden.
4. Stoppe und starte die Runtime-Ausführung, um Codeänderungen anzuwenden.

Updates in der Produktion​

Bei Produktions-Landscapes folgen Updates typischerweise diesem Ablauf:

1. Committe und pushe Änderungen in dein Git-Repository.
2. Führe in der Workspace git pull aus, um die neuesten Änderungen abzurufen.
3. Führe Sync für die Landscape aus, um neue ci.yml-Konfigurationen anzuwenden.
4. Stoppe und starte die Pipeline-Ausführung für die betreffenden Runtimes.
5. Alle diese Schritte können über deine CI-Pipeline automatisiert werden, was nahtlose Updates ohne manuelle Eingriffe ermöglicht.

Verwaltung unterschiedlicher Umgebungen​

Du kannst CI Profiles verwenden, um unterschiedliche Konfigurationen für Entwicklungs-, Staging- und Produktionsumgebungen zu pflegen. Jedes Profil erstellt eine separate ci.yml-Variante (z. B. ci.dev.yml, ci.prod.yml), sodass du problemlos zwischen umgebungsspezifischen Konfigurationen wechseln kannst.

Zero-Downtime-Deployments​

Für Produktions-Workloads solltest du die Umsetzung von Zero-Downtime-Releases in Betracht ziehen, indem du den Traffic über eine Custom-Domain-Konfiguration zwischen mehreren Landscape-Instanzen routest.

Teardown​

Du kannst eine Landscape abbauen (Teardown), ohne deine Daten zu verlieren:

• Alle Ressourcen werden deprovisioniert und in den Instance Pool zurückgegeben.
• Persistente Volumes bleiben erhalten, wodurch der Zustand und die Daten deiner Anwendung bewahrt werden.
• Die Landscape kann jederzeit erneut synchronisiert werden, um Ressourcen wieder bereitzustellen und genau dort weiterzumachen, wo sie aufgehört hat.

Dies ist nützlich für:

• Kosteneinsparungen bei Nicht-Produktionsumgebungen außerhalb der Nutzungszeiten
• Vorübergehendes Freigeben von Cluster-Ressourcen
• Pausieren eines Projekts, ohne Arbeit zu verlieren

Um eine Landscape abzubauen, verwende die Option Teardown im Execution Manager.

Löschung (Ende des Lebenszyklus)​

Wenn du eine Workspace über das Workspace-Cockpit löschst:

• Alle Ressourcen werden deprovisioniert.
• Alle persistenten Volumes werden gelöscht.
• Alles, was nicht in Git nachverfolgt wird, geht dauerhaft verloren.

Neuerstellung nach der Löschung​

Solange deine ci.yml (Infrastructure as Code) alles enthält, was du benötigst:

• Kannst du eine neue Workspace erstellen.
• Die ci.yml aus deinem Git-Repository synchronisieren.
• Eine neue Instanz mit derselben Konfiguration starten.

Dies zeigt die Stärke des deklarativen Ansatzes—deine gesamte Infrastruktur kann aus versionierten Konfigurationsdateien wiederhergestellt werden.

Zusammenfassung des Lebenszyklus (Reactive Runtime)​

Phase	Beschreibung	Datenpersistenz
Erstellung	Leere Landscape, verbunden mit neuer Workspace	Nicht zutreffend
Bereitstellung	Ressourcen werden basierend auf der ci.yml zugewiesen	Volumes werden erstellt
Laufend	Services sind aktiv und bedienen Traffic	Daten in Volumes
Gestoppt	Ausführung angehalten, Ressourcen weiterhin zugewiesen	Daten in Volumes
Teardown	Ressourcen deprovisioniert, Volumes bleiben erhalten	Daten bleiben erhalten
Löschung	Vollständige Entfernung einschließlich Volumes	Daten verloren