Image-Updates nach der Migration

Die Containerartefakte, die Sie mit dem Befehl migctl migration generate-artifacts erstellen, sind nicht nur für die Bereitstellung der migrierten Arbeitslast im Zielcluster gedacht. Sie sind auch für Wartungsvorgänge am "Tag 2" vorgesehen. Das schließt Software-Updates für Anwendungsbetriebssysteme sowie Betriebssysteme im Nutzermodus, Sicherheitspatches, das Bearbeiten von eingebetteten Konfigurationen, das Hinzufügen oder Ersetzen von Dateien und das Aktualisieren der Runtime-Software von Migrate to Containers ein.

Generiertes Image-Dockerfile prüfen

Solche Wartungsvorgänge nutzen das generierte Dockerfile und die erfasste System-Image-Ebene. In Kombination mit der Laufzeitebene von "Migrate to Containers" können diese Dateien in ein ausführbares Container-Image erstellt werden.

Bei der Erzeugung der Containerartefakte wurde die Einbindung der CI-/CD-Pipelineerstellung berücksichtigt, wie im folgenden Diagramm beschrieben:

Diagramm mit CI-/CD-Pipeline

Das Dockerfile wird als mehrstufiger Build strukturiert. So werden die Wartung und Bearbeitung erleichtert, ohne das Image zu überlasten.

Beispiel für ein generiertes Dockerfile:

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

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.6.0 as migrate-for-anthos-runtime

# Image containing data captured from the source VM
FROM gcr.io/myproject/myworkload-non-runnable-base:v1.0.0 as source-content

# 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

COPY --from=migrate-for-anthos-runtime / /

# Migrate for GKE Enterprise image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

Die zweite FROM-Anweisung verweist auf die erfasste System-Image-Ebene von der migrierten VM. Diese Ebene kann nicht allein ausgeführt werden und muss mit der Laufzeitebene von Migrate to Containers kombiniert werden, um ein ausführbares Image zu erstellen.

Weitere Informationen zum Erstellen von Container-Images mit Cloud Build finden Sie unter Container-Images erstellen.

Ebene der migrierten Arbeitslastkomponenten aktualisieren

Updates oder Änderungen, die Sie auf der Image-Ebene der migrierten Arbeitslast anwenden möchten, sollten nach der zweiten FROM-Anweisung übernommen werden.

Im folgenden Beispiel aktualisieren wir ein Container-Image, das von einer SLES-VM (SUSE Enterprise Linux) als Quelle migriert wurde, mithilfe von Cloud Build und der gcloud CLI. Im folgenden Beispiel wird das SLES-Distributionspaket openssh aktualisiert.

Aktualisiertes Dockerfile:

# Image containing data captured from the source VM
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.6.0 as migrate-for-anthos-runtime

# Image containing data captured from the source VM
FROM gcr.io/myproject/myworkload-non-runnable-base:v1.0.0 as source-content

# 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

RUN zypper ref -s && zypper -n in openssh
COPY --from=migrate-for-anthos-runtime / /

# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

Aktualisiertes Image erstellen:

  1. Laden Sie das generierte Dockerfile aus dem Cloud Storage-Bucket in ein lokales Verzeichnis in Ihrer Cloud Shell-Umgebung herunter.
  2. Bearbeiten Sie das Dockerfile, um die markierte RUN-Anweisung wie im obigen Beispiel hinzuzufügen.
  3. Erstellen Sie das aktualisierte Image und übertragen Sie es mit einem aktualisierten Versions-Tag an Container Registry, damit genügend Zeit bleibt, um den Build fertigzustellen. Im folgenden Beispiel befindet sich das Image im aktuellen Verzeichnis:

    gcloud builds submit --timeout 4h --tag gcr.io/myproject/mySUSEworkload:v1.0.1 .
    
  4. Sie können das neu erstellte Image verwenden, um eine vorhandene Bereitstellung zu aktualisieren, etwa um ein Rolling-Upgrade für die bereitgestellte Anwendung durchzuführen:

    kubectl set image deployment/myWorkload my-app=gcr.io/myproject/mySUSEworkload:v1.0.1 --record
    

Version der Migrate to Containers-Ebene aktualisieren

Wenn neue Versionen der Migrate to Containers-Software veröffentlicht werden, können Sie die Softwareversion in den bereitgestellten Arbeitslast-Images aktualisieren. Das kann neue Features, Verbesserungen oder Fehlerkorrekturen beinhalten.

Bearbeiten Sie das Dockerfile und ändern Sie das Versions-Tag in die aktualisierte Version, die Sie anwenden möchten, um die Software-Ebene von Migrate to Containers zu aktualisieren.

Mithilfe des vorherigen Beispiels können Sie die Version von v1.6.0 auf die hypothetische Version v1.15.0 aktualisieren. Ändern Sie dazu die FROM-Anweisung so:

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime

Nachdem Sie das Dockerfile aktualisiert haben, müssen Sie eine neue Image-Version des Arbeitslastcontainers erstellen und auf vorhandene Bereitstellungen anwenden, um sie zu aktualisieren.

Nächste Schritte