Container aus einer Drittanbieter-Registry migrieren

Wenn Sie einige Container-Images direkt aus Registrys von Drittanbietern herunterladen, um sie in Google Cloud-Umgebungen wie Google Kubernetes Engine oder Cloud Run bereitzustellen, können Ratenbegrenzungen für das Abrufen von Images oder Ausfälle von Drittanbietern Ihre Builds und Bereitstellungen beeinträchtigen. Auf dieser Seite wird gezeigt, wie Sie diese Images ermitteln und in eine Registry in Google Cloud kopieren, um sie konsolidiert und konsistent zu verwalten.

Darüber hinaus können Sie weitere Funktionen nutzen, einschließlich des Schutzes Ihrer Softwarelieferkette mit Scannen auf Sicherheitslücken und der Durchsetzung von Bereitstellungsrichtlinien mit Binärautorisierung.

Registry auswählen

Artifact Registry ist der empfohlene Dienst zum Speichern und Verwalten von Container-Images und anderen Build-Artefakten in Google Cloud.

• Wenn Sie Container Registry nicht verwenden, migrieren Sie stattdessen Images in Artifact Registry. Artifact Registry bietet mehr Flexibilität und Kontrolle, einschließlich Speicherung von Images in einer Region statt in mehreren Regionen, detaillierteren Zugriffssteuerung und Unterstützung für andere Artefaktformate.
• Wenn Sie Container Registry verwenden, Umstellung auf Artifact Registry.

Übersicht über die Migration

Wichtig: Container Registry wurde verworfen und wird demnächst eingestellt. In Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden neue gcr.io-Repositories standardmäßig in Artifact Registry gehostet. Ab dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

Die Migration Ihrer Container-Images umfasst die folgenden Schritte:

1. Richten Sie Voraussetzungen ein.
2. Identifizieren Sie zu migrierende Images.
   • Suchen Sie in Dockerfile-Dateien und Bereitstellungsmanifesten nach Verweisen auf Registrys von Drittanbietern.
   • Ermitteln Sie mithilfe von Cloud Logging und BigQuery die Abrufhäufigkeit von Images aus Drittanbieter-Registrys.
3. Identifizierte Images in Container Registry kopieren:
4. Prüfen Sie, ob die Berechtigungen für die Registry korrekt konfiguriert sind, insbesondere wenn sich Container Registry und Ihre Google Cloud-Bereitstellungsumgebung in verschiedenen Projekten befinden.
5. Aktualisieren Sie Manifeste für Ihre Bereitstellungen.
6. Stellen Sie Ihre Arbeitslasten neu bereit.
7. (Optional) Blockieren Sie Bereitstellungen von Images aus Drittanbieterquellen.

Container Registry überwacht keine Drittanbieter-Registrys auf Updates für Images, die Sie in Container Registry kopieren. Wenn Sie eine neuere Version eines Images in Ihre Pipeline einbinden möchten, müssen Sie sie in Container Registry hochladen.

Hinweis

1. Prüfen Sie Ihre Berechtigungen. Sie benötigen die IAM-Rolle Inhaber oder Bearbeiter in den Projekten, in denen Sie Images zu Container Registry migrieren.

2. Zur Projektauswahl

   1. Wählen Sie das Google Cloud-Projekt aus, in dem Sie Container Registry verwenden möchten.
   2. Rufen Sie in der Google Cloud Console Cloud Shell auf.

   3. Suchen Sie Ihre Projekt-ID und legen Sie sie in Cloud Shell fest. Ersetzen Sie YOUR_PROJECT_ID durch Ihre Projekt-ID.

      gcloud config set project YOUR_PROJECT_ID
      

3. Exportieren Sie die folgenden Umgebungsvariablen:

     export PROJECT=$(gcloud config get-value project)
   

4. Aktivieren Sie BigQuery, Container Registry und Cloud Monitoring APIs mit folgendem Befehl:

   gcloud services enable \
   containerregistry.googleapis.com \
   stackdriver.googleapis.com \
   logging.googleapis.com \
   monitoring.googleapis.com
   

5. Prüfen Sie, ob Go Version 1.13 oder höher installiert ist.

   • Prüfen Sie die Version einer vorhandenen Go-Installation mit folgendem Befehl:

     go version
     

   • Wenn Sie Go installieren oder aktualisieren müssen, finden Sie Informationen dazu in der Dokumentation zur Go-Installation.

Kosten

In diesem Leitfaden werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

• GKE
• Container Registry
• BigQuery
• Logging

Zu migrierende Images identifizieren

Suchen Sie in den Dateien, die Sie zum Erstellen und Bereitstellen Ihrer Container-Images verwenden, nach Verweise auf Registrys von Drittanbietern. Prüfen Sie dann, wie oft Sie die Images abrufen.

Verweise in Dockerfiles identifizieren

Führen Sie diesen Schritt an einem Speicherort aus, an dem Ihre Dockerfiles gespeichert sind. Dies kann dort sein, wo Ihr Code lokal geprüft wird, oder in Cloud Shell, wenn die Dateien in einer VM verfügbar sind.

Führen Sie im Verzeichnis mit Ihren Dockerfiles den folgenden Befehl aus:

grep -inr -H --include Dockerfile\* "FROM" . | grep -i -v -E 'docker.pkg.dev|gcr.io'

Die Ausgabe sieht so aus:

./code/build/baseimage/Dockerfile:1:FROM debian:stretch
./code/build/ubuntubase/Dockerfile:1:FROM ubuntu:latest
./code/build/pythonbase/Dockerfile:1:FROM python:3.5-buster

Mit diesem Befehl werden alle Dockerfiles in Ihrem Verzeichnis durchsucht, um die Zeile FROM zu ermitteln. Passen Sie den Befehl entsprechend der Speicherung Ihrer Dockerfiles an.

Verweise in Manifesten ermitteln

Führen Sie diesen Schritt an einem Speicherort aus, an dem Ihre GKE- oder Cloud Run-Manifeste gespeichert sind. Dies kann dort sein, wo Ihr Code lokal geprüft wird, oder in Cloud Shell, wenn die Dateien in einer VM verfügbar sind.

1. Führen Sie den folgenden Befehl im Verzeichnis mit Ihren GKE- oder Cloud Run-Manifesten aus:

   grep -inr -H --include \*.yaml "image:" . | grep -i -v -E 'docker.pkg.dev|gcr.io'
   

   Beispielausgabe:

   ./code/deploy/k8s/ubuntu16-04.yaml:63: image: busybox:1.31.1-uclibc
   ./code/deploy/k8s/master.yaml:26:      image: kubernetes/redis:v1
   

   Dieser Befehl prüft alle YAML-Dateien in Ihrem Verzeichnis und identifiziert die Zeile image:. Passen sie ihn so an, dass er mit der Art des Speicherns der Manifeste funktioniert.

2. Um die derzeit auf einem Cluster ausgeführten Images aufzulisten, führen Sie folgenden Befehl aus:

     kubectl get all --all-namespaces -o yaml | grep image: | grep -i -v -E 'docker.pkg.dev|gcr.io'
   

   Dieser Befehl gibt alle Objekte zurück, die im aktuell ausgewählten Kubernetes-Cluster ausgeführt werden, und ruft deren Image-Namen ab.

   Beispielausgabe:

   - image: nginx
     image: nginx:latest
       - image: nginx
       - image: nginx
   

Führen Sie diesen Befehl für alle GKE-Cluster in allen Google Cloud-Projekten aus für gesamte Abdeckung.

Abrufhäufigkeit von Drittanbieter-Registry ermitteln

Verwenden Sie in Projekten, die aus Registrys von Drittanbietern abrufen, Informationen zur Image-Abrufhäufigkeit, um festzustellen, ob Ihre Nutzung irgendwelche Ratenbegrenzungen durch die Drittanbieter-Registry fast erreicht oder überschreitet.

Logdaten erfassen

Erstellen Sie eine Logsenke, um Daten nach BigQuery zu exportieren. Eine Senke enthält ein Ziel und eine Abfrage, mit der die Logeinträge ausgewählt werden, die exportiert werden sollen. Sie können eine Senke durch Abfrage einzelner Projekte erstellen oder durch Verwendung eines Skripts, mit dem Daten projektübergreifend erfasst werden.

So erstellen Sie eine Senke für ein einzelnes Projekt:

Diese Anleitung bezieht sich auf die Benutzeroberfläche (Preview) von Logging.

1. Zu „Log-Explorer“

2. Wählen Sie ein Google Cloud-Projekt aus.

3. Geben Sie auf dem Tab Query Builder die folgende Abfrage ein:

     resource.type="k8s_pod"
     jsonPayload.reason="Pulling"
   

4. Ändern Sie den Verlaufsfilter von Letzte Stunde in Letzte 7 Tage.

   

5. Klicken Sie auf Abfrage ausführen.

6. Nachdem Sie geprüft haben, ob die Ergebnisse korrekt angezeigt werden, klicken Sie auf Aktionen > Senke erstellen.

