Zum Hauptinhalt springen
Version: Weekly Build

Konfigurieren einer Landscape

Eine Landscape definiert, wie deine Services deployed und verbunden werden. Du kannst Compute Runtimes (Reactives, Managed Containers, Cloud Native Deployments) und Managed Services hinzufügen und ihre Ressourcen, Netzwerkeinstellungen und Umgebung konfigurieren. Für einen tieferen technischen Überblick siehe Landscapes & Workspaces.

Jede Konfiguration beginnt im Landscape Config Editor:

  1. Öffne in deinem Workspace den Landscape Config Editor über die Seitenleiste.
  2. Stelle sicher, dass das richtige CI Profile ausgewählt ist (z. B. default oder dev). Falls du eines erstellen musst, siehe CI Profiles verwenden.
  3. Klicke auf den Button + Add New Service auf der rechten Seite des Landscape-Deployment-Bereichs und wähle den gewünschten Service-Typ aus.

Von hier aus kannst du deine Landscape entweder über den visuellen Editor konfigurieren oder die Datei ci.yml direkt bearbeiten.

Speichern von Service-Konfigurationen

Die Landscape-Konfigurationsoberfläche verhält sich wie ein großes Formular, das deine ci.yml-Datei konfiguriert. Du kannst die Konfiguration nur auf der obersten Ebene des Formulars speichern.

Codesphere Reactives

Codesphere Reactives sind Codespheres Flaggschiff-Runtime und lassen sich am besten als zustandsbehaftetes Serverless (stateful serverless) beschreiben. Sie kombinieren persistenten Dateisystemzugriff mit automatischer Ressourcenfreigabe während Leerlaufphasen und nahezu sofortigem Start (Millisekunden). Für einen detaillierten Überblick siehe Runtimes.

Um eine Reactive hinzuzufügen, wähle Reactive Service aus der Auswahl der Service-Typen und konfiguriere sie dann anhand der folgenden Abschnitte.

Runtime-Konfiguration

Landscape Config Editor mit Feldern zur Runtime-Konfiguration eines Reactive Service, einschließlich Ausführungsschritten, Base-Image-Auswahl und Mounting-Pfaden.

Ausführungsschritte

Ausführungsschritte definieren die Befehle, die beim Start deines Service ausgeführt werden. Diese Befehle werden sequenziell ausgeführt und sollten deinen Anwendungsprozess starten.

So fügst du Ausführungsschritte hinzu:

  1. Klicke auf + Add Execution Step
  2. Gib einen Namen für den Schritt ein (z. B. „Start Server“)
  3. Gib den auszuführenden Befehl ein (z. B. npm start oder node server.js)
  4. Wiederhole dies, falls weitere Schritte benötigt werden

Service-Ausführung

Der letzte Schritt sollte typischerweise ein langlaufender Prozess sein (wie ein Webserver). Wenn alle Befehle beendet werden, wird der Service als fehlerhaft markiert: Der Service läuft, aber seine Pipeline wird nicht mehr ausgeführt.

Base-Image-Konfiguration

Reactives verwenden standardmäßig ein von Codesphere gepflegtes, gemeinsam genutztes Ubuntu-Base-Image (Codesphere Defaults). Dieses Image ist vorgewärmt und gepoolt für nahezu sofortigen Start (Millisekunden). Du kannst die Runtime-Umgebung anpassen, indem du Abhängigkeiten über Nix installierst. Für erweiterte Anwendungsfälle steht außerdem die Option Custom Base Image zur Verfügung, die als Grundlage für Managed Containers dient.

Mounting-Pfade

Standardmäßig mounten alle Reactive Services das gesamte Verzeichnis /home/user/app aus dem gemeinsamen Netzwerk-Dateisystem. Über die Einstellung Mounting Paths kannst du einen Service so einschränken, dass nur ein bestimmtes Unterverzeichnis gemountet wird.

Anwendungsfälle für gemountete Unterverzeichnisse:

  • Isolierung des Dateizugriffs zwischen Services, um versehentliches Überschreiben zu verhindern
  • Verbesserte Sicherheit durch Einschränkung des Dateisystemzugriffs jedes Service
  • Organisation von Multi-Service-Architekturen mit dedizierten Verzeichnissen

