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:
- Öffne in deinem Workspace den Landscape Config Editor über die Seitenleiste.
- Stelle sicher, dass das richtige CI Profile ausgewählt ist (z. B.
defaultoderdev). Falls du eines erstellen musst, siehe CI Profiles verwenden. - 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
- UI
- YAML
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:
- Klicke auf + Add Execution Step
- Gib einen Namen für den Schritt ein (z. B. „Start Server“)
- Gib den auszuführenden Befehl ein (z. B.
npm startodernode server.js) - 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.
run:
my-service:
# Only mounts /home/user/app/uploads
volumeMounts:
- name: _workspace
mountPath: /home/user/app
workspacePath: uploads
steps:
- name: Start Server
command: npm start
- steps: Liste der Ausführungsschritte, jeweils mit einem
nameundcommand. Die Befehle werden beim Start des Service sequenziell ausgeführt. - volumeMounts (optional): Beschränkt den Service auf ein Unterverzeichnis von
/home/user/app.
Beispielbefehle:
npm start— Node.js-Anwendunguv run uvicorn main:app --port 3000 --host 0.0.0.0— Python-Anwendung./gradlew bootRun— Spring-Boot-Anwendung
Ressourcen
- UI
- YAML

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:
- Wähle einen Plan aus der Liste (jeder Plan zeigt seine Zuteilung an vCPUs, Arbeitsspeicher und Speicherplatz)
- 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
- 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:
| Typ | Beschreibung | Am besten geeignet für |
|---|---|---|
| Vertikale Skalierung | Erhöhung von vCPUs/Arbeitsspeicher durch Auswahl eines höheren Plans | Rechen- oder speicherintensive Workloads |
| Horizontale Skalierung | Hinzufügen mehrerer Replicas desselben Service | Bewältigung erhöhter Anfragemengen |
run:
api-server:
plan: 21 # Resource tier (determines CPU/memory)
replicas: 3 # Number of instances
steps:
- name: Start Server
command: node server.js
- plan: Die Resource-Tier-ID, die die Zuteilung von CPU und Arbeitsspeicher bestimmt.
- replicas (optional): Anzahl der Service-Instanzen für horizontale Skalierung. Standardmäßig 1.
tipp
Für Entwicklungsumgebungen bieten kleinere Pläne mit aktiviertem „Off when unused“ deutliche Kosteneinsparungen. Reserviere größere Pläne und mehrere Replicas für Produktionsworkloads.
Ports & Routes
- UI
- YAML

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:
- Klicke auf + Add New Port auf der rechten Seite
- Gib die Port-Nummer ein, auf der deine Anwendung lauscht
- 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:
- Klicke auf + Add New Route
- Gib das Path-Präfix ein (z. B.
/,/api,/admin) - Wähle den Port, an den der Traffic geleitet werden soll
- 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.
run:
backend:
healthEndpoint: http://localhost:8080/health
network:
ports:
- port: 8080
isPublic: false
paths:
- port: 8080
path: /api
steps:
- command: npm run start:backend
- healthEndpoint (optional): Benutzerdefinierte Health-Check-URL. Standardmäßig
http://localhost:3000/. Die Anfrage wird 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. - network.ports: Liste der Ports, die der Service freigibt. Setze
isPublic: true, um eine direkte öffentliche URL freizugeben (nicht empfohlen). - network.paths: Ordnet URL-Pfadpräfixe den Ports für den Workspace Router zu.
Beispiel für eine Routing-Konfiguration:
| Pfad | Service | Beschreibung |
|---|---|---|
/ | frontend | Haupt-UI der Anwendung |
/api | backend | REST-API-Endpunkte |
/ws | websocket-server | WebSocket-Verbindungen |
Umgebungsvariablen
- UI
- YAML

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:
- Öffne den Bereich Environment Variables in der Service-Konfiguration
- Klicke auf + Add New Variable
- Gib den Key (Variablennamen) ein
- 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.
run:
my-service:
env:
NODE_ENV: production
SECRET_KEY: ${{ vault.secretFoo }}
DB_PASSWORD: ${{ vault.dbPassword }}
PG_USER: ${{ workspace.env['BACKEND_PG_USER'] }}
- env: Schlüssel-Wert-Paare, die zur Laufzeit als Umgebungsvariablen injiziert werden.
Template-Syntax für Werte:
| Template | Beschreibung |
|---|---|
${{ vault.NAME }} | Verweist auf ein Secret aus dem Codesphere Vault |
${{ workspace.id }} | Löst sich zur Workspace-ID auf |
${{ team.id }} | Löst sich zur Team-ID auf |
${{ workspace.env['KEY'] }} | Verweist auf eine globale Workspace-Umgebungsvariable |
Secrets werden verschlüsselt gespeichert und erst zur Laufzeit injiziert. Details dazu findest du unter Secret Management.
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.
- UI
- YAML
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
1501erhä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
1010fü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-dirausfü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.
run:
alpine-image:
image: alpine:latest
steps:
- name: Run Alpine
command: echo "Hello from Alpine!"
plan: 21
network:
ports:
- port: 80
isPublic: false
paths:
- port: 80
path: /
nginx-server:
image: nginx-unprivileged:1.25-alpine
command: ["-g", "daemon off;"]
plan: 21
healthEndpoint: http://localhost/
network:
ports:
- port: 80
isPublic: false
paths:
- port: 80
path: /
env:
NGINX_HOST: example.com
volumeMounts:
- name: _workspace
mountPath: /etc/nginx/nginx.conf
workspacePath: custom-nginx.conf
runAsUser: 1000
runAsGroup: 1000
- image: Das zu verwendende Docker-Image (z. B.
nginx-unprivileged:1.25-alpine,node:20-slim,myregistry.com/repo/myimage:tag). - runAsUser / runAsGroup (optional): Legt die User- und Group-ID fest, unter denen der Container ausgeführt wird.
- command (optional): Überschreibt den Standardbefehl des Containers. Als Array von Argumenten angeben (z. B.
["-g", "daemon off;"]). Der Entrypoint bleibt der Standard des Images. Dieses Feld schließt sich mitstepsgegenseitig aus und kann nicht im selben Service verwendet werden. - volumeMounts (optional): Du kannst Dateien und Ordner aus dem Workspace in beliebige Pfade im Container mounten.
- Alle weiteren Felder (
plan,network,envusw.) funktionieren genauso wie bei Reactives.
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
- UI
- YAML
- 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.
- Zugriff auf den Cluster: Sobald der Cluster bereitgestellt ist, rufe die kubeconfig über die API ab, um dich mit
kubectlzu verbinden. - Workloads deployen: Verwende
kubectl-Befehle in den Prepare- oder Run-Schritten oder interagiere direkt über das Terminal.
K8s-Manifeste über kubectl deployen:
prepare:
steps:
- name: Deploy Application
command: |
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml
Ein Helm-Chart deployen:
prepare:
steps:
- name: Deploy with Helm
command: |
helm repo add corp42 https://charts.corp42.net
helm repo update
helm install my-release corp42/my-awesome-app -n app --create-namespace -f values-codesphere.yaml
Plattformintegration
Die tiefe Lifecycle-Integration in die Codesphere ci.yml befindet sich derzeit noch in Entwicklung. Verfügbare Funktionen:
| Funktion | Status |
|---|---|
| Bereitstellung des virtuellen Clusters | ✅ Verfügbar |
| kubectl-Zugriff | ✅ Verfügbar |
| Helm-Deployments | ✅ Verfügbar |
| Monitoring-Integration | Manuelle Konfiguration erforderlich |
| Netzwerkintegration | Manuelle 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.
- UI
- YAML

