Die Migrationsleitfäden für Cloud Foundry zu Cloud Run bieten Hintergrundinformationen zu den Unterschieden zwischen Cloud Foundry-Diensten und Cloud Run-Diensten und zeigen, was Sie tun müssen, um Cloud Foundry-Anwendungen zur Ausführung in einem Container in Cloud Run zu migrieren. Die Datenmigration wird nicht auf diesen Migrationsseiten behandelt.
Cloud Foundry-Anwendungen, die für die Migration infrage kommen
Cloud Run wurde für die Ausführung zustandsloser HTTP- oder HTTP/2-Anwendungen entwickelt. Ihre Cloud Foundry-Anwendung kann nur migriert werden, wenn sie die folgenden Kriterien erfüllt:
- Verwendet HTTP oder HTTP/2 (einschließlich gRPC).
- Wartet auf Traffic anhand der Umgebungsvariable
PORT. - Erfordert kein Routing auf verschiedenen Pfaden zu verschiedenen Anwendungen.
- Erfordert keine Legacy-"Route-Dienste" von Cloud Foundry für die Proxy-Weiterleitung.
- Erfordert keine Instanz-ID oder bestimmte Startreihenfolge.
- Erfordert nicht, dass einzelne Instanzen adressierbar sind.
- Kann ohne Nebenwirkungen auf die Umgebung gestartet werden, z. B. Starten einer Datenbankmigration.
Unterschiede zwischen Cloud Foundry und Cloud Run
Cloud Foundry und Cloud Run haben zwar eine ähnliche Quellbereitstellung, doch gibt es wichtige Unterschiede bei der Vorgehensweise zur Containerisierung von Arbeitslasten, der Anwendungskonfiguration und den Dienstdefinitionen. Die Unterschiede zwischen Cloud Foundry und Cloud Run sind in der folgenden Tabelle aufgeführt:
| Anwendungskomponente | Cloud Foundry | Cloud Run Container-Image-Bereitstellung |
Cloud Run Dockerfile-Quellbereitstellung |
Cloud Run Buildpacks-Quellbereitstellung |
|---|---|---|---|---|
| Containerisierung | CF-Buildpacks V2 | – | Cloud Build | Cloud Build |
| Basis-Image |
cflinuxfs3 (Ubuntu 18.04) cflinuxfs4 (Ubuntu 22.04) |
Eigenes Container-Image verwenden | Dockerfile angegeben | Ubuntu 18.04 oder Ubuntu 22.04 |
| Dienstdefinition | manifest.yaml |
service.yaml |
||
| Ignorieren-Liste | .cfignore |
.gcloudignore |
||
| Dienstmetadaten | VCAP_*-Umgebungsvariablen |
Workload Identity, Cloud-Secrets | ||
| Unterstützte Containerformate | Droplet | Docker Image Manifest V2, Schema 1, Schema 2 und OCI-Formate | ||
Vorgehensweise
So migrieren Sie eine Cloud Foundry-Anwendung:
- Strategie zum Erstellen von OCI-kompatiblen Containern auswählen
- Zu OCI-kompatiblen Containern migrieren
- Manifest konvertieren
- Sicherungsdienste anhängen
- Dienst in Cloud Run bereitstellen
Beispielmigration
Das Spring Music-Beispiel verwendet Kernkomponenten von Cloud Foundry, um Spring Music als OCI-kompatibles Image neu zu erstellen und in Cloud Run bereitzustellen. Dieses Beispiel folgt der Lift-and-Shift-OCI-Compliance-Strategie.
Weitere Informationen
Containerisierungsstrategie wählen