warnung

Nur Dateien, die unter /home/user/app geschrieben werden, werden im Netzwerk-Dateisystem persistiert und zwischen allen Services geteilt. Dateien, die anderswo geschrieben werden, existieren nur auf der lokalen Festplatte des jeweiligen Pods und stehen anderen Services oder Replicas nicht zur Verfügung. Diese lokalen Dateien gehen auch bei Workspace-Neustarts verloren, die aufgrund von Skalierung oder Codesphere-Updates auftreten können.

Ressourcen

Bereich „Resources“ im Landscape Config Editor mit Plan-Auswahl, Verfügbarkeitsoptionen, Replica-Steuerung und geschätzter monatlicher Kostenübersicht.

Jeder Service verfügt über einen Resource Plan, der die zugewiesenen vCPUs, den Arbeitsspeicher und den Speicherplatz bestimmt. Die verfügbaren Pläne und deren Preise werden vom Cluster-Administrator konfiguriert und können je nach Installation variieren.

So konfigurierst du die Ressourcen:

  1. Wähle einen Plan aus der Liste (jeder Plan zeigt seine Zuteilung an vCPUs, Arbeitsspeicher und Speicherplatz)
  2. Lege den Availability-Modus fest:
    • Always on: Der Service läuft kontinuierlich – ideal für Produktionsworkloads
    • Off when unused: Der Service stoppt automatisch nach einer Zeit der Inaktivität und startet neu, wenn die Domain oder der Workspace aufgerufen wird – gut geeignet für Preview-Deployments oder Entwicklungsumgebungen
  3. Lege die Anzahl der Default Replicas für horizontale Skalierung über die Steuerelemente / + fest

info

Der Screenshot zeigt unten eine Kostenübersicht mit geschätzten monatlichen Kosten pro Ressource und in Summe. Beachte, dass dies nicht bei allen Installationen sichtbar sein muss.

Details dazu, wie Pläne definiert und angepasst werden, findest du im Artikel Plans Configuration.

Skalierungsstrategien:

TypBeschreibungAm besten geeignet für
Vertikale SkalierungErhöhung von vCPUs/Arbeitsspeicher durch Auswahl eines höheren PlansRechen- oder speicherintensive Workloads
Horizontale SkalierungHinzufügen mehrerer Replicas desselben ServiceBewältigung erhöhter Anfragemengen

Ports & Routes

Bereich „Ports & Routes“ im Landscape Config Editor mit Einstellungen für Health-Checks, freigegebenen Service-Ports und Pfadzuordnungen des Workspace-Routers.

Health-Check

Standardmäßig prüft der Landscape Router deine Reactive Services über Port 3000 auf ihre Funktionsfähigkeit. Du kannst einen benutzerdefinierten Health-Endpoint konfigurieren, z. B. http://localhost:8080/health, falls deine Anwendung einen anderen Port oder Pfad für Health-Checks verwendet. Die Anfrage wird außerdem innerhalb des Service-Containers ausgeführt, sodass die Anwendung unter localhost erreichbar sein muss. Falls sie an eine andere Schnittstelle gebunden ist, gib stattdessen die entsprechende IP-Adresse oder den Hostnamen an.

info

Für jeden Service muss mindestens eine Route definiert sein. Ohne Route erkennt der Workspace Router den Service nicht – er gilt nicht als funktionsfähig und ist von außerhalb der Landscape nicht erreichbar.

Ports konfigurieren

Dieser Abschnitt definiert die Ports, die dein Service freigibt. Die interne Kommunikation zwischen Services sollte interne Port-URLs verwenden, während Ports über den unten stehenden Workspace Router zugänglich gemacht werden können. Das Routing kann zudem über benutzerdefinierte Domains weiter angepasst werden.

Reactives innerhalb einer Landscape kommunizieren über interne URLs: http://ws-server-[WorkspaceId]-[serviceName].workspaces:[port]. Du kannst die interne URL eines Service über den Button Copy auf der rechten Seite kopieren.

