Linux-Cluster für die Bereitstellung vorbereiten

Auf dieser Seite wird beschrieben, wie Sie Ihren Zielcluster für die Bereitstellung vorbereiten.

Hinweise

In diesem Dokument wird davon ausgegangen, dass Sie die Migration bereits abgeschlossen haben und dass die resultierenden Artefakte vorhanden sind.

Der Zielcluster muss Lesezugriff auf die Docker-Registry haben.

Im Rahmen einer Migration lädt Migrate to Containers Docker-Images hoch, die eine in eine Docker-Registry migrierte VM darstellen. Diese Docker-Images stellen die Dateien und Verzeichnisse der migrierten VM dar.

Für die Docker-Registry können Sie Folgendes verwenden:

Weitere Informationen finden Sie unter Daten-Repositories definieren.

Arbeitslast in einem anderen Google Cloud-Projekt bereitstellen als dem, das für die Migration verwendet wird

Oft haben Sie mehrere Google Cloud-Projekte in Ihrer Umgebung. Wenn Sie eine Migration in einem Google Cloud-Projekt ausführen, die migrierte Arbeitslast jedoch in einem Cluster in einem anderen Projekt bereitstellen möchten, müssen Sie prüfen, ob die Berechtigungen richtig konfiguriert sind.

Führen Sie beispielsweise die Migration in Projekt A aus. Die migrierte Arbeitslast wird in diesem Fall in einen Container Registry-Bucket in Projekt A kopiert. Beispiel:

gcr.io/project-a/image_name:image_tag

Anschließend stellen Sie die Arbeitslast in einem Cluster in Projekt B bereit. Wenn Sie die Berechtigungen nicht korrekt konfigurieren, kann der Arbeitslast-Pod nicht ausgeführt werden, da der Cluster in Projekt B keinen Image-Pull-Zugriff auf Projekt A hat. Dann sehen Sie ein Ereignis im Pod mit einer Nachricht im Format:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Alle Projekte, für die die Compute Engine API aktiviert wurde, haben ein Compute Engine-Standarddienstkonto mit der folgenden E-Mail-Adresse:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei ist PROJECT_NUMBER die Projektnummer für Projekt B.

Achten Sie zur Umgehung dieses Problems darauf, dass das Compute Engine-Standarddienstkonto für Projekt B die erforderlichen Berechtigungen für den Zugriff auf den Container Registry-Bucket hat. Sie können den Zugriff beispielsweise mit dem folgenden gcloud storage-Befehl aktivieren:

gcloud storage buckets add-iam-policy-binding gs://artifacts.project-a.appspot.com --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

Arbeitslasten im Verarbeitungscluster bereitstellen

Sie können die migrierte Arbeitslast auf demselben Cluster bereitstellen, mit dem Sie auch die Migration durchgeführt haben. Diese Migration wird als der Verarbeitungscluster von Migrate to Containers bezeichnet. In den meisten Fällen müssen Sie keine zusätzliche Konfiguration für den Verarbeitungscluster vornehmen, da der Cluster bereits einen Lese- oder Schreibzugriff auf die Docker-Registry benötigt, um eine Migration auszuführen.

In einem Zielcluster bereitstellen, wobei Container Registry als Docker-Registry verwendet wird

Erstellen Sie ein Kubernetes-Secret mit den für den Zugriff auf Container Registry erforderlichen Anmeldedaten, um sicherzustellen, dass ein Zielcluster Zugriff auf die Container Registry hat:

  1. Erstellen Sie ein Dienstkonto zum Bereitstellen einer Migration, wie unter Dienstkonto für den Zugriff auf Container Registry und Cloud Storage erstellen beschrieben.

    In diesem Vorgang laden Sie eine JSON-Schlüsseldatei namens m4a-install.json herunter.

  2. Erstellen Sie ein Kubernetes-Secret mit den für den Zugriff auf Container Registry erforderlichen Anmeldedaten:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    Dabei gilt:

    • docker-registry gibt den Namen des Kubernetes-Secrets an, in diesem Beispiel gcr-json-key.
    • docker-server=gcr.io gibt Container Registry als Server an.
    • docker-username=_json_key gibt an, dass der Nutzername in der JSON-Schlüsseldatei enthalten ist.
    • docker-password angibt, dass ein Passwort aus der JSON-Schlüsseldatei verwendet wird.
    • docker-email die E-Mail-Adresse des Dienstkontos angibt.

  3. Legen Sie das Kubernetes-Secret so fest:

    • Ändern Sie den Standardwert imagePullSecrets:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Bearbeiten Sie die deployment_spec.yaml-Datei, um den Wert imagePullSecrets der Definition spec.template.spec hinzuzufügen. Wenn Sie WebSphere verwenden, lautet die YAML-Bereitstellungsdatei je nach Ziel twas_deployment_spec.yaml, liberty_deployment_spec.yaml oder openliberty_deployment_spec.yaml.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  4. Stellen Sie das Arbeitslast-Secret bereit, falls secrets.yaml vorhanden ist. Für Tomcat-basierte Arbeitslasten und WebSphere-basierte herkömmliche Arbeitslasten mit Liberty ist eine Secret-Datei vorhanden. Die Liberty-Datei heißt liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

In einem Zielcluster mithilfe einer Docker-Registry mit Basisauthentifizierung bereitstellen

Wenn Sie eine Docker-Registry zum Speichern von Migrations-Images verwenden, muss die Registry die Basisauthentifizierung mit einem Nutzernamen und einem Passwort unterstützen. Da es mehrere Möglichkeiten zum Konfigurieren einer schreibgeschützten Verbindung zu einer Docker-Registry gibt, sollten Sie die für Ihre Clusterplattform und Docker-Registry geeignete Methode verwenden.

Nächste Schritte