Runtimes

Runtimes sind die Ausführungsumgebungen, in denen die Services deiner Anwendung innerhalb einer Codesphere Landscape laufen. Jeder Service in deiner Landscape nutzt einen dieser Runtime-Typen, die jeweils für unterschiedliche Workload-Muster und Deployment-Anforderungen optimiert sind.

Überblick über die Runtime-Typen

Codesphere unterstützt mehrere Runtime-Typen, um unterschiedliche Anwendungsarchitekturen und Deployment-Szenarien abzudecken:

Runtime-Typ	Am besten geeignet für	Hauptmerkmale
Codesphere Reactives	Web-Services, APIs, Microservices, zustandsbehaftete Anwendungen aus klassischen Serverumgebungen	Verwaltetes Ubuntu, standardmäßiges Dateisystem-Mount, inaktiv wenn ungenutzt (kann als „zustandsbehaftetes Serverless“ beschrieben werden), automatische Neustarts, gemeinsames Basis-Image
Managed Containers	Eigene Container-Images, spezifische Anforderungen an das Basis-Betriebssystem, Open-Source-Projekte, extern gebaute Abhängigkeiten	Gleiche Plattform-Orchestrierung wie Reactives, jedoch mit eigenem Image, Anbindung an alle Plattformfunktionen
Virtual Clusters	Komplexe Kubernetes-Workloads (z. B. per Helm bereitgestellt), erfahrene Nutzer	Voller kubectl-Zugriff, virtuell verwalteter Cluster, manche Plattformintegrationen müssen manuell konfiguriert werden
Virtual Machines	Legacy-Anwendungen, Anforderungen auf Betriebssystemebene, Windows-Workloads	KubeVirt-basierte VMs neben Reactives und Managed Containers starten, Routing- und Netzwerk-Plattformfunktionen können angebunden werden
Managed Services	Services, von denen deine Anwendungen abhängen	Vorkonfigurierte Services aus dem Marketplace, die bereitgestellt und mit deiner Landscape verbunden werden können

Die richtige Runtime wählen

Für viele moderne Webanwendungen und APIs bieten Codesphere Reactives die beste Balance aus Einfachheit, Leistung und Kosteneffizienz. Nutze Managed Containers, wenn du bestehende OCI-Images wiederverwenden möchtest, und Virtual Clusters, wenn du volle Kontrolle über Kubernetes benötigst.

Codesphere Reactives

Codesphere Reactives sind eine Runtime-Umgebung, mit der du deine Anwendungsumgebung über Standard-Bash-Befehle definieren kannst – genau wie auf einer lokalen Maschine oder VM –, während die Plattform die gesamte Infrastrukturverwaltung automatisch übernimmt. Du erhältst die Freiheit einer imperativen Linux-Konfiguration, ohne Container bauen, verwalten oder überhaupt über sie nachdenken zu müssen. Die Runtime kombiniert die Leistungsfähigkeit klassischer Serverumgebungen mit automatischer Skalierung und minimalem Infrastruktur-Overhead im inaktiven Zustand.

→ Den vollständigen Leitfaden zu Codesphere Reactives lesen

Was Reactives anders macht

Im Gegensatz zu traditionellen Serverless-Plattformen, die zustandslos sind und auf kurzlebige Funktionsausführungen beschränkt sind, oder herkömmlichen VMs, die kontinuierlich Ressourcen verbrauchen, vereinen Codesphere Reactives die Vorteile beider Ansätze:

• Zustandsbehaftete Ausführung: Voller Zugriff auf ein gemeinsames Netzwerk-Dateisystem für persistente Daten
• Inaktiv wenn ungenutzt: Automatische Freigabe von Ressourcen in Leerlaufphasen
• Automatische schnelle Neustarts: Optimierte Cold-Start-Zeiten
• Langlaufende Prozesse: Unterstützung für klassische Webserver, Hintergrundprozesse und komplexe Anwendungen
• Umgebungskontrolle & Sicherheit: Rootless-Container mit anpassbaren Abhängigkeiten über Nix oder sprachspezifische Paketmanager (z. B. npm, pip)

Architektur & Funktionsweise

Codesphere Reactives sind voll funktionsfähige Ubuntu-Open-Standard-Container, die mit unserer patentierten Deployment-Orchestrierung für verbesserte Startleistung orchestriert werden:

• Gemeinsames Netzwerk-Dateisystem: Jede Reactive hat Zugriff auf ein leistungsstarkes Netzwerk-Dateisystem, das persistenten Speicher über Neustarts und Replikate hinweg bereitstellt. Dateien in /home/user/app bleiben erhalten, während andere Speicherorte flüchtigen Speicher verwenden.
• Serverloses Ressourcenmanagement: Gebündelte Compute-Instanzen über mehrere Knoten ermöglichen sofortigen Start und automatische Ressourcenfreigabe in Leerlaufphasen. Ungenutzte Ressourcen stehen anderen Workloads sofort zur Verfügung, und eine Wakeup-Logik startet Services bei Bedarf neu.
• Kubernetes-basierte Orchestrierung: Basiert auf Kubernetes mit Health-Monitoring, Load Balancing, Auto-Scaling und kontrolliertem Herunterfahren – alles von der Plattform verwaltet, ohne dass Kubernetes-Kenntnisse erforderlich sind.

Entsprechende barrierefreie Textbeschreibung

Reactives vs. Managed Containers

Sowohl Codesphere Reactives als auch Managed Containers nutzen dieselbe zugrunde liegende Orchestrierungsplattform, unterscheiden sich jedoch darin, wie das Basis-Container-Image verwaltet wird:

Codesphere Reactives verwenden ein gemeinsames, von Codesphere gepflegtes Basis-Image, das:

• Gepoolt und vorgewärmt ist: Instanzen werden im Pool bereitgehalten, um einen nahezu sofortigen Start (im Millisekundenbereich) zu ermöglichen
• Standardisiert ist: Wird von Codesphere für Sicherheit und Kompatibilität gepflegt und aktualisiert
• Agent-injiziert ist: Der Codesphere-Agent wird zur Laufzeit dynamisch injiziert, für Orchestrierung, Monitoring und Plattformintegration
• Zur Laufzeit anpassbar ist: Du definierst Abhängigkeiten über Nix oder Paketmanager in der prepare-Phase

Managed Containers erlauben es, ein eigenes (Basis-)Image zu definieren, was bedeutet:

• Eigenes Basis-Betriebssystem: Verwendung beliebiger OCI-Images aus öffentlichen Registries
• Vorab gebündelte Abhängigkeiten: Alle Abhängigkeiten werden direkt in das Image integriert
• Gleiche Plattformfunktionen: Weiterhin Orchestrierung, Monitoring, Netzwerk und alle Codesphere-Funktionen
• Etwas langsamerer Start: Container-Images müssen abgerufen und initialisiert werden (typischerweise Sekunden statt Millisekunden)
• Plattformintegration: Der Codesphere-Agent wird für Plattformfunktionen integriert

Beide Runtime-Typen profitieren von:

• Zugriff auf das gemeinsame Netzwerk-Dateisystem
• Funktion „Inaktiv wenn ungenutzt“
• Automatisches Load Balancing und Skalierung
• Integriertes Monitoring und Observability

Lifecycle-Management

Verhalten bei „Inaktiv wenn ungenutzt“

Eine der leistungsstärksten Funktionen von Reactives ist die Fähigkeit, auf null zu skalieren:

1. Aktiver Zustand: Beim Verarbeiten von Anfragen oder Ausführen von Code verbrauchen Reactives ihre zugewiesenen Compute-Ressourcen
2. Inaktivitätserkennung: Nach einer Phase der Inaktivität (keine eingehenden Web-Anfragen, standardmäßig 1 Stunde) fährt der Orchestrator den Reactive-Service herunter
3. Ressourcenfreigabe: Compute-Ressourcen werden an den Pool zurückgegeben, der Zustand des Dateisystems bleibt jedoch erhalten
4. Sofortiges Aufwachen: Bei der nächsten eingehenden Anfrage startet die Reactive neu (typischerweise nur Millisekunden bis zur Ausführung der Run-Phase) und setzt genau dort fort, wo sie aufgehört hat

Dieses Verhalten ist ideal für:

• Entwicklungs- und Staging-Umgebungen
• Produktions-Services mit geringem Traffic
• Geplante Batch-Jobs
• Kostensensitive Workloads

Skalierungsstrategien

Reactives unterstützen sowohl horizontale als auch vertikale Skalierung:

Horizontale Skalierung (Replikate)

• Mehrere Instanzen (Replikate) desselben Services hinzufügen
• Automatisches Load Balancing über alle gesunden Replikate
• Konfiguration über das Feld replicas in ci.yml, über die UI oder per API
• Ideal zur Bewältigung erhöhter Anfragevolumen

Vertikale Skalierung (Ressourcen)

• Erhöhung von CPU-Kernen oder Speicherzuweisung
• Wirkt innerhalb von Sekunden, ohne Neustart
• Konfiguration über das Feld plan, das die Ressourcenstufe festlegt
• Ideal für rechen- oder speicherintensive Workloads

Beispielkonfiguration für die Skalierung:

run:
  api-server:
    plan: 42  # Ressourcenstufe (bestimmt CPU/Speicher)
    replicas: 3  # Anzahl der Instanzen
    steps:
      - name: Start Server
        command: node server.js

Konfiguration & Einrichtung

Vorbereitung der Umgebung

Der Abschnitt prepare definiert, wie deine Runtime-Umgebung eingerichtet wird:

prepare:
  steps:
    - name: Install System Dependencies
      command: |
        nix-env -iA nixpkgs.nodejs_20 nixpkgs.python311
        
    - name: Install Application Dependencies
      command: npm ci
      
    - name: Build Application
      command: npm run build

Um binäre Abhängigkeiten während der prepare-Phase zu installieren, unterstützt Codesphere den Nix Package Manager. Weitere Details findest du unter Installing Dependencies with Nix.

Grundlegende Reactive-Konfiguration

Jeder Reactive-Service wird im Abschnitt run deiner ci.yml definiert:

run:
  my-service:
    # Ressourcenzuweisung
    plan: 21  # Compute-Stufe – Details siehe Preisseite
    
    # Umgebungsvariablen
    env:
      NODE_ENV: production
      DATABASE_URL: ${{ vault.dbUrl }}  # Verweis auf Secrets im Vault
      
    # Netzwerk
    network:
      ports: [3000]  # Erreichbar für andere Services in der Landscape
          
    # Startbefehle
    steps:
      - name: Start Application
        command: npm start

Erweiterte Konfigurationsoptionen

Benutzerdefinierte Health Checks

run:
  my-service:
    steps:
      - name: Start Application
        command: npm start
    healthEndpoint: http://localhost:8080/health        
    network:
      ports: [8080]

Volume-Mounts

Standardmäßig mounten alle Services das gesamte Verzeichnis /home/user/app. Du kannst einen Service darauf beschränken, nur ein Unterverzeichnis zu mounten, indem du volumeMounts verwendest:

run:
  my-service:
    # Mountet nur /home/user/app/uploads
    volumeMounts:
      - name: _workspace
        mountPath: /home/user/app
        workspacePath: uploads
    steps:
      - name: Start Application
        command: npm start

Best Practices & Muster

Multi-Service-Architektur

Services innerhalb der Landscape erreichen sich gegenseitig über ihre deklarierten Ports, unter Verwendung interner Hostnamen. Externer Traffic gelangt über ein einziges Landscape-Gateway in die Landscape. Für Landscapes mit mehreren Services wird als Gateway der Codesphere Workspace Router empfohlen, der Anfragepfade an deine Services weiterleitet. Services ohne Pfadzuordnung, etwa Hintergrundprozesse, bleiben nur innerhalb der Landscape erreichbar. Details dazu findest du unter Landscape Networking.

run:
  frontend:
    plan: 21
    network:
      ports: [3000]
    steps:
      - command: npm run start:frontend

  backend:
    plan: 21
    network:
      ports: [8080]
    steps:
      - command: npm run start:backend

  worker:
    plan: 21
    network:
      ports: [3000]  # Nur intern, keine Pfadzuordnung im Router
    steps:
      - command: npm run start:worker

  cs-router:
    type: router
    plan: 101
    replicaCount: 1
    network:
      isLandscapeGateway: true
      paths:
        - path: /
          service: frontend
          port: 3000
        - path: /api
          service: backend
          port: 8080

Häufige Fallstricke

Problem	Ursache	Lösung
Datenverlust beim Neustart	Schreiben außerhalb von /home/user/app	Sicherstellen, dass alle persistenten Schreibvorgänge in das App-Verzeichnis erfolgen
Konflikte bei gleichzeitigen Schreibvorgängen	Mehrere Replikate schreiben dieselben Dateien	Separate Verzeichnisse pro Replikat oder externe Datenbanken verwenden
Langsame Cold Starts	Große Abhängigkeitsbäume	Prepare-Phase optimieren, nicht kritische Module nur bei Bedarf laden
Fehlgeschlagene Health Checks	Anwendung vor Timeout nicht bereit	Sicherstellen, dass der richtige Port verwendet wird, und prüfen, ob die Anwendung gültiges HTTP zurückgibt, indem die interne Port-URL per curl angefragt wird (kann aus dem Service-Flyout kopiert werden)
OOM-Fehler	Zu klein dimensionierter Plan	Speichernutzung überwachen und Plan entsprechend upgraden

Sicherheit

Rootless-Container

Reactives laufen als Nicht-Root-Nutzer, was eine zusätzliche Sicherheitsebene bietet. Das bedeutet:

• Kein direkter Zugriff auf privilegierte Ports (< 1024)
• Keine Installation von Systempaketen möglich, die Root-Rechte erfordern
• Eingeschränkte Dateisystemberechtigungen außerhalb von /home/user/app

Secret-Management

Verwende immer den Vault, um sensible Informationen zu speichern:

run:
  api:
    env:
      # Template-Syntax verwenden, um auf Secrets zu verweisen
      SECRET_KEY: ${{ vault.secretFoo }}
      DB_PASSWORD: ${{ vault.secretBar }}

Ausführliche Informationen zur Verwaltung von Secrets findest du unter Secret Management.

Tiefer in Reactives eintauchen

Dieser Überblick behandelt die Grundlagen von Codesphere Reactives. Umfassende Leitfäden zu Konfigurationsmustern, erweiterten Funktionen, Fehlerbehebung und praxisnahen Beispielen findest du in der vollständigen Dokumentation zu Codesphere Reactives.

Managed Containers

Mit Managed Containers kannst du eigene Docker-Images in Codesphere einbringen und gleichzeitig die Orchestrierungs-, Netzwerk- und Monitoring-Funktionen der Plattform nutzen. Daher gelten alle zuvor genannten Punkte und Best Practices für Reactives ebenso für die Managed Container Runtime.

→ Den vollständigen Leitfaden zu Managed Containers lesen

Benutzerdefinierte Deploy-Konfiguration

In Private-Cloud-Installationen kannst du auch das Standard-Basis-Image ändern, das von allen Reactives verwendet wird. Dies wird im Abschnitt deployConfig der Installationskonfiguration konfiguriert. Weitere Details findest du in der Referenz zur Private-Cloud-Installer-Konfiguration.

Wann Managed Containers verwendet werden sollten

Nutze Managed Containers, wenn:

• du bereits vorhandene Dockerfiles oder vorgefertigte Images hast
• du ein bestimmtes Basis-Image oder eine bestimmte Betriebssystemdistribution benötigst (Alpine, Ubuntu, Debian usw.)
• deine Abhängigkeiten komplex sind und am besten über ein Dockerfile verwaltet werden
• du Images aus Registries wie Docker Hub, ECR oder privaten Registries verwenden möchtest
• du Systempakete bündeln musst, die über Nix nicht verfügbar sind

Konfiguration

run:
  nginx-server:
    baseImage: nginx-unprivileged:1.29-alpine
    plan: 21
    steps:
      - command: nginx -g "daemon off;"
    healthEndpoint: http://localhost/
    network:
      ports: [3000, 8080]
    runAsUser: 1000
    runAsGroup: 1000

Startleistung

Managed Containers haben aufgrund des Image-Abrufs und der Initialisierung typischerweise Startzeiten im Sekundenbereich (im Vergleich zu Millisekunden bei Reactives). Die tatsächliche Geschwindigkeit hängt von der Größe des Images und der Netzwerkleistung zwischen der Registry und dem Cluster ab.

Tiefer in Managed Containers eintauchen

Umfassende Leitfäden zum Erstellen eigener Images, zur Registry-Konfiguration, zu erweiterten Mustern und zur Fehlerbehebung findest du in der vollständigen Dokumentation zu Managed Containers.

Managed Kubernetes (Virtual Clusters)

Virtual Clusters nutzen einen virtuellen, verwalteten Kubernetes-Cluster. Nutzer erhalten vollen kubectl-Zugriff für fortgeschrittene Orchestrierungsszenarien.

→ Den vollständigen Leitfaden zu Virtual Clusters lesen

Wann Virtual Clusters verwendet werden sollten

Nutze Virtual Clusters, wenn:

• du vollen Zugriff auf die Kubernetes-API benötigst
• du komplexe Helm-Charts bereitstellst
• du benutzerdefinierte Kubernetes-Ressourcen (CRDs) benötigst
• du bereits bestehende Kubernetes-Manifeste hast

Konfiguration

Du kannst den virtuellen Kubernetes-Cluster im Bereich Managed Services der UI oder über die API bereitstellen. Sobald der Cluster bereitgestellt ist, kannst du dich über die in der API verfügbare Kubeconfig damit verbinden und deine Workloads mithilfe von kubectl-Befehlen in den prepare- oder run-Schritten oder über das Terminal bereitstellen.

Die tiefe Lifecycle-Integration in die Codesphere-ci.yml befindet sich derzeit in Arbeit. Nutzer können Workloads jedoch bereits bereitstellen, indem sie kubectl-Befehle zu den prepare- oder run-Schritten hinzufügen und den passenden Context verwenden.

warnung

Diese Runtime richtet sich an Experten und sollte nicht ohne Vorkenntnisse zu Kubernetes verwendet werden.