So gibst du einen neuen Port frei:

  1. Klicke auf + Add New Port auf der rechten Seite
  2. Gib die Port-Nummer ein, auf der deine Anwendung lauscht
  3. Optional kannst du über das Aktionsmenü (Drei-Punkte-Symbol) in der Port-Zeile eine Public Port URL freigeben. Dies gibt direkt eine öffentliche URL für den Port frei, die über das Kontextmenü kopiert werden kann. Dies ist weniger sicher als Pfad-basiertes Routing und wird typischerweise nur bei älteren Legacy-Frameworks benötigt.

Workspace Router

Routen bilden eingehende HTTP-Anfragen anhand von URL-Pfadpräfixen auf deine Services ab. Der Router unterstützt außerdem die Option Strip Path, die das übereinstimmende Präfix entfernt, bevor die Anfrage an deinen Service weitergeleitet wird.

So fügst du eine Route hinzu:

  1. Klicke auf + Add New Route
  2. Gib das Path-Präfix ein (z. B. /, /api, /admin)
  3. Wähle den Port, an den der Traffic geleitet werden soll
  4. Aktiviere optional Strip Path, um das Präfix vor der Weiterleitung zu entfernen

Der Bereich Routing for Other Services unten zeigt die Routen, die von anderen Services in derselben Landscape definiert wurden – nützlich, um Konflikte zu erkennen oder einen Überblick über die gesamte Routing-Tabelle zu erhalten.

Umgebungsvariablen

Bereich „Environment Variables“ im Landscape Config Editor mit Schlüssel-Wert-Einträgen und auswählbaren Quellen wie Secrets, Workspace-Werten und Team-IDs.

Umgebungsvariablen ermöglichen es dir, Konfigurationswerte an deine Services zu übergeben, ohne diese hart zu kodieren. Sie werden zur Laufzeit injiziert.

So fügst du Umgebungsvariablen hinzu:

  1. Öffne den Bereich Environment Variables in der Service-Konfiguration
  2. Klicke auf + Add New Variable
  3. Gib den Key (Variablennamen) ein
  4. Gib den Value ein, entweder als reinen Text oder durch Auswahl aus den Dropdown-Kategorien: User Inputs, Global Values, Secrets, Global Constants, Team ID oder Workspace ID

Weitere Details findest du unter Umgebungsvariablen.

Managed Containers

Managed Containers basieren im Kern auf Reactives, ermöglichen es dir jedoch, ein eigenes Docker-Image zu verwenden, anstatt das von Codesphere gepflegte Base-Image zu nutzen. Das bedeutet, du erhältst dieselbe Plattform-Orchestrierung, Netzwerkfunktionalität und Überwachung, während du einen benutzerdefinierten Container ausführst. Für einen detaillierten Überblick siehe Runtimes.

Um einen Managed Container hinzuzufügen, wähle Managed Container aus der Auswahl der Service-Typen.

Ansicht der Runtime-Konfiguration eines Managed Container mit Image-Referenz, Startup-Argumenten, Mounting-Pfaden sowie Einstellungen für Run-as-User und Run-as-Group.

Entsprechende barrierefreie Textbeschreibung

Base-Image-Konfiguration:

  • Gib die vollständige Image-Referenz ein (z. B. nginx:1.25-alpine, node:20-slim)
  • Bei privaten Registries stelle sicher, dass entsprechende Zugangsdaten konfiguriert sind
  • Setze Startup Args, um den Standardbefehl des Containers zu überschreiben, falls erforderlich. Der Entrypoint bleibt der Standard des Images. Wenn du den Entrypoint überschreiben möchtest, müsstest du stattdessen Codesphere Reactives verwenden und dein Image als Custom Base Image einsetzen.
  • Setze Mounting Paths (volumeMounts), um zu steuern, welche Verzeichnisse oder Dateien aus dem Workspace in den Container gemountet werden und wohin.

Run As User/Group:

  • Setze die User ID (runAsUser), um festzulegen, unter welchem Benutzerkonto der Service im Container ausgeführt wird.
  • Setze die Group ID (runAsGroup), um festzulegen, zu welcher Benutzergruppe der Service im Container gehört.
  • Diese Einstellungen steuern Dateizugriffs- und Prozessberechtigungen und sollten den Eigentumserwartungen deiner Anwendung und der gemounteten Dateien entsprechen.