7. Wählen Sie in der Liste der Senken BigQuery-Dataset aus und klicken Sie auf Weiter.

8. Führen Sie im Bereich „Senke bearbeiten“ die folgenden Schritte aus:

   • Geben Sie im Feld Name der Senke () image_pull_logs ein.
   • Erstellen Sie im Feld Senkenziel ein neues Dataset oder wählen Sie ein Ziel-Dataset in einem anderen Projekt aus.

9. Klicken Sie auf Senke erstellen.

So erstellen Sie eine Senke für mehrere Projekte:

1. Öffnen Sie Cloud Shell.

2. Führen Sie die folgenden Befehle in Cloud Shell aus:

   PROJECTS="PROJECT-LIST"
   DESTINATION_PROJECT="DATASET-PROJECT"
   DATASET="DATASET-NAME"
   
   for source_project in $PROJECTS
   do
     gcloud logging --project="${source_project}" sinks create image_pull_logs bigquery.googleapis.com/projects/${DESTINATION_PROJECT}/datasets/${DATASET} --log-filter='resource.type="k8s_pod" jsonPayload.reason="Pulling"'
   done
   

   Dabei gilt:

   • PROJECT-LIST ist eine Liste von Google Cloud-Projekt-IDs, die durch Leerzeichen getrennt sind. Beispiel: project1 project2 project3.
   • DATASET-PROJECT ist das Projekt, in dem Sie das Dataset speichern möchten.
   • DATASET-NAME ist der Name des Datasets, z. B. image_pull_logs.

Nachdem Sie eine Senke erstellt haben, dauert es eine gewisse Zeit, bis Daten an BigQuery-Tabellen übertragen werden. Dies hängt auch davon ab, wie häufig Images abgerufen werden.

Abfrage von Abrufhäufigkeit

Sobald Ihnen ein repräsentatives Stichprobe für das Abrufen von Images durch Ihre Builds zur Verfügung steht, führen Sie eine Abfrage für die Abrufhäufigkeit aus.

1. Wechseln Sie zur BigQuery-Konsole.

2. Führen Sie die folgende Abfrage aus:

   SELECT
     REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
     COUNT(*) AS numberOfPulls
   FROM
         `DATASET-PROJECT.DATASET-NAME.events_*`
   GROUP BY
         imageName
   ORDER BY
         numberOfPulls DESC
   

   Dabei gilt:

   • DATASET-PROJECT ist das Projekt, das Ihr Dataset enthält.
   • DATASET-NAME ist der Name des Datasets.

Das folgende Beispiel zeigt die Ausgabe der Abfrage. In der Spalte imageName können Sie prüfen, wie häufig Images abgerufen werden, die nicht in Artifact Registry oder Container Registry gespeichert sind.

Images nach Container Registry kopieren

Nachdem Sie Images von Drittanbieter-Registries ermittelt haben, können Sie diese nach Container Registry kopieren. Das gcrane-Tool bietet eine Unterstützung für den Kopiervorgang.

1. Erstellen Sie in Cloud Shell die Textdatei images.txt mit den Namen der ermittelten Images. Beispiel:

   ubuntu:18.04
   debian:buster
   hello-world:latest
   redis:buster
   jupyter/tensorflow-notebook
   

2. Laden Sie gcrane herunter.

     GO111MODULE=on go get github.com/google/go-containerregistry/cmd/gcrane
   

3. Erstellen Sie ein Skript mit dem Namen copy_images.sh, um die Liste Ihrer Dateien zu kopieren.

   Hinweis: Dieses Skript und die Anweisungen auf dieser Seite gehen davon aus, dass Sie Images in gcr.io kopieren. Wenn Sie einen anderen multiregionalen Host wie eu.gcr.io verwenden möchten, müssen Sie die Beispielkonfigurationen und -skripts entsprechend aktualisieren.

   #!/bin/bash
   
   images=$(cat images.txt)
   
   if [ -z "${GCR_PROJECT}" ]
   then
       echo ERROR: GCR_PROJECT must be set before running this
       exit 1
   fi
   
   for img in ${images}
   do
       gcrane cp ${img} gcr.io/${GCR_PROJECT}/${img}
   done
   

   Machen Sie das Skript ausführbar:

     chmod +x copy_images.sh
   

4. Führen Sie das Skript aus, um die Dateien zu kopieren:

   GCR_PROJECT=${PROJECT}
   ./copy_images.sh
   

Berechtigungen prüfen

Standardmäßig haben Google Cloud-CI/CD-Dienste Zugriff auf Container Registry im selben Google Cloud-Projekt.