- Typ auswählen: Wähle Databases & More aus dem Dropdown/Modal aus.
- Provider wählen: Wähle den benötigten Service aus (z. B. PostgreSQL, Redis, S3).
- 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.
- Name: Gib einen Namen an (z. B.
- Secrets: Definiere die vom Service benötigten Secrets (z. B. Passwörter). Du kannst auf Secrets auf Projektebene verweisen oder neue generieren.
- Speichern: Der Service wird nun deinem Landscape-Profil hinzugefügt. Er wird beim nächsten Deployment dieser Landscape bereitgestellt.
Du kannst Managed Services in deiner ci.yml-Datei definieren. Dies ist nützlich für „Infrastructure as Code“-Ansätze. Die UI generiert dieses YAML ebenfalls für dich, du kannst es aber auch manuell schreiben, wenn du das bevorzugst.
-
Profil bearbeiten: Klicke oben rechts auf Edit as File und bearbeite die Profildefinition, um einen neuen Service im Abschnitt
runhinzuzufügen. Dieses Beispiel definiert eine PostgreSQL-Datenbank.schemaVersion: v0.2# ... existing prepare and run stages ...run:my-postgres-db:provider:name: postgresversion: v1plan:id: 0parameters:storage: 10000cpu: 5memory: 500config:version: "17.6"userName: "${{ workspace.env.pgUser }}"databaseName: "${{ workspace.env.pgDb }}"secrets:userPassword: "${{ vault.pgPassword }}"superuserPassword: "${{ vault.pgSuperuserPassword }}"- Key (z. B.
my-postgres-db): Der Name und eindeutige Bezeichner dieses Service in der Landscape.warnung
Das Umbenennen eines Service erfordert, dass das System ihn neu erstellt, was zu Datenverlust führen kann. Gehe hier mit Vorsicht vor.
- provider: Der Typ des Service (entspricht dem Provider-Namen im Katalog).
- secrets: Kann über die Syntax
${{ vault.NAME }}auf Codesphere-Vault-Secrets verweisen.