Die Zugriffsebene auf das Workspace-Dateisystem hängt davon ab, welche User ID oder Group ID hier eingestellt wird:

  • Mit der User ID 1501 erhält der Container-Prozess denselben Lese-/Schreibzugriff auf die Workspace-Dateien.
  • Mit einer anderen User ID erhält der Container-Prozess Lesezugriff auf alle Dateien und Schreibzugriff auf das Wurzelverzeichnis des gemounteten Volumes, jedoch nicht auf Unterverzeichnisse.
  • Unabhängig von der konfigurierten Group ID fügt Codesphere direkt die GID 1010 für das Workspace-Dateisystem hinzu. Die definierte GID wirkt sich auf die Eigentümergruppe der von deinen Services erstellten Dateien aus.
  • Du kannst Schreibzugriff auf ein bestimmtes Unterverzeichnis für die Group ID einrichten, indem du im Prepare-Stage chmod g+w some-dir ausführst.

Startgeschwindigkeit

Managed Containers haben Startzeiten im Sekundenbereich (im Vergleich zu Millisekunden bei Reactives), da das Image gepullt und initialisiert werden muss. Die tatsächliche Geschwindigkeit hängt von der Image-Größe und der Netzwerkperformance zur Registry ab.

Alle weiteren Konfigurationsoptionen (Ressourcen, Ports, Routes, Umgebungsvariablen) funktionieren genauso wie bei Codesphere Reactives — siehe die Abschnitte oben.

Cloud Native Deployments

Cloud Native Deployments stellen einen virtuellen Managed Kubernetes-Cluster mit vollständigem kubectl-Zugriff bereit, der für fortgeschrittene Orchestrierungsszenarien konzipiert ist. Für einen detaillierten Überblick siehe Virtual Clusters.

Runtime für Experten

Diese Runtime richtet sich an Nutzer mit Vorkenntnissen in Kubernetes. Wenn du neu in der Container-Orchestrierung bist, solltest du zunächst mit Codesphere Reactives oder Managed Containers starten.

Ein Cloud Native Deployment einrichten

  1. Cluster bereitstellen: Füge einen virtuellen Kubernetes-Cluster über den Bereich Managed Services in der UI oder API hinzu. Beachte, dass jedes Team jeweils nur einen virtuellen Cluster haben kann.
  2. Zugriff auf den Cluster: Sobald der Cluster bereitgestellt ist, rufe die kubeconfig über die API ab, um dich mit kubectl zu verbinden.
  3. Workloads deployen: Verwende kubectl-Befehle in den Prepare- oder Run-Schritten oder interagiere direkt über das Terminal.

Plattformintegration

Die tiefe Lifecycle-Integration in die Codesphere ci.yml befindet sich derzeit noch in Entwicklung. Verfügbare Funktionen:

FunktionStatus
Bereitstellung des virtuellen Clusters✅ Verfügbar
kubectl-Zugriff✅ Verfügbar
Helm-Deployments✅ Verfügbar
Monitoring-IntegrationManuelle Konfiguration erforderlich
NetzwerkintegrationManuelle Konfiguration erforderlich

Für sämtliche Plattformfunktionen (automatisches Monitoring, integrierte Netzwerkfunktionen, „Off when unused“) verwende Reactives oder Managed Containers.

Managed Services in Landscapes

Während du eigenständige Managed Services erstellen kannst, die dauerhaft bestehen bleiben, ist es für viele Anwendungsfälle Best Practice, Managed Services als Teil deiner Landscape-Konfiguration zu definieren. Dadurch wird sichergestellt, dass deine Anwendungsumgebungen eigenständig und reproduzierbar sind.

Wenn du beispielsweise eine Development- oder Staging-Landscape startest, kann Codesphere automatisch eine dedizierte PostgreSQL-Datenbank für diese spezifische Umgebung bereitstellen und diese wieder entfernen, wenn die Landscape nicht mehr benötigt wird.

Hinzufügen eines Managed Service zu einer Landscape

Du kannst Managed Services in deiner ci.yml (oder einem bestimmten CI Profile wie ci.dev.yml) über den Landscape Config Editor definieren oder die YAML-Datei direkt bearbeiten.

Ansicht des Landscape-Editors zur Konfiguration eines Managed-Service-Eintrags im ci.yml-Formular.

  1. Typ auswählen: Wähle Databases & More aus dem Dropdown/Modal aus.
  2. Provider wählen: Wähle den benötigten Service aus (z. B. PostgreSQL, Redis, S3).
  3. Konfigurieren: Lege die Version, den Plan und die Konfigurationsparameter fest.
    • Name: Gib einen Namen an (z. B. primary-db). Dieser Name wird verwendet, um den Service innerhalb deiner Landscape zu referenzieren.
  4. Secrets: Definiere die vom Service benötigten Secrets (z. B. Passwörter). Du kannst auf Secrets auf Projektebene verweisen oder neue generieren.
  5. Speichern: Der Service wird nun deinem Landscape-Profil hinzugefügt. Er wird beim nächsten Deployment dieser Landscape bereitgestellt.

Verbindung zum Service herstellen

Sobald ein Managed Service bereitgestellt wurde, kann sich deine Anwendung mit ihm verbinden. Siehe die Managed Service Provider Reference für Provider-spezifische Verbindungsdetails.

Service Discovery & Umgebungsvariablen

Codesphere ermöglicht es dir, Verbindungsdetails über Umgebungsvariablen in deine Anwendung zu injizieren.

  1. Secrets: Du kannst die im Managed Service definierten Secrets direkt an die Umgebungsvariablen deiner Anwendung übergeben.
  2. Hostnamen: Um konkrete Beispiele zur Hostnamenbildung für einen bestimmten Service zu sehen, sieh dir die entsprechende Seite in der Provider Reference an.

Lifecycle-Management

  • Erstellung: Der Managed Service wird erstellt, wenn das entsprechende Landscape Profile (z. B. dev) deployed wird.
  • Updates: Änderungen an der ci.yml-Konfiguration (z. B. Änderung des Plans oder der Konfiguration) aktualisieren den Service beim nächsten Deployment.
  • Pausieren: Wenn die Landscape „Off when unused“ unterstützt, können auch die Managed Services pausiert werden, um Kosten zu sparen (je nach Fähigkeiten des Service).
  • Löschen: Wenn die Landscape gelöscht wird, werden die zugehörigen Managed Services automatisch entfernt, um verwaiste Ressourcen und zusätzliche Kosten zu vermeiden.

Umbenennen von Services

Das Umbenennen eines Managed Service in der ci.yml-Datei erfordert, dass das System ihn neu erstellt, was zu Datenverlust führen kann.

Unterschiede zu eigenständigen Services

MerkmalLandscape Managed ServiceEigenständiger Managed Service
DefinitionDefiniert in der ci.ymlManuell über UI/API erstellt
LifecycleAn die Landscape gebunden (wird mit ihr erstellt/gelöscht)Unabhängig (bleibt bestehen, bis er manuell gelöscht wird)
AnwendungsfallDev-, Test-, Review-UmgebungenProduktion, langlaufende gemeinsam genutzte Datenbanken
KonfigurationInfrastructure as Code (in Git nachverfolgt)Manuelle Konfiguration

Versionierte ci.yml-Schemas

# Example fixture for the current schema after the managed-service provider schemaVersion rename.
# `schemaVersion` pins the fixture to the current pipeline schema.
schemaVersion: v0.4

# `prepare` runs setup before tests and deploys.
prepare:
# `steps` lists sequential setup commands.
steps:
# `name` is a descriptive label only.
- name: Install dependencies
# `command` is the shell command to execute.
command: yarn install

# `test` runs verification commands after setup.
test:
# `steps` keeps the same stage shape as `prepare`.
steps:
# `name` documents the test step.
- name: Run unit tests
# `command` runs the example test suite.
command: yarn test --run

