Zum Hauptinhalt springen
Version: Weekly Build

Managed Containers

Teil von Runtimes

Dies ist ein detaillierter Leitfaden für Managed Containers. Für einen Überblick über alle Runtime-Typen und wie zwischen ihnen gewählt wird, 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-Funktionen der Plattform zu nutzen. Dieser Runtime-Typ verwendet dieselbe zugrunde liegende Infrastruktur wie Codesphere Reactives, erlaubt jedoch die Definition eigener Images und das Vorbacken 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:

FunktionCodesphere ReactivesManaged Containers
Basis-ImageGemeinsames Codesphere Ubuntu (anpassbar für Private Cloud)Eigenes OCI-Image
StartzeitMillisekundenSekunden (abhängig von der Image-Größe)
AbhängigkeitenLokal (npm-Pakete, Python-Pakete usw.) oder NixVorgebacken im OCI-Image
OS-DistributionUbuntu oder vom Organisationsadministrator festgelegtBeliebig (Alpine, Debian usw.)
Image RegistryNicht zutreffendDocker Hub, ECR, private Registries
OrchestrierungAlle PlattformfunktionenAlle Plattformfunktionen
DateisystemzugriffAnpassbares gemeinsames Netzwerk-DateisystemAnpassbares gemeinsames Netzwerk-Dateisystem
Off-when-unusedJaJa
Skalierung & LastverteilungJaJa
PlattformintegrationIntegriertZur Laufzeit

Architektur​

Managed Containers nutzen dieselbe Orchestrierungsplattform wie Reactives, mit dem entscheidenden Unterschied bei der Quelle des Container-Images:

Managed Container Architektur

Entsprechende barrierefreie Textbeschreibung

Wichtige 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 vor
  • Vollständige Kontrolle über OS-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 für Plattformfunktionen integriert

3. Gemeinsames Netzwerk-Dateisystem​

  • Identischer Dateisystemzugriff wie bei Reactives
  • Beliebige Datei oder Verzeichnis an jedes Ziel im Container einbinden
  • Standardmäßiges Mounten unter /home/user/app für persistenten Speicher
  • Es gelten dieselben Best Practices (in das App-Verzeichnis schreiben, gleichzeitige Schreibvorgänge vermeiden)

4. Image Pull & Start​

  • Container-Images werden bei erstem Start aus der Registry gezogen
  • Nachfolgende Starts können zwischengespeicherte Images verwenden (abhängig vom Clusterzustand)
  • Startzeit typischerweise im Sekundenbereich im Vergleich zu Millisekunden bei Reactives
  • Trade-off für vollständige Image-Anpassung

Wann Managed Containers verwendet werden sollten​

Managed Containers sind ideal geeignet für:

  • Bestehende OCI-Images/Dockerfiles - Wiederverwendung bestehender Container-Definitionen
  • Spezifische Basis-OS-Anforderungen - Alpine, Debian, individuelle 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 Projekt von Grund auf begonnen wird

Gemeinsamkeiten mit Codesphere Reactives​

Beide Runtime-Typen teilen sich dieselben zugrunde liegenden Plattformfunktionen:

FunktionBeide Runtimes
DateisystemzugriffGemeinsames Netzwerk-Dateisystem unter /home/user/app
Off-when-unusedAutomatische Freigabe von Ressourcen bei Inaktivität
SkalierungHorizontal (Replicas) und vertikal (Pläne)
LastverteilungAutomatisch über den Landscape Router
Health-MonitoringKonfigurierbare Health-Checks und automatischer Neustart
Privates NetworkingSichere interne Service-Kommunikation
Secret ManagementVault-Integration für sensible Daten
MonitoringLogs, Metriken und Request-Tracing
PlattformintegrationCodesphere-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. Diese werden als zwei Workspace-Secrets bereitgestellt. Codesphere liest sie zum Zeitpunkt des Deployments und verwendet sie, um das Image zu ziehen.

SchlüsselWert
REGISTRY_USERNAMERegistry-Benutzername
REGISTRY_PASSWORDRegistry-Passwort oder Access Token

Die Schlüsselnamen müssen exakt und in korrekter Schreibweise (Groß-/Kleinschreibung) angegeben werden. Beide müssen vorhanden sein.

Speichere sie im Workspace-Vault genauso wie jedes andere Secret. Siehe Secret Management für Informationen zum dauerhaften Speichern von Workspace-Secrets.

Beim nächsten erneuten Deployment wird das Image mit diesen Zugangsdaten gezogen, sofern sie benötigt werden.

Verfügbarkeit der Funktion

Zugangsdaten für private Registries werden nur gelesen, wenn sowohl das Feature-Flag secret-management als auch cimg-private-registry für die Installation aktiviert sind. Ist eines der beiden deaktiviert, wird das Image ohne Zugangsdaten gezogen, und der Download eines privaten Images schlägt fehl. Siehe Feature Flags für die Konfiguration von Flags.

Konfiguration & Lifecycle​

Managed Containers werden über die Datei ci.yml im Repository konfiguriert. Umfassende Leitfäden zur Konfiguration und Verwaltung von Managed Containers finden sich hier: