Linux-Systemcontainer

Mit der Migrate to Containers-Befehlszeile können Sie Linux-basierte Anwendungen in Containerumgebungen migrieren. Dabei wird ein vordefinierter Linux-Systemcontainer verwendet, der als Bootloader für die von der modernisierten Anwendung benötigten Dienste dient. Mit Migrate to Containers für Linux-Anwendungen können Sie eine Vielzahl zustandsloser Anwendungen modernisieren, damit diese auf Google Kubernetes Engine (GKE), Cloud Run und GKE-Clustern ausgeführt werden können.

Weitere Informationen finden Sie unter Architektur der Migrate to Containers CLI.

In diesem Dokument finden Sie Details zu Linux-Systemcontainern von Migrate to Containers, die als Teil der Lösung zum Ausführen von Anwendungen verwendet werden, die mithilfe von Migrate to Containers migriert wurden.

Migration mit Linux-Systemcontainer

Migrate to Containers erkennt die Quellanwendungsdateien und -prozesse. Anschließend werden Artefakte generiert, darunter ein Dockerfile, ein Kubernetes-Manifest und eine Skaffold-Konfiguration.

Die Hauptfunktion eines Linux-Systemcontainers besteht darin, die Dienste zu initiieren, die ursprünglich auf der Quell-VM-Instanz ausgeführt wurden, einschließlich relevanter Betriebssystem- und Anwendungsdienste.

Mit dem Dockerfile wird das Image für die migrierte VM erstellt. Ein Dockerfile für einen Linux-Systemcontainer sieht in der Regel so aus:

# Please refer to the documentation:
# https://cloud.google.com/migrate/anthos/docs/dockerfile-reference

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime

FROM scratch

# Tar containing data captured from the source VM
ADD vmFiles.tar.gz /

COPY --from=service-manager-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml

ADD logs.yaml /code/config/logs/logsArtifact.yaml

ADD services-config.yaml /.m4a/

ADD tempfiles.yaml  /.m4a/

# If you want to update parts of the image, add your commands here.
# For example:
# RUN apt-get update
# RUN apt-get install -y \
#       package1=version \
#       package2=version \
#       package3=version
# RUN yum update
# RUN wget http://github.com

ENTRYPOINT ["/ko-app/service-manager-runtime", "start", "-c", "/.m4a/"]

Wenn Sie eine Migration ausführen, kopieren oder fügen folgende Dockerfile-Anweisungen die VM-Daten aus der ursprünglichen Quelle in das Docker-Image ein:

Mit der folgenden Anweisung wird die Tar-Datei, die die von der Quell-VM erfassten Daten enthält, dem Docker-Image hinzugefügt:
```
ADD vmFiles.tar.gz /
```
Diese TAR-Datei wird von Migrate to Containers erstellt. Sie enthält das Stammdateisystem der Quell-VM mit allen im Filter enthaltenen Migrationsplänen und allen Ordnern, die im Datenmigrationsplan bereitgestellt werden.

Mit folgender Anweisung wird die Migrate to Containers-Laufzeit aus dem Docker-Repository in das Docker-Image importiert:

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime

Mit folgender Anweisung wird dann die Migrate to Containers-Laufzeit in das Docker-Image kopiert:
```
COPY --from=service-manager-runtime / /
```

Klicken Sie, um Details zur Migrate to Containers-Laufzeitdatei anzusehen

/ko-app/service-manager-runtime ist die Hauptlaufzeitdatei von Migrate to Containers. Dies ist ein Initialisierungssystem, das für Container optimiert ist. Es werden folgende Aufgaben ausgeführt:

Liest die /.m4a/services-config.yaml-Datei und führt die angegebenen Binärdateien entsprechend der angegebenen Ausführungsmethode aus, z. B. Daemonisiernen, nicht Daemonisieren, auf Abschluss des Vorgangs warten.
Erfasst Logs, die in der /code/config/logs/logsArtifact.yaml-Datei angegeben sind, und gibt sie in stdout des Containers aus. Bei GKE und GKE-Clustern wird außerdem sichergestellt, dass die Logs an Cloud Logging gesendet werden.

Wartung migrierter Arbeitslasten

Sie können aus den migrierten Artefakten eine neue Pipeline für Ihre Anwendung erstellen. Möglicherweise haben Sie für unterschiedliche Anwendungen unterschiedliche Pipelines. Sie können die vorhandene Pipeline für Continuous Integration und Deployment, die die ursprüngliche VM-basierte Anwendung generiert hat, beibehalten. Außerdem können Sie die relevanten Schritte hinzufügen, die die generierten ausführbaren Dateien in Linux-Systemcontainer umwandeln.

Das folgende Diagramm zeigt eine Beispielpipeline mit Migrate to Containers:

Automatisierter CI/CD-Ablauf für den Plattformwechsel von Anwendungen mit Migrate to Containers

Dieses Diagramm zeigt den Änderungsprozess einer vorhandenen Anwendung.

Eine Änderung am Quellcode oder ein neuer Betriebssystempfad wird per Push in das vorhandene Git-Repository übertragen. Die Quelle wird anhand der vorhandenen Konfiguration kompiliert und ein neues Image wird erstellt. Das neue Image enthält die Migrate to Containers-Laufzeitebene.

In der Testumgebung führt ein Entwickler Vorabtests durch, um zu prüfen, ob das neue Image wie erwartet funktioniert. Nach der Testphase wird ein neues Systemcontainer-Image erstellt und in die Entwicklungs- oder Testumgebung übertragen, die später in der Produktion bereitgestellt wird.