info
Die Definition des Managed Service muss eine gültige Provider-Konfiguration für den Service verwenden, den du deployst (z. B. Plan-IDs, Versionen und Konfigurationsparameter). Die zulässigen Werte findest du, indem du den Endpunkt
get providerin der Codesphere Public API aufrufst, oder indem du die anfängliche Grundstruktur über die UI erstellst, bevor du dieYAML-Datei manuell bearbeitest. - Key (z. B.
-
Speichern: Speichere das Profil (Strg + S bzw. Cmd + S)
-
Landscape synchronisieren: Öffne den Tab Execution Manager und klicke oben in der Mitte des Landscape-Deployment-Bereichs auf Sync Landscape. Bestätige den Ressourcenverbrauch. Dadurch werden die Änderungen auf das Profil angewendet und die Bereitstellung der Managed Services ausgelöst.

-
Secrets: Gib die erforderlichen Secrets ein, die du zuvor zur Definition des Managed Service verwendet hast. In diesem Beispiel
pgPasswordundpgSuperuserPassword. Diese werden sicher im Codesphere-Vault gespeichert und in den Service injiziert, wenn dieser bereitgestellt wird.
Der Service wird nun erstellt und steht deiner Anwendung zur Verbindung zur Verfügung, sobald du diese Landscape deployst.
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.
- Secrets: Du kannst die im Managed Service definierten Secrets direkt an die Umgebungsvariablen deiner Anwendung übergeben.
- 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
| Merkmal | Landscape Managed Service | Eigenständiger Managed Service |
|---|---|---|
| Definition | Definiert in der ci.yml | Manuell über UI/API erstellt |
| Lifecycle | An die Landscape gebunden (wird mit ihr erstellt/gelöscht) | Unabhängig (bleibt bestehen, bis er manuell gelöscht wird) |
| Anwendungsfall | Dev-, Test-, Review-Umgebungen | Produktion, langlaufende gemeinsam genutzte Datenbanken |
| Konfiguration | Infrastructure as Code (in Git nachverfolgt) | Manuelle Konfiguration |
Versionierte ci.yml-Schemas
- v0.4
- v0.3
- v0.2
- v0.1
# 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
# Example fixture for the v0.2 -> v0.3 migration where workspace mounts become explicit.
# `schemaVersion` selects the v0.3 parser rules.
schemaVersion: v0.3
# `prepare` runs setup work before tests and deploys.
prepare:
# `steps` lists the stage commands in execution order.
steps:
# `name` labels the step for humans.
- name: Install dependencies
# `command` is the shell command to run.
command: yarn install
# `test` runs verification after `prepare`.
test:
# `steps` keeps the same shape across all single-running stages.
steps:
# `name` documents the purpose of the test step.
- name: Run unit tests
# `command` runs the tests.
command: yarn test --run
# `run` contains named deploy targets.
run:
# v0.3 keeps the v0.2 deploy shapes, but makes workspace mounts explicit.
reactive-app:
# `steps` marks this target as a reactive runtime.
steps:
# Build before startup.
- name: Build app
# Produce the deployable app bundle.
command: yarn build
# Start the runtime process.
- name: Start app
# Launch the application server.
command: yarn start
# `image` optionally customizes the reactive base image.
image: ghcr.io/codesphere-cloud/example-reactive:latest
# `healthEndpoint` is polled after deployment.
healthEndpoint: http://127.0.0.1:3000/healthz/app
# `plan` selects the workspace plan for this runtime.
plan: 20
# `replicas` requests multiple runtime instances.
replicas: 2
# `isPublic` is ignored here because the advanced network shape is used below.
isPublic: true
# `network` configures public ports and HTTP routes.
network:
# `ports` exposes runtime ports directly.
ports:
# `port` is the runtime port number.
- port: 3000
# `isPublic` exposes this port externally.
isPublic: true
- port: 9229
isPublic: false
# `paths` maps HTTP routes to runtime ports.
paths:
# Route `/` to port `3000`.
- port: 3000
path: /
stripPath: false
# Route `/api` to the same port and strip the prefix.
- port: 3000
path: /api
stripPath: true
# `env` provides environment variables to the runtime.
env:
# String env var example.
NODE_ENV: production
# Numeric env var example.
PORT: 3000
# `runAsUser` sets the effective UID inside the runtime.
runAsUser: 1000
# `runAsGroup` sets the effective GID inside the runtime.
runAsGroup: 1000
# In v0.3 this commonly explicit mount becomes important.
volumeMounts:
# `name` refers to the workspace volume.
- name: _workspace
# `mountPath` is the in-container destination.
mountPath: /home/user/app
# `workspacePath` of `""` mounts the workspace root.
workspacePath: ""
# This target demonstrates the container-runtime branch of the schema.
container-app:
# `image` is the required runtime image.
image: ghcr.io/codesphere-cloud/example-container:latest
# `command` overrides the image startup command.
command:
# First argv segment.
- node
# Second argv segment.
- server.js
# Common deploy-server fields are shared with reactive runtimes.
healthEndpoint: http://127.0.0.1:8080/healthz/app
# `plan` selects the workspace plan for this runtime.
plan: 20
# `replicas` requests the instance count.
replicas: 1
# `isPublic` allows the simple network route to be exposed publicly.
isPublic: true
# This simple network shape publishes a single HTTP route.
network:
# `path` is the public route prefix.
path: /container
# `stripPath: false` forwards the full incoming path.
stripPath: false
env:
# String env var example.
NODE_ENV: production
# Numeric env var example.
PORT: 8080
# `runAsUser` sets the effective UID inside the runtime.
runAsUser: 1000
# `runAsGroup` sets the effective GID inside the runtime.
runAsGroup: 1000
# `volumeMounts` makes the workspace available inside the container.
volumeMounts:
# `name` refers to the workspace volume.
- name: _workspace
# `mountPath` is the in-container destination.
mountPath: /home/user/app
# `workspacePath` of `""` mounts the workspace root.
workspacePath: ""
# Managed service runtime in v0.3 still uses `provider.version`.
# This key names the service instance.
postgres:
# `provider` identifies the managed service type and version.
provider:
# `name` selects the provider implementation.
name: postgres
# `version` is still the field name before v0.4.
version: "14"
# `plan` chooses the service plan and parameters.
plan:
# `id` identifies the selected plan.
id: 1
# `parameters` carries provider-defined numeric sizing inputs.
parameters:
# `storage` requests persistent disk capacity.
storage: 1024
# `cpu` requests compute units for the service.
cpu: 1
# `memory` requests RAM for the service.
memory: 512
# `config` carries non-secret provider inputs.
config:
# `database` is a provider-defined config field.
database: app
# `extensions` shows that provider config can include lists.
extensions:
- pgcrypto
# `secrets` carries sensitive provider inputs.
secrets:
# `password` is a provider-defined secret value.
password: secret
# Example fixture for the first versioned pipeline schema with deploy runtimes.
# `schemaVersion` selects the parser rules for this fixture.
schemaVersion: v0.2
# `prepare` runs initial setup before tests and deployment.
prepare:
# Steps are executed sequentially inside the stage.
steps:
# Step names are descriptive only.
- name: Install dependencies
# Commands contain the shell instruction to execute.
command: yarn install
# `test` runs verification work after `prepare`.
test:
# Test steps use the same stage shape as `prepare`.
steps:
# This name explains what the test step does.
- name: Run unit tests
# The command launches the test suite.
command: yarn test --run
# `run` becomes a map of named deploy runtimes in v0.2.
run:
# Reactive runtime:
# - identified by `steps`
# - may optionally set `image`
# - all common deploy-server fields are supported
# The map key names this deploy target.
reactive-app:
# `steps` marks this as a reactive runtime and defines its lifecycle commands.
steps:
# This step builds the app before it starts.
- name: Build app
# The build command prepares production assets.
command: yarn build
# This step names the runtime startup command.
- name: Start app
# The start command launches the reactive process.
command: yarn start
# Optional custom base image for reactive execution.
image: ghcr.io/codesphere-cloud/example-reactive:latest
# Optional health endpoint used by the platform.
healthEndpoint: http://127.0.0.1:3000/healthz/app
# Optional workspace plan id.
plan: 20
# Optional replica count.
replicas: 2
# `isPublic` is ignored when `network` uses the advanced shape.
isPublic: true
# Advanced network config:
# - `ports` defines public/private TCP ports
# - `paths` defines routed HTTP paths
network:
# `ports` exposes raw TCP ports on the runtime.
ports:
# `port` is the container port that the platform should expose.
- port: 3000
# `isPublic` controls whether the port is reachable externally.
isPublic: true
- port: 9229
isPublic: false
# `paths` configures HTTP routing rules on top of the ports.
paths:
# `port` selects which runtime port receives this HTTP path.
- port: 3000
# `path` is the incoming route prefix to match.
path: /
# `stripPath` controls whether the prefix is removed before proxying.
stripPath: false
- port: 3000
path: /api
stripPath: true
# Environment values may be strings or numbers.
env:
# `NODE_ENV` is a representative string environment variable.
NODE_ENV: production
# `PORT` shows that numeric env values are accepted too.
PORT: 3000
# Optional user/group to run the process as.
runAsUser: 1000
# `runAsGroup` pairs with `runAsUser` for filesystem permissions.
runAsGroup: 1000
# Optional workspace mounts.
volumeMounts:
# `name` currently supports the workspace volume only.
- name: _workspace
# `mountPath` is where the workspace appears inside the runtime.
mountPath: /home/user/app
# `workspacePath` narrows the mounted subdirectory; empty means the root.
workspacePath: ""
# Container runtime:
# - identified by `image`
# - must not define `steps`
# - may optionally set `command`
# This second deploy target demonstrates the container-runtime shape.
container-app:
# `image` is required for container runtimes.
image: ghcr.io/codesphere-cloud/example-container:latest
# `command` overrides the image default entrypoint/command.
command:
# Command arrays are passed through as ordered argv segments.
- node
- server.js
# The remaining fields share the common deploy-server schema.
healthEndpoint: http://127.0.0.1:8080/healthz/app
plan: 20
replicas: 1
isPublic: true
# Simple network config routes one path to the main port.
network:
# `path` exposes the service under a single HTTP prefix.
path: /container
# `stripPath` keeps the `/container` prefix when forwarding requests.
stripPath: false
env:
NODE_ENV: production
PORT: 8080
runAsUser: 1000
runAsGroup: 1000
volumeMounts:
- name: _workspace
mountPath: /home/user/app
workspacePath: ""
# Managed service runtime in v0.2:
# - uses `provider.version`
# This key names the managed service instance.
postgres:
# `provider` identifies which service catalog entry to provision.
provider:
# `name` selects the provider type.
name: postgres
# `version` selects the provider schema version in v0.2/v0.3.
version: "14"
# `plan` selects a service plan and its numeric parameters.
plan:
# `id` identifies the chosen plan in the marketplace catalog.
id: 1
# Provider-specific integer parameters.
parameters:
# `storage` requests persistent disk capacity.
storage: 1024
# `cpu` requests compute units for the service.
cpu: 1
# `memory` requests RAM for the service.
memory: 512
# Arbitrary provider config payload.
config:
# `database` is a provider-defined config field.
database: app
# `extensions` shows that provider config can include lists.
extensions:
- pgcrypto
# Arbitrary provider secrets payload.
secrets:
# `password` is a provider-defined secret value.
password: secret
# Example fixture for the legacy pre-versioned parser shape.
# v0.1 has no top-level schemaVersion field yet.
# All three top-level entries are plain stages, not deploy-runtime maps.
# `prepare` runs setup work before tests or app startup.
prepare:
# Steps are executed sequentially.
steps:
# Step names are optional and only descriptive.
- name: Install dependencies
# Command is the only required field on a step.
command: yarn install
# `test` runs verification commands after `prepare`.
test:
# Test steps still use the same sequential stage shape as `prepare`.
steps:
# This label only helps readers identify the step in UIs or logs.
- name: Run unit tests
# The command contains the shell instruction to execute.
command: yarn test --run
# `run` executes the main workload for this legacy schema version.
run:
# In v0.1, `run` is still just a plain stage.
# Deploy runtimes such as reactive servers, container runtimes,
# and managed services are introduced in later versions.
# The run stage can also define a health endpoint.
healthEndpoint: http://127.0.0.1:3000/healthz/app
# Runtime steps are executed in order, just like any other stage.
steps:
# The step name documents the intent of the runtime command.
- name: Start dev server
# The command starts the long-running application process.
command: yarn start