OCI-konforme Strategie auswählen

Diese Seite bietet einen Überblick über den Cloud Foundry-Build-Prozess, von dem Sie migrieren müssen, und enthält eine Beschreibung der verschiedenen Möglichkeiten, von diesem zu einem Prozess zu migrieren, mit dem OCI-kompatible Container erstellt werden.

Überblick über den Cloud Foundry-Build-Prozess

Wenn eine Anwendung in Cloud Foundry übertragen wird, durchläuft sie eine Build-Phase, in der der Quellcode von den Cloud Foundry-V2-Buildpacks kompiliert wird.

Die Ausgabe eines Cloud Foundry-Build-Prozesses erstellt ein ausführbares Archiv, das als Droplet bezeichnet wird. Droplets sind nicht direkt mit der OCI-Spezifikation (Open Container Initiative) zum Ausführen von Containern in Cloud Run kompatibel.

Wenn Sie Anwendungen von Cloud Foundry zu Cloud Run migrieren, müssen Sie den Anwendungs-Build-Prozess ändern, um OCI-Images nach Branchenstandard zu generieren (manchmal auch als Docker-Images bezeichnet).

Diagramm zur Erstellung von Cloud Foundry-Droplets

Strategien zum Erreichen von OCI-kompatiblen Images

Sie können zwischen drei Migrationsstrategien wählen, um OCI-kompatible Container zu erstellen:

Cloud Foundry-Anwendung ändern (Lift-and-Shift)

Die Kernkomponenten der Cloud Foundry-Umgebung (V2-Buildpacks, Stemcells usw.) sind Open Source. Das bedeutet, dass Sie den Containerisierungsprozess der Anwendung neu erstellen können. Folgen Sie dazu unserer Anleitung zum "Dockerisieren" der Kern-Build-Komponenten, um ein neues OCI-kompatibles Image zu erstellen.

Vorteile:

  • Erfordert das geringste Maß an Anwendungsrefaktorierung und -anpassung.
  • Der Vorgang ist für alle Anwendungsinstanzen wiederholbar.

Nachteile:

  • Die Pipeline zum Erstellen von Anwendungscontainern ist selbstverwaltet.
  • Ältere Cloud Foundry-Komponenten haben einen geringeren Wartungs- und Supportumfang.
  • Es fallen laufende Kosten für die Sicherheitswartung an, darunter:
    • Build-Komponenten regelmäßig neu erstellen, um Sicherheitspatches zu erhalten.
    • Die "dockerisierten" Anwendungen regelmäßig neu erstellen, um die Sicherheitsupdates der neu erstellten Build-Komponenten zu übernehmen.

Cloud Native Buildpacks verwenden

Die Spezifikation Cloud Native Buildpacks (CNB) wurde erstellt, um die Buildpacks-Umgebung zu modernisieren und zu vereinheitlichen. Builder, die mit der CNB-Spezifikation kompatibel sind, folgen offenen Standards und erstellen OCI-kompatible Images. Drei gängige CNB-Anbieter sind:

Vorteile:

  • Buildpack-Administratoren und Plattformanbieter sind für die Wartung des Buildpacks verantwortlich.
  • Mit Buildpacks unterstützen das Rebasing von Containern auf neuen Images, um schnelle Sicherheitsupdates zu ermöglichen, ohne die Anwendungscontainer neu erstellen zu müssen.
  • Buildpacks generieren portable OCI-Images.
  • Die Entwicklung des CNB-Projekts erfolgt gemäß der Cloud Native Computing Foundation (CNCF) mit einer aktiven Community von Administratoren und Mitwirkenden.

Nachteile:

  • Funktions- und Konfigurationsunterschiede zwischen V2- und V3-Buildpacks.
  • Frameworks und Integrationen, die in Ihrem Namen in den Java-V2-Buildpacks installiert werden, sind möglicherweise im Java-CNB-Buildpack nicht verfügbar.

Selbstverwaltete Dockerfiles verwenden

Sie können völlig neue Dockerfiles erstellen, um Ihre Anwendung zu containerisieren. Weitere Informationen zu Container-Images, die von Cloud Run akzeptiert werden, finden Sie unter Container erstellen.

Vorteile:

  • Bietet die größte Flexibilität beim Entwerfen von Anwendungen.
  • Sie können die Tools und Build-Strategien Ihres Unternehmens nutzen.

Nachteile:

  • Dockerisierung und benutzerdefinierte Konfiguration müssen für jede Anwendung ausgeführt werden, was Debugging und Umschreibungen potenziell zeitaufwendig macht.
  • Es ist schwierig, Implementierungen für mehrere Teams zu standardisieren.
  • Für das Patchen von Images ist eine vollständige Neuerstellung und Neubereitstellung erforderlich.

Empfehlungen

Teams, die ressourcenbeschränkt sind und so viele Anwendungen wie möglich verschieben möchten, sollten zuerst die Strategie Lift-and-Shift verwenden, um Cloud Foundry zu ändern. Sobald die Anwendungen in Bezug auf OCI-konforme Images modernisiert wurden, empfehlen wir Ihnen die Verwendung von Cloud Native Buildpacks oder selbstverwalteten Dockerfiles.

Teams, die sofort migrieren möchten, sollten mit Cloud Native Buildpacks beginnen und dann zu selbstverwalteten Dockerfiles wechseln, wenn sie ein hohes Maß an Kontrolle über ihre Umgebung benötigen.

Weitere Informationen