Landscape-Lebenszyklus

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 einen zugehörigen Workspace – dein Cockpit zur Interaktion mit dieser spezifischen Landscape. Dieser Artikel führt durch den vollständigen Lebenszyklus einer Landscape, von der initialen Erstellung bis zur Löschung.

Initiale Erstellung​

Wenn ein neuer Workspace erstellt wird, ist dieser zunächst an eine leere Landscape angehängt – es werden noch keine Ressourcen außer dem Workspace selbst bereitgestellt, unabhängig davon, ob neu gestartet oder ein bestehendes Projekt geklont wird:

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

Bereitstellung von Ressourcen​

Sobald eine ci.yml-Datei definiert ist, stellt das Synchronisieren der Landscape alle in der Konfiguration festgelegten 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 weiteren Ressourcen, die in der ci.yml referenziert werden

So stellst du deine Landscape bereit oder aktualisierst sie:

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

Codesphere instanziiert daraufhin 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 die Steuerung der Ausführung innerhalb des Pods, ohne die Ressourcen zu deprovisionieren:

• Start: Beginnt die Ausführung deiner Anwendung innerhalb des bereitgestellten Pods.
• Stop: Hält die Ausführung an, während der Pod und seine Ressourcen weiterhin zugewiesen bleiben.

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

Off-When-Unused​

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

• Obwohl synchronisiert, überwacht der Service die Aktivität und fährt sich bei Inaktivität automatisch herunter.
• Wenn eine URL-Anfrage oder eine Anfrage über das Workspace-Cockpit eintrifft, startet der Service automatisch neu.
• Das Workspace-Cockpit selbst wird genau nach diesem Prinzip deployt, wodurch es immer verfügbar ist, wenn es benötigt wird, aber im Leerlauf keine Ressourcen verbraucht.
• Dies funktioniert reibungslos aufgrund des persistenten Volumes, das an jede Landscape angehängt ist und den Zustand deiner Anwendung erhält.

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

• Entwicklungsumgebungen: Entwickler benötigen ihre Umgebung nur während der aktiven Arbeit, nicht rund um die Uhr
• Staging-/Testumgebungen: Tests erfolgen in Schüben, nicht kontinuierlich
• Interne Tools und Admin-Panels: Werden über den Tag verteilt sporadisch genutzt
• Demo-Umgebungen: Nur während Kundendemos oder Testphasen aktiv
• Preview-Deployments: Feature-Branch-Deployments, die nur gelegentlich überprüft werden

Dies trägt zur Optimierung des Ressourcenverbrauchs bei und gewährleistet gleichzeitig sofortige Verfügbarkeit, wenn nötig.

Aktualisieren deiner Landscape​

Eine Landscape-Version sollte immer an einen bestimmten Git-Zustand gebunden sein, der mit dem Dateisystem synchronisiert wurde. Dazu gehören die ci.yml, Konfigurationsdateien und jeglicher ausgeführter Code.

Aktualisierungen bei Entwicklung & Test​

Während der Entwicklung können direkte Änderungen am Dateisystem vorgenommen werden (tatsächliche Code-Änderungen bei der Arbeit mit reaktiven Services oder Konfigurationsänderungen wie 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 bereit, synchronisiere (Sync) die Landscape, um Konfigurationsänderungen anzuwenden.
4. Stoppe und starte die Runtime-Ausführung, um Code-Änderungen anzuwenden.

Aktualisierungen in der Produktion​

Bei Produktions-Landscapes folgen Aktualisierungen typischerweise diesem Ablauf:

1. Committe und pushe Änderungen in dein Git-Repository.
2. Führe im Workspace git pull aus, um die neuesten Änderungen abzurufen.
3. Synchronisiere (Sync) die Landscape, um neue ci.yml-Konfigurationen anzuwenden.
4. Stoppe und starte die Pipeline-Ausführung für die betroffenen Runtimes.
5. Alle diese Schritte können über deine CI-Pipeline automatisiert werden, wodurch nahtlose Aktualisierungen ohne manuellen Eingriff möglich sind.

Verwaltung verschiedener Umgebungen​

Du kannst CI-Profile 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 Produktionsworkloads solltest du Zero-Downtime-Releases in Betracht ziehen, indem du Traffic über eine benutzerdefinierte Domain-Konfiguration zwischen mehreren Landscape-Instanzen leitest.

Teardown​

Eine Landscape kann abgebaut werden (Teardown), ohne dass Daten verloren gehen:

• Alle Ressourcen werden deprovisioniert und in den Instanzpool zurückgeführt.
• 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übergehende Freigabe von Cluster-Ressourcen
• Pausieren eines Projekts, ohne Arbeit zu verlieren

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

Löschung (Ende des Lebenszyklus)​

Wenn ein Workspace über das Workspace-Cockpit gelöscht wird:

• Werden alle Ressourcen deprovisioniert.
• Werden alle persistenten Volumes gelöscht.
• Geht alles, was nicht in Git nachverfolgt wird, dauerhaft verloren.

Wiedererstellung nach der Löschung​

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

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

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

Zusammenfassung des Lebenszyklus (Reactive Runtime)​

Phase	Beschreibung	Datenpersistenz
Erstellung	Leere Landscape, an neuen Workspace angehängt	Nicht zutreffend
Bereitstellung	Ressourcen basierend auf ci.yml zugewiesen	Volumes erstellt
Läuft	Services aktiv und verarbeiten Traffic	Daten in Volumes
Gestoppt	Ausführung angehalten, Ressourcen weiterhin zugewiesen	Daten in Volumes
Teardown	Ressourcen deprovisioniert, Volumes bleiben erhalten	Daten erhalten
Löschung	Vollständige Entfernung einschließlich Volumes	Daten verloren