Managed Containers
Dies ist eine ausführliche Anleitung für Managed Containers. Für einen Überblick über alle Runtime-Typen und wie man zwischen ihnen wählt, siehe Runtimes Overview. 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-Funktionen der Plattform zu nutzen. Dieser Runtime-Typ nutzt die gleiche zugrunde liegende Infrastruktur wie Codesphere Reactives, erlaubt aber die Definition eigener Images und das Vorbacken von Abhängigkeiten über OCI-Images.
Überblick
Managed Containers schlagen eine Brücke zwischen der Einfachheit von Codesphere Reactives und der Flexibilität eigener Container-Images:
| Funktion | Codesphere Reactives | Managed Containers |
|---|---|---|
| Basis-Image | Geteiltes 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 | Im OCI-Image vorgebacken |
| OS-Distribution | Ubuntu oder von 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 Netzwerkdateisystem | Anpassbares, gemeinsames Netzwerkdateisystem |
| Off-when-unused | Ja | Ja |
| Skalierung & Lastverteilung | Ja | Ja |
| Plattformintegration | Eingebaut | Zur Laufzeit |
Architektur
Managed Containers nutzen dieselbe Orchestrierungsplattform wie Reactives, der wesentliche Unterschied liegt in der Quelle des Container-Images:
Entsprechende barrierefreie Textbeschreibung
Wesentliche Komponenten
1. Eigenes Container-Image
- Definition eines eigenen Basis-Images über ein Dockerfile
- Abruf von Docker Hub, ECR, GCR oder privaten Registries
- Vorbacken aller Systemabhängigkeiten und Pakete
- Vollständige Kontrolle über OS-Distribution und Version
2. Plattformorchestrierung
- 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 Netzwerkdateisystem
- Identischer Dateisystemzugriff wie bei Reactives
- Mounten beliebiger Dateien oder Verzeichnisse an beliebigen Zielpfaden im Container
- Standard-Mount unter
/home/user/appfür persistenten Speicher - Gleiche Best Practices gelten (Schreiben in das App-Verzeichnis, gleichzeitige Schreibzugriffe vermeiden)
4. Image Pull & Start
- Container-Images werden beim ersten Start aus der Registry geladen
- Nachfolgende Starts können gecachte Images verwenden (abhängig vom Cluster-Zustand)
- Startzeit typischerweise im Sekundenbereich statt Millisekunden wie bei Reactives
- Abwägung zugunsten vollständiger Image-Anpassung
Kompatibilitätshinweise
Codesphere startet in jedem Managed Container einen Agent als PID 1, um Plattformfunktionen bereitzustellen. Der durch das 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. Sollte dies bei einem Image der Fall sein, ist es nicht mit Managed Containers kompatibel, es sei denn, seine dokumentierte Konfiguration unterstützt das Ausführen der Anwendung als Kindprozess.
Wann Managed Containers verwenden
Managed Containers eignen sich ideal für:
- Bestehende OCI-Images/Dockerfiles – Wiederverwendung bestehender Container-Definitionen
- Spezifische Basis-OS-Anforderungen – Alpine, Debian, benutzerdefinierte Distributionen
- Komplexe Abhängigkeiten – Pakete auf Systemebene, 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
- schnellere Startzeiten entscheidend sind
- 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 Netzwerkdateisystem unter /home/user/app |
| Off-when-unused | Automatische Ressourcenfreigabe bei Inaktivität |
| Skalierung | Horizontal (Replicas) und vertikal (Plans) |
| Lastverteilung | Automatisch über Replicas hinweg |
| Health-Monitoring | Konfigurierbare Health-Checks und Auto-Restart |
| Privates Networking | Sichere interne Service-Kommunikation |
| Secret-Management | 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 abzurufen. Codesphere unterstützt zwei Wege, diese bereitzustellen: Container Registries auf Resource-Group-Ebene (empfohlen) und Workspace-Secrets (veraltet, aber weiterhin unterstützt).
Container Registries auf Resource-Group-Ebene
Resource Group Admins können Registry-Zugangsdaten einmalig auf Ebene der Resource Group konfigurieren, anstatt Secrets pro Workspace zu verwalten. Codesphere gleicht das baseImage eines Managed Containers mit den konfigurierten Registries ab und verwendet die Zugangsdaten beim Deployment automatisch.
- Öffne die Resource Group und gehe dann zu Settings > Container Registries.
- Klicke auf Configure Container Registry.
- Vergib einen Namen für die Registry und lege Container Registry Address, Username und Password/Access Token fest.
Die Registry-Adresse kann so breit oder so eng gefasst werden, wie benötigt – der jeweils spezifischste passende Eintrag für ein gegebenes baseImage wird verwendet.
Container Registries auf Resource-Group-Ebene erfordern, dass sowohl das Feature-Flag team-container-registries als auch cimg-private-registry für die jeweilige Installation aktiviert sind. Ist eines der beiden deaktiviert, ist die Seite Container Registries nicht verfügbar. Siehe Feature Flags für die Konfiguration der Flags.
Workspace-Secrets (veraltet)
Diese Methode ist veraltet und wird durch Container Registries auf Resource-Group-Ebene oben ersetzt. Sie wird weiterhin für bestehende Konfigurationen unterstützt, neue Konfigurationen sollten jedoch den Resource-Group-Ansatz verwenden. Sind sowohl Registries auf Resource-Group- als auch auf Workspace-Ebene konfiguriert, hat die Registry der Resource Group Vorrang.
Die Zugangsdaten werden als zwei Workspace-Secrets bereitgestellt. Codesphere liest sie beim Deployment aus und verwendet sie, um das Image abzurufen.
| Schlüssel | Wert |
|---|---|
REGISTRY_USERNAME | Registry-Benutzername |
REGISTRY_PASSWORD | Registry-Passwort oder Access Token |
Die Schlüsselnamen sind exakt und groß-/kleinschreibungssensitiv. Beide müssen vorhanden sein.
Speichere sie im Workspace-Vault genau wie jedes andere Secret. Siehe Secret Management für Hinweise zum dauerhaften Speichern von Workspace-Secrets.
Beim nächsten Redeploy wird das Image bei Bedarf mit diesen Zugangsdaten abgerufen.
Zugangsdaten für private Registries werden nur ausgelesen, wenn sowohl das Feature-Flag secret-management als auch cimg-private-registry für die jeweilige Installation aktiviert sind. Ist eines der beiden deaktiviert, wird das Image ohne Zugangsdaten abgerufen und ein privates Image kann nicht heruntergeladen werden. Siehe Feature Flags für die Konfiguration der Flags.
Konfiguration & Lebenszyklus
Managed Containers werden über die Datei ci.yml im Repository konfiguriert. Umfassende Anleitungen zur Konfiguration und Verwaltung von Managed Containers:
- Configuring a Landscape – Vollständige Anleitung zur Landscape-Konfiguration
- Configuring CI Pipeline – Detaillierte Pipeline-Einrichtung einschließlich Prepare- und Run-Stages
- Landscape Lifecycle – Verständnis von Deployment, Skalierung und Lifecycle-Management
- Environment Variables – Verwaltung der Umgebungskonfiguration
- Secret Management – Sicherer Umgang mit sensiblen Daten
- CI Profiles – Verwaltung unterschiedlicher Konfigurationen für Dev, Staging und Produktion