Linux-Systemcontainer

Mit der Migrate to Containers CLI können Sie Linux-basierte Anwendungen in containerisierte Umgebungen migrieren. Dabei wird ein vordefinierter Linux-Systemcontainer verwendet, der als Bootloader für die Dienste dient, die für die modernisierte Anwendung erforderlich sind. 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.

Dieses Dokument enthält Details zu Linux-Systemcontainern von Migrate to Containers, die als Teil der Lösung zum Ausführen von Anwendungen verwendet werden, die mit Migrate to Containers migriert wurden.

Migration mit Linux-Systemcontainer

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

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

Das Dockerfile wird verwendet, um das Image für die migrierte VM zu erstellen. Ein Dockerfile für Linux-Systemcontainer sieht normalerweise 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 Ihre vorhandene Pipeline für Continuous Integration und Continuous Deployment beibehalten, die die ursprüngliche VM-basierte Anwendung generiert hat, und die relevanten Schritte hinzufügen, mit denen die generierten ausführbaren Dateien in Linux-Systemcontainer umgewandelt werden.

Das folgende Diagramm zeigt eine Beispielpipeline mit Migrate to Containers:

Automatisierter CI/CD-Ablauf für die 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 Einrichtung kompiliert und ein neues Image wird erstellt. Das neue Image enthält die Laufzeitebene von Migrate to Containers.

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