Daten-Repositories definieren

Im Rahmen einer Migration schreibt Migrate to Containers Informationen in verschiedene Daten-Repositories:

  1. Docker-Image-Dateien einer migrierten Linux-VM werden in eine Docker-Registry geschrieben.

    Diese Docker-Image-Dateien stellen die Dateien und Verzeichnisse der migrierten Linux-VM dar. Dieses Repository ist bei der Migration von Windows-Arbeitslasten nicht erforderlich.

  2. Migrationsartefakte der migrierten Arbeitslast werden in ein zweites Repository geschrieben.

    Artefakte enthalten die YAML-Konfigurationsdateien, mit denen Sie die migrierten Arbeitslasten bereitstellen können, sowie weitere Dateien. Die genauen Artefakte hängen davon ab, ob Sie Linux- oder Windows-Arbeitslasten migrieren.

Plattform Registry für Docker-Image-Dateien* Repository für Migrationsartefakte
GKE Enterprise-Cluster in Google Cloud Der Standardwert ist Container Registry (GCR).

Optional können Sie eine beliebige Docker-Registry angeben, die die Basisauthentifizierung unterstützt.

Der Standardwert ist Cloud Storage.

Geben Sie optional S3 als Artefakt-Repo für Linux-Migrationen an. S3 wird für die Migration von Windows-Arbeitslasten nicht unterstützt.

Google Distributed Cloud Virtual for Bare Metal-Cluster Der Standardwert ist Container Registry (GCR).

Optional können Sie eine beliebige Docker-Registry angeben, die die Basisauthentifizierung unterstützt.

Der Standardwert ist Cloud Storage.

Geben Sie optional S3 als Artefakt-Repository an.

* Die Registry der Docker-Image-Dateien ist für Windows-Migrationen nicht erforderlich. Sie ist nur für die Migration von Linux-VMs erforderlich.

Repository-Status aufrufen

Nach der Installation von Migrate to Containers prüfen Sie die Installation von Migrate to Containers mit dem Befehl migctl doctor. Im Rahmen dieser Prüfung prüft der Befehl migctl doctor den Status der Repositories:

migctl doctor

In der folgenden Beispielausgabe des Befehls migctl doctor gibt das Häkchen an, dass Migrate to Containers erfolgreich bereitgestellt wurde, Sie die erforderlichen Daten-Repositories jedoch noch nicht konfiguriert haben:

  [✓] Deployment
  [!] Docker Registry
  [!] Artifacts Repo
  [!] Source Status

Wenn Probleme mit Ihren Repositories auftreten, kennzeichnet migctl doctor Sie bei der Ausführung des Befehls. Wenn Sie migctl doctor ausführen, fragt migctl alle Artefakt-Repositories ab und warnt jedes Mal, wenn ein Fehler auftritt.

In der folgenden Beispielausgabe des Befehls migctl doctor gibt das Ausrufezeichen an, dass Migrate to Containers in den Artefakt-Repositories Fehler gefunden hat. Wegen dem Fehler konnte das Repository nicht initialisiert werden. Die Konfiguration sollte korrigiert werden, bevor der Befehl noch einmal ausgeführt wird. Bei zusätzlichen Repositories, die über Ihre Standardausstattung hinausgehen, ist dies nicht unbedingt ein Hindernis für Ihre Migration.

Ist Ihr Standard-Repository fehlerhaft, so zeigt ein X an, dass Migrate to Containers einen Fehler gefunden hat und die Migration fehlschlagen kann.

[✓] Deployment
[✓] Docker Registry
[!] Artifacts Repository
    [✓] example-healthy-repository [default]
    [!] example-failed-repository
        Error: Failed to initialize repository client: Retryable M4A_RepositoryFactoryMissingSecret: artifacts repository secret is configured, but not found at the designated location '/example-failed-repository'
[!] Source Status
[✓] Default storage class

Nachdem Sie die Repositories konfiguriert haben, können Sie den Befehl migctl doctor noch einmal ausführen, um sicherzustellen, dass die Repositories richtig konfiguriert sind:

  [✓] Deployment
  [✓] Docker registry
  [✓] Artifacts repo
  [!] Source Status

Unterstützung für die Google Cloud Console

Die Google Cloud Console zeigt die URLs zu Elementen in den Repositories basierend auf der Repository-Implementierung an. Wenn das Repository beispielsweise mit S3 implementiert wird, zeigt die Google Cloud Console URLs für einen Bucket in S3 an.

Optionen für den Speicherort des Repositorys

Der Speicherort der Daten-Repositories kann sich auf die Leistung und Kosten für die Migration auswirken.

Beispielsweise können die Docker-Image-Dateien, die eine migrierte VM darstellen, sehr groß sein. Wenn Sie über einen lokalen Verarbeitungscluster verfügen, die Docker-Image-Dateien jedoch in GCR in Google Cloud schreiben, entstehen Ihnen die Leistungslatenz beim Hochladen der Daten und die Kosten für das Speichern dieser Daten.