• Mit Cloud Build können Images übertragen und abgerufen werden.
• Mit Laufzeitumgebungen wie GKE, Cloud Run, die flexible App Engine-Umgebung und Compute Engine können Images abgerufen werden.

Wenn Sie Images projektübergreifend übertragen oder abrufen müssen oder Tools von Drittanbietern in Ihrer Pipeline verwenden, die auf Container Registry zugreifen müssen, müssen Sie vor dem Aktualisieren und nochmaligem Bereitstellen Ihrer Arbeitslasten prüfen, ob die Berechtigungen korrekt konfiguriert sind.

Weitere Informationen finden Sie in der Dokumentation zur Zugriffssteuerung.

Manifeste zum Verweis auf Container Registry aktualisieren

Die Dockerfiles und Manifeste aktualisieren, damit sie nicht auf die Registry von Drittanbietern, sondern auf Container Registry verweisen.

Das folgende Beispiel zeigt ein Manifest, das auf die Registry eines Drittanbieters verweist:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Die aktualisierte Version dieses Manifests verweist auf das Image in Container Registry:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/<GCR_PROJECT>/nginx:1.14.2
        ports:
        - containerPort: 80

Für eine große Anzahl an Manifesten verwenden Sie sed oder ein anderes Tool, mit dem sich die Aktualisierung vieler Textdateien verarbeiten lässt.

Arbeitslasten noch einmal bereitstellen

Stellen Sie Arbeitslasten mit aktualisierten Manifesten noch einmal bereit.

Führen Sie die folgende Abfrage in der BigQuery-Konsole aus, um den Überblick über neue Imageabrufe zu behalten:

SELECT`

FORMAT_TIMESTAMP("%D %R", timestamp) as timeOfImagePull,
REGEXP_EXTRACT(jsonPayload.message, r'"(.*?)"') AS imageName,
COUNT(*) AS numberOfPulls
FROM
  `image_pull_logs.events_*`
GROUP BY
  timeOfImagePull,
  imageName
ORDER BY
  timeOfImagePull DESC,
  numberOfPulls DESC

Alle neuen Imageabrufe sollten stammen aus Container Registry und enthalten den String gcr.io.

(Optional) Image-Abrufe aus Registries von Drittanbietern blockieren

Bei GKE-Clustern, die die Binärautorisierung verwenden, blockiert die von Ihnen definierte Richtlinie automatisch Pull-Vorgänge aus nicht vertrauenswürdigen Quellen. Achten Sie darauf, dass die migrierten Images nicht durch die Richtlinie blockiert werden, indem Sie diese der Liste der Ausnahmen hinzufügen. In dieser Anleitung wird beschrieben, wie Sie eine Ausnahme für alle Images festlegen, die in Container Registry in Ihrem Projekt gespeichert sind.

Erwägen Sie bei der ersten Aktualisierung der Richtlinie, den Probelaufmodus zu aktivieren. Anstatt Images zu blockieren, erstellt die Binärautorisierung Audit-Logeinträge, sodass Sie ausstehende Images aus Drittanbieter-Registries identifizieren können, die Sie zu Container Registry migrieren müssen.

Weitere Informationen zum Konfigurieren von Bereitstellungsrichtlinien finden Sie in der Dokumentation zur Binärautorisierung.

1. Zur Seite "Binärautorisierung"
2. Klicken Sie auf Richtlinie bearbeiten.
3. Aktivieren Sie unter Projektstandardregel den Probelaufmodus.
4. Lassen Sie unter Von Bereitstellungsregeln ausgenommene Images die Option Allen von Google bereitgestellten System-Images vertrauen ausgewählt.
5. Maximieren Sie Image-Pfade.
6. Fügen Sie Ihren Images den Pfad als Ausnahme für die Standard-Projektregel hinzu:
   1. Klicken Sie unten in der Imageliste auf Images hinzufügen.
   2. Geben Sie den Image-Pfad für Ihr Google Cloud-Projekt ein. Beispiel: gcr.io/my-project/* schließt alle Images im Projekt my-project aus.
7. Wiederholen Sie den vorherigen Schritt für weitere Projekte, die Images enthalten, die Sie bereitstellen möchten.

Prüfen Sie die Probelaufereignisse für Ihre Deployments in Logging. Migrieren Sie alle verbleibenden Images, die Sie regelmäßig aus Drittanbieter-Registries beziehen. Wenn alle Images migriert wurden, können Sie per Bearbeitung der Richtlinie den Probelaufmodus deaktivieren und Images aus nicht vertrauenswürdigen Quellen blockieren.