Managed Containers
Teil von Runtimes
Dies ist ein detaillierter Leitfaden für Managed Containers. Für einen Überblick über alle Runtime-Typen und wie man zwischen ihnen wählt, siehe Runtimes Übersicht. Um die Unterschiede zwischen Reactives und Managed Containers zu verstehen, siehe auch Codesphere Reactives.
Managed Containers ermöglichen es, eigene OCI-Images in Codesphere einzubringen und dabei die Orchestrierungs-, Netzwerk- und Monitoring-Fähigkeiten der Plattform zu nutzen. Dieser Runtime-Typ verwendet dieselbe zugrunde liegende Infrastruktur wie Codesphere Reactives, erlaubt jedoch die Definition eigener Images und das Vorabbacken von Abhängigkeiten über OCI-Images.
Überblick
Managed Containers schließen die Lücke zwischen der Einfachheit von Codesphere Reactives und der Flexibilität eigener Container-Images:
| Funktion | Codesphere Reactives | Managed Containers |
|---|---|---|
| Basis-Image | Gemeinsames Codesphere-Ubuntu (anpassbar für Private Cloud) | Eigenes OCI-Image |
| Startzeit | Millisekunden | Sekunden (abhängig von Image-Größe) |
| Abhängigkeiten | Lokal (npm-Pakete, Python-Pakete usw.) oder Nix | Vorab in OCI-Image gebacken |
| Betriebssystem-Distribution | Ubuntu oder vom Organisationsadmin festgelegt | Beliebig (Alpine, Debian usw.) |
| Image-Registry | Nicht zutreffend | Docker Hub, ECR, private Registries |
| Orchestrierung | Vollständige Plattformfunktionen | Vollständige Plattformfunktionen |
| Dateisystemzugriff | Anpassbares gemeinsames Netzwerk-Dateisystem | Anpassbares gemeinsames Netzwerk-Dateisystem |
| Off-when-unused | Ja | Ja |
| Skalierung & Lastverteilung | Ja | Ja |
| Plattformintegration | Integriert | Zur Laufzeit |
Architektur
Managed Containers nutzen dieselbe Orchestrierungsplattform wie Reactives, mit dem entscheidenden Unterschied bei der Quelle des Container-Images:
Entsprechende barrierefreie Textbeschreibung
Wesentliche Komponenten
1. Eigenes Container-Image
- Definiere ein eigenes Basis-Image über ein Dockerfile
- Ziehe Images von Docker Hub, ECR, GCR oder privaten Registries
- Backe alle Systemabhängigkeiten und Pakete vorab
- Vollständige Kontrolle über Betriebssystem-Distribution und -Version
2. Plattform-Orchestrierung
- Dieselbe Kubernetes-basierte Orchestrierung wie bei Reactives
- Health-Monitoring, Lastverteilung und Auto-Scaling
- Off-when-unused-Funktionen für Ressourceneffizienz
- Codesphere-Agent zur Laufzeit integriert für Plattformfunktionen
3. Gemeinsames Netzwerk-Dateisystem
- Identischer Dateisystemzugriff wie bei Reactives
- Beliebige Datei oder Verzeichnis kann an beliebiges Ziel im Container gemountet werden
- Standard-Mount unter
/home/user/appfür persistente Speicherung - Dieselben Best Practices gelten (Schreiben in das App-Verzeichnis, gleichzeitige Schreibvorgänge vermeiden)
4. Image-Pull & Start
- Container-Images werden beim ersten Start aus der Registry gezogen
- Nachfolgende Starts können zwischengespeicherte Images verwenden (abhängig vom Cluster-Zustand)
- Startzeit typischerweise im Sekundenbereich statt Millisekunden wie bei Reactives
- Kompromiss für vollständige Image-Anpassung
Kompatibilitätsüberlegungen
PID-1-Verhalten
Codesphere startet in jedem Managed Container einen Agenten als PID 1, um Plattformfunktionen bereitzustellen. Der vom Image konfigurierte Befehl läuft daher als Kindprozess und nicht als PID 1.
Die meisten Images sind nicht darauf angewiesen, dass ihre Anwendung PID 1 ist. Falls ein Image dies doch voraussetzt, ist es nicht mit Managed Containers kompatibel, sofern die dokumentierte Konfiguration nicht die Ausführung der Anwendung als Kindprozess unterstützt.
Wann Managed Containers verwendet werden sollten
Managed Containers sind ideal für:
- Vorhandene OCI-Images/Dockerfiles – Wiederverwendung bestehender Container-Definitionen
- Spezifische Anforderungen an das Basis-Betriebssystem – Alpine, Debian, benutzerdefinierte Distributionen
- Komplexe Abhängigkeiten – Systemebene-Pakete, die am besten über ein Dockerfile verwaltet werden
- Open-Source-Projekte – Bereits containerisierte Anwendungen
- Registry-basierte Workflows – CI/CD, das Images in Registries pusht
Ziehe stattdessen Codesphere Reactives in Betracht, wenn:
- kein spezifisches Basis-Image benötigt wird
- eine schnellere Startzeit entscheidend ist
- die Installation von Abhängigkeiten zur Laufzeit über Nix bevorzugt wird
- ein neues Greenfield-Projekt gestartet wird
Gemeinsamkeiten mit Codesphere Reactives
Beide Runtime-Typen teilen sich dieselben zugrunde liegenden Plattformfunktionen:
| Funktion | Beide Runtimes |
|---|---|
| Dateisystemzugriff | Gemeinsames Netzwerk-Dateisystem unter /home/user/app |
| Off-when-unused | Automatische Ressourcenfreigabe während Inaktivitätsphasen |
| Skalierung | Horizontal (Replicas) und vertikal (Plans) |
| Lastverteilung | Automatisch über den Landscape Router |
| Health-Monitoring | Konfigurierbare Health-Checks und automatischer Neustart |
| Private Vernetzung | Sichere interne Service-Kommunikation |
| Secret-Verwaltung | Vault-Integration für sensible Daten |
| Monitoring | Logs, Metriken und Request-Tracing |
| Plattformintegration | Codesphere-Agent für Plattformfunktionen |
Verwendung einer privaten Registry
Ein Managed Container startet von einem benutzerdefinierten Basis-Image (baseImage). Liegt dieses Image in einer privaten Registry, benötigt die Landscape Zugangsdaten, um es zu ziehen. Codesphere unterstützt zwei Wege, diese bereitzustellen: teambasierte Container-Registries (empfohlen) und Workspace-Secrets (veraltet, aber weiterhin unterstützt).
Teambasierte Container-Registries
Team-Admins können Registry-Zugangsdaten einmalig auf Team-Ebene konfigurieren, anstatt Secrets für jeden Workspace einzeln zu verwalten. Codesphere gleicht das baseImage eines Managed Containers mit den konfigurierten Registries ab und verwendet die Zugangsdaten beim Deployment automatisch.
- Öffne dein Team und wechsle zu Settings > Container Registries.
- Klicke auf Configure Container Registry.
- Gib der Registry einen Namen und lege die Container Registry Address, den Username und das Password/Access Token fest.
Die Registry-Adresse kann so breit oder so eng gefasst werden, wie benötigt; für ein gegebenes baseImage wird der spezifischste passende Eintrag verwendet.
Funktionsverfügbarkeit
Teambasierte Container-Registries erfordern, dass für die Installation sowohl das Feature-Flag team-container-registries als auch cimg-private-registry aktiviert sind. Ist eines der beiden deaktiviert, ist die Seite Container Registries nicht verfügbar. Siehe Feature Flags für die Konfiguration von Flags.
Workspace-Secrets (veraltet)
Veraltet
Diese Methode ist veraltet und wird durch die oben beschriebenen teambasierten Container-Registries ersetzt. Sie bleibt für bestehende Setups unterstützt, neue Konfigurationen sollten jedoch den teambasierten Ansatz verwenden. Sind sowohl teambasierte als auch workspacebasierte Registries konfiguriert, hat die teambasierte Registry Vorrang.
Die Zugangsdaten werden als zwei Workspace-Secrets bereitgestellt. Codesphere liest sie beim Deployment und verwendet sie, um das Image zu ziehen.
| Schlüssel | Wert |
|---|---|
REGISTRY_USERNAME | Registry-Benutzername |
REGISTRY_PASSWORD | Registry-Passwort oder Access Token |
Die Schlüsselnamen sind exakt und case-sensitiv. Beide müssen vorhanden sein.
Speichere sie im Workspace-Vault genauso wie jedes andere Secret. Siehe Secret Management für das Persistieren von Workspace-Secrets.
Beim nächsten Redeploy wird das Image bei Bedarf mit diesen Zugangsdaten gezogen.
Funktionsverfügbarkeit
Zugangsdaten für private Registries werden nur gelesen, wenn für die Installation sowohl das Feature-Flag secret-management als auch cimg-private-registry aktiviert sind. Ist eines der beiden deaktiviert, wird das Image ohne Zugangsdaten gezogen, und ein privates Image kann nicht heruntergeladen werden. Siehe Feature Flags für die Konfiguration von Flags.
Konfiguration & Lifecycle
Managed Containers werden über die Datei ci.yml im Repository konfiguriert. Umfassende Anleitungen zur Konfiguration und Verwaltung von Managed Containers finden sich hier:
- Konfigurieren einer Landscape – Vollständiger Leitfaden zur Landscape-Konfiguration
- Konfigurieren der CI-Pipeline – Detaillierte Pipeline-Einrichtung inklusive Prepare- und Run-Stages
- Landscape Lifecycle – Verständnis von Deployment, Skalierung und Lifecycle-Management
- Umgebungsvariablen – Verwaltung der Umgebungskonfiguration
- Secret Management – Sicherer Umgang mit sensiblen Daten
- CI-Profile – Verwaltung unterschiedlicher Konfigurationen für Dev, Staging und Produktion