Für einen lokalen Verarbeitungscluster ist es möglicherweise effizienter, eine lokale Docker-Registry für den Cluster zu definieren. Wenn Sie die Registry lokal ausführen, minimieren Sie die Uploadlatenz und minimieren die Speicherkosten.

Bei einem in Google Cloud bereitgestellten GKE-Cluster bietet die Verwendung der Standard-GCR-Repositories die höchste Leistung. Ihnen wird jedoch diese Speicherung in Rechnung gestellt. Sie müssen GCR jedoch nicht mit einem Cloud-basierten Cluster verwenden und können stattdessen Ihre eigene Docker-Registry verwenden.

Anforderungen zur Benennung von Repositories

Sie weisen einem Repository einen Namen zu, wenn Sie es zu Migrate to Containers hinzufügen. Der Name muss die folgenden Anforderungen erfüllen:

  • Es darf höchstens 63 Zeichen enthalten.
  • Es dürfen nur kleingeschriebene alphanumerische Zeichen oder „-“ (Bindestrich) enthalten.
  • Es muss mit einem alphanumerischen Zeichen beginnen.
  • Er muss mit einem alphanumerischen Zeichen enden.

Repository-Authentifizierung

Alle von Migrate to Containers verwendeten Repositories erfordern eine Authentifizierung. Der Authentifizierungsmechanismus hängt vom Repository-Typ ab, wie in der folgenden Tabelle dargestellt:

Repository Implementierung Authentication
Registry für Docker-Image-Dateien GCR JSON-Schlüssel für ein Google Cloud-Dienstkonto

Weitere Informationen finden Sie unter Dienstkonto für den Zugriff auf Container Registry und Cloud Storage erstellen.

Docker-Registry Nutzername und Passwort für die Basisauthentifizierung.
Repository für Migrationsartefakte Cloud Storage JSON-Schlüssel für ein Google Cloud-Dienstkonto

Weitere Informationen finden Sie unter Dienstkonto für den Zugriff auf Container Registry und Cloud Storage erstellen.

S3 Zugriffsschlüssel und Secret oder Anmeldedatendatei. Weitere Informationen finden Sie unter Zugriff verwalten.

TLS unterstützen

Auf einige Repositories kann mit TLS/SSL über HTTPS zugegriffen werden. Wenn die HTTPS-Verbindung zum Repository ein selbst signiertes Zertifikat verwendet, müssen Sie beim Konfigurieren des Repositorys eine PEM-Datei mit einem der folgenden Werte übergeben:

  • Den öffentlichen Schlüssel des selbst signierten Zertifikats
  • Eine Verkettung vom Root-Zertifikat und allen Zwischenzertifikaten bis zum tatsächlichen Serverzertifikat

Docker-Registry konfigurieren

Mit dem Befehl migctl konfigurieren Sie eine Docker-Registry. Mit dem Befehl migctl können Sie die folgenden Aktionen in einer Registry-Konfiguration ausführen:

  • Erstellen
  • Aktualisieren
  • Löschen
  • List
  • Standard festlegen

Sie können mehrere Konfigurationen definieren. Migrate to Containers verwendet die derzeit als Standard definierte Konfiguration. Rufen Sie mit dem Befehl migctl docker-registry list die aktuellen Konfigurationen einschließlich der Standardkonfiguration auf. Verwenden Sie den Befehl migctl docker-registry set-default, um die Standardkonfiguration festzulegen.

Das folgende Beispiel zeigt, wie Sie eine Docker-Registry konfigurieren:

  • GCR

    migctl docker-registry create gcr registry-name --project project-id --json-key=m4a-install.json

    Dabei gilt:

    • registry-name ist der benutzerdefinierte Name der Docker-Registry-Konfiguration.

    • project-id ist Ihre Google-Projekt-ID.

    • m4a-install.json ist der Name der JSON-Schlüsseldatei für das Dienstkonto für den Zugriff auf Container Registry und Cloud Storage, wie unter Dienstkonto konfigurieren beschrieben.

  • Docker-Registry

    migctl docker-registry create basic-auth registry-name --registry-path url --username username --ca-pem-file ca-pem-filename

    Dabei gilt:

    • registry-name ist der benutzerdefinierte Name der Docker-Registry-Konfiguration.

    • url gibt die URL des Registry-Pfads ohne das Präfix http:// oder https:// an. Beispiel: localhost:8080/myregistry

    • username für die grundlegenden Anmeldedaten zur Authentifizierung der Registry Sie werden aufgefordert, das Passwort einzugeben.

    • Wenn die Registry ein selbst signiertes Zertifikat verwendet, gibt ca-pem-filename eine PEM-Datei an, die entweder den öffentlichen Schlüssel oder die vollständige CA-Kette enthält. Dies ist eine Verkettung der Zwischen-CA-Zertifikate bis zum Root-Zertifikat. Beispiele:

      cat int1.pem int2.pem ... root.pem

Führen Sie den Befehl migctl docker-registry update mit denselben Argumenten aus, wie Sie sie zum Erstellen der Registry-Konfiguration verwendet haben, um später die Registry-Konfiguration zu aktualisieren:

migctl docker-registry update gcr registry-name same-flags-as-create

Wenn Sie eine Docker-Registry konfigurieren, wird sie zur Standard-Registry. Möglicherweise sind jedoch mehrere Registries definiert. So rufen Sie die aktuelle Liste der Registries auf:

migctl docker-registry list

Verwenden Sie den folgenden Befehl, um die Standard-Registry-Konfiguration festzulegen. Dies bedeutet, dass sie derzeit für Migrationen verwendet wird:

migctl docker-registry set-default registry-name

So löschen Sie eine Registry-Konfiguration:

migctl docker-registry delete registry-name

Artefakte-Repository konfigurieren

Mit dem Befehl migctl können Sie ein Artefakt-Repository konfigurieren. Mit dem Befehl migctl können Sie die folgenden Aktionen in einer Repository-Konfiguration ausführen:

  • Erstellen
  • Aktualisieren
  • Löschen
  • List
  • Standard festlegen

Die migctl-Befehle create, update und list nutzen kontinuierliche Systemdiagnosen für Artefakt-Repositories. Wenn sie ausgeführt werden, geben sie Nachrichten darüber zurück, ob das Repository bereit ist, und eine entsprechende Fehlermeldung. Wenn Sie die Systemdiagnose von create oder update überspringen möchten, führen Sie diese Befehle mit dem --async-Flag aus.

Sie können mehrere Konfigurationen definieren. Migrate to Containers verwendet die derzeit als Standard definierte Konfiguration. Rufen Sie mit dem Befehl migctl artifacts-repo list die aktuellen Konfigurationen einschließlich der Standardkonfiguration auf. Verwenden Sie den Befehl migctl artifacts-repo set-default, um die Standardkonfiguration festzulegen.

Das folgende Beispiel zeigt, wie ein Artefakte-Repository konfiguriert wird:

  • Cloud Storage

    migctl artifacts-repo create gcs repository-name --bucket-name bucket-name --json-key=m4a-install.json

    Dabei gilt:

    • repository-name ist der benutzerdefinierte Name der Repository-Konfiguration für Artefakte.

    • bucket-name gibt einen vorhandenen Bucket im Cloud Storage-Repository an. Wenn noch kein Bucket vorhanden ist, erstellen Sie einen anhand der Anleitung unter Buckets erstellen.

      Hinweis: Wenn Sie Migrate to Containers in Clustern in Google Cloud installieren, erstellt das Migrate to Containers-Installationsprogramm automatisch einen Standard-Bucket mit dem Namen:

      GCP_PROJECT-migration-artifacts

      Dabei ist GCP_PROJECT Ihre Google-Projekt-ID.

    • project-id ist Ihre Google-Projekt-ID.

    • m4a-install.json ist der Name der JSON-Schlüsseldatei für das Dienstkonto für den Zugriff auf Container Registry und Cloud Storage, wie unter Dienstkonto konfigurieren beschrieben.

    migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --access-key-id=key-id

    Sie werden aufgefordert, den Secret-Schlüssel für key-id einzugeben.

    Alternativ können Sie den Pfad zu einer Datei mit Anmeldedaten angeben:

    migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --credentials-file-path file-path

    Dabei gilt:

    • repository-name ist der benutzerdefinierte Name der Repository-Konfiguration für Artefakte.

    • bucket-name gibt einen vorhandenen Bucket im S3-Repository an. Wenn Sie keinen vorhandenen Bucket haben, erstellen Sie einen. Folgen Sie dazu der Anleitung unter Mit Amazon S3-Buckets arbeiten.

    • aws-region gibt die AWS-Region für das Repository an. Der Verarbeitungscluster und das Repository können sich in separaten Regionen befinden, solange der Cluster berechtigt ist, auf das Repository zuzugreifen.

    • key-id gibt den Zugriffsschlüssel an. Weitere Informationen finden Sie unter Zugriff verwalten.

    • file-path gibt den Pfad zu einer CSV-Datei an, die von der AWS-Konsole heruntergeladen wird und die Anmeldedaten enthält.

Führen Sie den Befehl migctl docker-registry update mit denselben Argumenten aus, wie Sie sie zum Erstellen der Repository-Konfiguration verwendet haben, um später die Repository-Konfiguration zu aktualisieren:

migctl artifacts-repo update gcr repository-name same-flags-as-create

Wenn Sie eine Repository-Registry konfigurieren, wird es zur Standard-Repository. Möglicherweise sind jedoch mehrere Repositories definiert. So rufen Sie die aktuelle Liste der Repositories auf:

migctl artifacts-repo list

Verwenden Sie den folgenden Befehl, um die Standard-Repository-Konfiguration festzulegen. Dies bedeutet, dass sie derzeit für Migrationen verwendet wird:

migctl artifacts-repo set-default repository-name

So löschen Sie eine Repository-Konfiguration:

migctl artifacts-repo delete repository-name

Nächste Schritte