# `run` contains the named deploy targets for the workspace.
run:
# Reactive runtime with the full set of supported server fields.
reactive-app:
# `steps` defines the lifecycle commands for a reactive runtime.
steps:
# Build the app before startup.
- name: Build app
# Produce deployable build output.
command: yarn build
# Start the application process.
- name: Start app
# Launch the runtime server.
command: yarn start
# `image` optionally customizes the reactive base image.
image: ghcr.io/codesphere-cloud/example-reactive:latest
# `healthEndpoint` is probed to determine readiness.
healthEndpoint: http://127.0.0.1:3000/healthz/app
# `plan` selects the workspace plan.
plan: 20
# `replicas` requests horizontal scaling.
replicas: 2
# `isPublic` is ignored when advanced `network` settings are present.
isPublic: true
# `network` defines exposed ports and routed paths.
network:
# `ports` exposes raw runtime ports.
ports:
# `port` is the runtime port number to expose.
- port: 3000
# `isPublic` makes the port reachable from outside the workspace.
isPublic: true
- port: 9229
isPublic: false
# `paths` maps HTTP prefixes onto runtime ports.
paths:
# Route the root path to port `3000`.
- port: 3000
path: /
stripPath: false
# Route `/api` to port `3000` and strip the prefix.
- port: 3000
path: /api
stripPath: true
# `env` injects runtime environment variables.
env:
# Example string env var.
NODE_ENV: production
# Example numeric env var.
PORT: 3000
# `runAsUser` sets the runtime UID.
runAsUser: 1000
# `runAsGroup` sets the runtime GID.
runAsGroup: 1000
# `volumeMounts` attaches workspace storage into the runtime.
volumeMounts:
# `name` selects the workspace volume.
- name: _workspace
# `mountPath` is the destination inside the runtime.
mountPath: /home/user/app
# `workspacePath` selects which subdirectory to mount.
workspacePath: ""

# Container runtime with the full set of supported server fields.
container-app:
# `image` is required for container runtimes.
image: ghcr.io/codesphere-cloud/example-container:latest
# `command` overrides the image entrypoint/command.
command:
# First argv entry.
- node
# Second argv entry.
- server.js
# The rest of the fields are shared with reactive runtimes.
healthEndpoint: http://127.0.0.1:8080/healthz/app
# `plan` selects the workspace plan.
plan: 20
# `replicas` requests horizontal scaling for this runtime.
replicas: 1
# `isPublic` allows the routed service to be reachable externally.
isPublic: true
# This simple network shape publishes one routed path.
network:
# `path` is the public prefix for this service.
path: /container
# `stripPath` controls whether the prefix is preserved upstream.
stripPath: false
env:
# Example string env var.
NODE_ENV: production
# Example numeric env var.
PORT: 8080
# `runAsUser` sets the runtime UID.
runAsUser: 1000
# `runAsGroup` sets the runtime GID.
runAsGroup: 1000
# `volumeMounts` attaches workspace storage into the runtime.
volumeMounts:
# `name` selects the workspace volume.
- name: _workspace
# `mountPath` is the destination inside the runtime.
mountPath: /home/user/app
# `workspacePath` selects which subdirectory to mount.
workspacePath: ""

# Managed service runtime in v0.4:
# - `provider.version` was renamed to `provider.schemaVersion`
# This key names the managed service instance.
postgres:
# `provider` identifies the catalog entry to provision.
provider:
# `name` selects the managed service type.
name: postgres
# `schemaVersion` is the renamed provider version field in v0.4.
schemaVersion: "14"
# `plan` selects the service plan and sizing.
plan:
# `id` identifies the chosen catalog plan.
id: 1
# `parameters` contains provider-specific numeric options.
parameters:
# `storage` requests disk capacity.
storage: 1024
# `cpu` requests compute capacity.
cpu: 1
# `memory` requests RAM capacity.
memory: 512
# `config` contains non-secret provider configuration.
config:
# `database` is an example provider config key.
database: app
# `extensions` shows that lists are allowed in config payloads.
extensions:
- pgcrypto
# `secrets` contains secret provider configuration.
secrets:
# `password` is an example secret key.
password: secret