Repositories mit Unterstützung für gcr.io-Domains einrichten

In diesem Dokument wird erläutert, wie Sie gcr.io-Repositories manuell in Artifact Registry einrichten.

Wir empfehlen die Verwendung unseres automatischen Migrationstools für die Umstellung auf gcr.io-Repositories in Artifact Registry.

Wenn Sie gcr.io-Repositories in Artifact Registry mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) erstellen möchten, führen Sie die Schritte unter Vorbereitung aus und folgen Sie dann der Anleitung unter Manuelle Repository-Erstellung.

Hinweise

  1. Installieren Sie die Google Cloud CLI, falls sie noch nicht installiert ist. Führen Sie bei einer vorhandenen Installation den folgenden Befehl aus, um Komponenten auf die neueste Version zu aktualisieren:

    gcloud components update

  2. Aktivieren Sie die Artifact Registry API und die Resource Manager API. Die gcloud CLI verwendet die Resource Manager API, um nach einer der erforderlichen Berechtigungen zu suchen.

    Führen Sie dazu diesen Befehl aus:

    gcloud services enable \
    cloudresourcemanager.googleapis.com \
    artifactregistry.googleapis.com

  3. Informieren Sie sich vor der Umstellung über die pricing.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Google Cloud-Projekt zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Einrichten von „gcr.io“-Repositories benötigen:

  • So erstellen Sie Artifact Registry-Repositories und gewähren Zugriff auf einzelne Repositories: Artifact Registry-Administrator (roles/artifactregistry.admin)
  • So rufen Sie die vorhandene Container Registry-Konfiguration auf, die auf Cloud Storage-Storage-Buckets angewendet wurde, und verwalten sie: Storage-Administrator (roles/storage.admin)
  • So erstellen Sie ein gcr.io-Repository, wenn Sie zum ersten Mal ein Image per Push an einen gcr.io-Hostnamen übertragen: Artifact Registry Create-on-push-Autor (roles/artifactregistry.createOnPushWriter)
  • So gewähren Sie Zugriff auf das Repository auf Projektebene: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) oder eine Rolle mit entsprechenden Berechtigungen wie Ordneradministrator (roles/resourcemanager.folderAdmin) oder Organisationsadministrator (roles/resourcemanager.organizationAdmin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Möglicherweise können Sie die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Beschränkungen

Die folgenden Einschränkungen gelten für Repositories mit gcr.io-Domainsupport:

  • Sie können einen Container Registry-Host keinem Artifact Registry-Repository in einem anderen Projekt zuordnen.
  • Jeder Container Registry-Hostname ist nur einem entsprechenden Artifact Registry-gcr.io-Repository am selben multiregionalen Standort zugeordnet.
  • Die Namen für gcr.io-Repositories sind vordefiniert und können nicht geändert werden.

Wenn Sie mehr Kontrolle über den Speicherort Ihrer Repositories benötigen, können Sie auf Standard-Repositories in der Artifact Registry-Domain pkg.dev umstellen. Da Standard-Repositories keine Unterstützung für die Domain gcr.io bieten, erfordert dieser Übergangsansatz mehr Änderungen an Ihrer vorhandenen Automatisierung und Ihren Workflows. Weitere Informationen zu den Funktionsunterschieden finden Sie unter Übergangsoption auswählen.

Repositories erstellen

Erstellen Sie gcr.io-Repositories, damit Sie den Zugriff für Ihre Nutzer konfigurieren und vorhandene Container Registry-Images in Artifact Registry kopieren können, bevor Sie die Weiterleitung aktivieren.

Schnelle Repository-Erstellung

Mit diesen Schritten werden gcr.io-Repositories erstellt, die mit von Google verwalteten Verschlüsselungsschlüsseln verschlüsselt sind. Wenn Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) verwenden möchten, müssen Sie Repositories manuell erstellen.

So erstellen Sie gcr.io-Repositories:

  1. Öffnen Sie in der Cloud Console die Seite Repositories.

    Zur Seite „Repositories“

    Auf der Seite wird in einem Banner die Meldung You have gcr.io repositories in Container Registry angezeigt.

    Zur Seite "Einstellungen"

  2. Klicken Sie im Banner auf gcr.io-Repositories erstellen.

    Der Bereich gcr.io Repositories erstellen wird geöffnet. Im Abschnitt Images kopieren werden die voll qualifizierten Namen jedes Repositorys aufgeführt, das erstellt wird. Sie benötigen diese Repository-Namen, wenn Sie Images aus Container Registry kopieren möchten, bevor Sie die Weiterleitung aktivieren.

  3. Klicken Sie auf Erstellen.

Artifact Registry erstellt gcr.io-Repositories für alle Container Registry-Hostnamen:

Container Registry-Hostname Name des Artifact Registry-Repositorys
gcr.io gcr.io
asia.gcr.io asia.gcr.io
eu.gcr.io eu.gcr.io
us.gcr.io us.gcr.io

Bewegen Sie den Mauszeiger auf das Warnsymbol ( ) neben dem Repository-Namen, um die Artifact Registry-URL für das Repository aufzurufen.

Bevor Sie Traffic zu Ihren neuen Repositories weiterleiten, müssen Sie prüfen, ob die vorhandene Automatisierung auf das Repository zugreifen kann. Im nächsten Schritt konfigurieren Sie die Berechtigungen, um Zugriff auf Repositories zu gewähren.

Repository manuell erstellen

Erstellen Sie gcr.io-Repositories manuell, wenn Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) zum Verschlüsseln von Repository-Inhalten verwenden möchten oder wenn in Ihrer Google Cloud-Organisation eine Standortbeschränkung vorliegt, die das Erstellen neuer Ressourcen an bestimmten Standorten blockiert.

So erstellen Sie manuell ein gcr.io-Repository:

  1. Wenn Sie CMEK verwenden, erstellen Sie den Schlüssel, den Sie mit diesem Repository verwenden werden, und gewähren Sie Berechtigungen zur Verwendung des Schlüssels. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel aktivieren.

  2. Fügen Sie das Repository hinzu:

    Console

    1. Öffnen Sie in der Cloud Console die Seite Repositories.

      Zur Seite „Repositories“

    2. Klicken Sie auf Repository erstellen.

    3. Geben Sie den Repository-Namen an.

      Container Registry-Hostname Name des Artifact Registry-Repositorys
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io

    4. Geben Sie Docker als Repository-Format an.

    5. Geben Sie unter Standorttyp den multiregionalen Standort für das Repository an:

      Container Registry-Hostname Speicherort des Artifact Registry-Repositorys
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us

    6. Fügen Sie eine Beschreibung für das Repository hinzu. Geben Sie keine sensiblen Daten an, da Repository-Beschreibungen nicht verschlüsselt sind.

    7. Wählen Sie im Abschnitt Verschlüsselung den Verschlüsselungsmechanismus für das Repository aus.

      • Von Google verwalteter Schlüssel: Verschlüsselung des Repository-Inhalts mit einem von Google verwalteten Verschlüsselungsschlüssel.
      • Vom Kunden verwalteter Schlüssel: Verschlüsselung des Repository-Inhalts mit einem Schlüssel, den Sie über Cloud Key Management Service steuern. Eine grundlegende Einrichtungsanleitung finden Sie unter Vom Kunden verwalteten Schlüssel für Repositories einrichten.

    8. Klicken Sie auf Erstellen.

    gcloud

    Führen Sie den folgenden Befehl aus, um ein neues Repository zu erstellen:

    gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY

    Ersetzen Sie die folgenden Werte:

    • REPOSITORY ist der Name des Repositorys.

      Container Registry-Hostname Name des Artifact Registry-Repositorys
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io

    • LOCATION ist der multiregionale Speicherort für das Repository:

      Container Registry-Hostname Speicherort des Artifact Registry-Repositorys
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us

    • DESCRIPTION ist eine Beschreibung des Repositorys. Geben Sie keine sensiblen Daten an, da Repository-Beschreibungen nicht verschlüsselt sind.

    • KMS-KEY ist der vollständige Pfad zum Cloud KMS-Verschlüsselungsschlüssel, wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel zum Verschlüsseln von Repository-Inhalten verwenden. Der Pfad hat folgendes Format:

      projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY

      Ersetzen Sie die folgenden Werte:

      • KMS-PROJECT ist das Projekt, in dem Ihr Schlüssel gespeichert ist.
      • KMS-LOCATION ist der Speicherort des Schlüssels.
      • KEY-RING ist der Name des Schlüsselbunds.
      • KEY ist der Name des Schlüssels.

    Sie können prüfen, ob das Repository erstellt wurde, indem Sie Ihre Repositories mit dem folgenden Befehl auflisten:

    gcloud artifacts repositories list

Bevor Sie Traffic zu Ihren neuen Repositories weiterleiten, müssen Sie prüfen, ob die vorhandene Automatisierung auf das Repository zugreifen kann. Im nächsten Schritt konfigurieren Sie die Berechtigungen, um Zugriff auf Repositories zu gewähren.

Berechtigungen für Repositories erteilen

Container Registry verwendet Cloud Storage-Rollen, um den Zugriff zu steuern. Artifact Registry hat eigene IAM-Rollen, die Lese-, Schreib- und Repository-Verwaltungsrollen deutlicher trennen als Container Registry.

Mit dem Tool für die Rollenzuordnung lassen sich vorhandene Berechtigungen, die für Storage-Buckets gewährt wurden, schnell den vorgeschlagenen Artifact Registry-Rollen zuordnen.

Alternativ können Sie in der Google Cloud Console eine Liste der Hauptkonten mit Zugriff auf Storage-Buckets aufrufen.

  1. Wechseln Sie in der Cloud Console zur Seite Cloud Storage-Buckets.

    Buckets aufrufen

  2. Klicken Sie auf den Storage-Bucket für den Registry-Host, den Sie ansehen möchten. In den Bucket-Namen ist PROJECT-ID Ihre Google Cloud-Projekt-ID.

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

  3. Klicken Sie auf den Tab Berechtigungen.

  4. Klicken Sie auf den Tab „Berechtigungen“ und dann auf den Untertab Nach Rolle anzeigen.

  5. Maximieren Sie eine Rolle, um die Hauptkonten mit dieser Rolle anzusehen.

Die Liste enthält IAM-Rollen, die direkt für den Bucket zugewiesen wurden, und Rollen, die aus dem übergeordneten Projekt übernommen wurden. Je nach Rolle können Sie die am besten geeignete Artifact Registry-Rolle zum Gewähren auswählen.

Cloud Storage und einfache Rollen

Gewähren Sie Nutzern und Dienstkonten, die derzeit auf Container Registry zugreifen, Zugriff auf Artifact Registry-Repositories. Prüfen Sie für Cloud Storage-Rollen, die vom übergeordneten Projekt übernommen wurden, ob das Hauptkonto derzeit Container Registry verwendet. Einige Hauptkonten greifen möglicherweise nur auf andere Cloud Storage-Buckets zu, die nichts mit Container Registry zu tun haben.

Die einfachen Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“, die vor IAM vorhanden waren, haben eingeschränkten Zugriff auf Storage-Buckets. Sie gewähren nicht grundsätzlich alle Zugriffsrechte für Cloud Storage-Ressourcen, die aus ihrem Namen hervorgeht, und bieten nicht zusätzliche Berechtigungen für andere Google Cloud-Dienste. Prüfen Sie, welche Nutzer und Dienstkonten Zugriff auf Artifact Registry benötigen, und verwenden Sie die Tabelle für die Rollenzuordnung, um die richtigen Rollen zuzuweisen, wenn der Artifact Registry-Zugriff angemessen ist.

In der folgenden Tabelle werden Artifact Registry-Rollen basierend auf den Berechtigungen zugeordnet, die von vordefinierten Cloud Storage-Rollen für den Container Registry-Zugriff gewährt werden.

Erforderlicher Zugriff Aktuelle Rolle Artifact Registry-Rolle Wo kann die Rolle gewährt werden?
Nur Images abrufen (schreibgeschützt) Storage-Objekt-Betrachter
(roles/storage.objectViewer)		 Artifact Registry-Leser
(roles/artifactregistry.reader) 		Artifact Registry-Repository oder Google Cloud-Projekt
  • Images übertragen und abrufen (Lese- und Schreibzugriff)
  • Bilder löschen
 Autor alter Storage-Buckets
(roles/storage.legacyBucketWriter)		 Artifact Registry-Repository-Administrator
(roles/artifactregistry.repoAdmin)		 Artifact Registry-Repository oder Google Cloud-Projekt
Erstellen Sie in Artifact Registry ein gcr.io-Repository, wenn ein Image zum ersten Mal an einen gcr.io-Hostnamen in einem Projekt übertragen wird. Storage-Administrator
(roles/storage.admin)		 Artifact Registry-Repository-Administrator bei Push-Erstellung
(roles/artifactregistry.createOnPushRepoAdmin)		 Google Cloud-Projekt
Repositories erstellen, verwalten und löschen Storage-Administrator
(roles/storage.admin)		 Artifact Registry-Administrator
(roles/artifactregistry.Admin)		 Google Cloud-Projekt
Vom Projekt übernommene Dienst-Agent-Rollen

Standarddienstkonten für Google Cloud-Dienste werden eigene Rollen auf Projektebene gewährt. Der Dienst-Agent für Cloud Run hat beispielsweise die Rolle „Cloud Run-Dienst-Agent“.

In den meisten Fällen enthalten diese Dienst-Agent-Rollen entsprechende Standardberechtigungen für Container Registry und Artifact Registry. Sie müssen keine zusätzlichen Änderungen vornehmen, wenn Sie Artifact Registry im selben Projekt wie Ihr vorhandener Container Registry-Dienst ausführen.

Weitere Informationen zu den Berechtigungen in Dienst-Agent-Rollen finden Sie in der Referenz zu Dienst-Agent-Rollen.

Benutzerdefinierte Rollen

Die Tabelle für die Rollenzuordnung hilft Ihnen bei der Entscheidung, welche Rolle Nutzern oder Dienstkonten je nach der benötigten Zugriffsebene zugeteilt werden soll.

Eine Anleitung zum Gewähren von Artifact Registry-Rollen finden Sie unter Rollen und Berechtigungen konfigurieren.

Container aus Container Registry kopieren

Zum Kopieren Ihrer Images von Container Registry in Artifact Registry empfehlen wir unser automatisches Migrationstool.

Wenn Sie andere Tools zum Kopieren der Images verwenden möchten, lesen Sie Images aus Container Registry kopieren

Weitere Funktionen einrichten

In diesem Abschnitt wird die Konfiguration für andere Funktionen beschrieben, die Sie möglicherweise in Container Registry eingerichtet haben.

Artefaktanalyse

Artifact Analysis unterstützt sowohl Container Registry als auch Artifact Registry. Beide Produkte verwenden dieselben Artifact Analysis APIs für Bildmetadaten und das Scannen auf Sicherheitslücken sowie dieselben Pub/Sub-Themen für Artefaktanalyse-Benachrichtigungen.

Die folgenden Aktionen werden jedoch nur ausgeführt, wenn die Weiterleitung aktiviert ist:

  • Automatisches Scannen von gcr.io Repositories in Artifact Registry.
  • gcr.io-Repository-Aktivität in Pub/Sub-Benachrichtigungen einschließen.

Sie können weiterhin die Befehle gcloud container images verwenden, um Hinweise und Vorkommen aufzulisten, die mit gcr.io-Image-Pfaden verknüpft sind.

Container Registry Artifact Registry
Scannt mit On-Demand-Scans nach Betriebssystem- und Sprachpaket-Sicherheitslücken in Images mit unterstütztem Betriebssystem. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken des Betriebssystems zurückgegeben. Weitere Informationen zu den Scantypen
On-Demand-Scans
Automatischer Scan
  • Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Scans geben nur Informationen zu Sicherheitslücken des Betriebssystems in Images in Container Registry mit unterstützten Betriebssystemen zurück.
Scannt sowohl on demand als auch automatisch nach Sicherheitslücken in Betriebssystem- und Sprachpaketen. Weitere Informationen zu den Scantypen
On-Demand-Scans
Automatischer Scan
  • Der Google Cloud CLI-Befehl gcloud Artifact docker images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Scans geben Informationen zu Sicherheitslücken des Betriebssystems in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken von Sprachpaketen für unterstützte und nicht unterstützte Betriebssysteme zurück.

Pub/Sub-Benachrichtigungen

Artifact Registry veröffentlicht Änderungen an demselben gcr-Thema wie Container Registry. Wenn Sie Pub/Sub bereits mit Container Registry im selben Projekt wie Artifact Registry verwenden, ist keine zusätzliche Konfiguration erforderlich. Artifact Registry veröffentlicht jedoch keine Nachrichten für gcr.io-Repositories, bis Sie die Weiterleitung aktivieren.

Wenn Sie Artifact Registry in einem separaten Projekt einrichten, ist das Thema gcr möglicherweise nicht vorhanden. Anleitungen zur Einrichtung finden Sie unter Pub/Sub-Benachrichtigungen konfigurieren.

Weiterleitung von gcr.io-Traffic aktivieren

Nachdem Sie gcr.io-Repositories erstellt und Berechtigungen und Authentifizierung für Ihre Drittanbieter-Clients konfiguriert haben, können Sie die Weiterleitung von gcr.io-Traffic aktivieren.

Wenn nach dem Aktivieren der Weiterleitung ein Problem auftritt, können Sie den Traffic zurück an Container Registry weiterleiten und die Weiterleitung dann wieder aktivieren, wenn Sie das Problem behoben haben.

Berechtigungen zum Aktivieren der Weiterleitung überprüfen

Zum Aktivieren der Weiterleitung benötigen Sie die folgenden Berechtigungen auf Projektebene:

  • artifactregistry.projectsettings.update: Berechtigungen zum Aktualisieren der Artifact Registry-Projekteinstellungen. Diese Berechtigung ist in der Rolle „Artifact Registry-Administrator“ (roles/artifactregistry.admin) enthalten.
  • storage.buckets.update: Berechtigungen zum Aktualisieren von Storage-Buckets im gesamten Projekt Diese Berechtigung ist in der Rolle „Storage-Administrator“ (roles/storage.admin) enthalten.

Wenn Sie diese Berechtigungen nicht haben, bitten Sie einen Administrator, sie auf Projektebene zu gewähren.

Die folgenden Befehle gewähren die Rollen „Artifact Registry-Administrator“ und „Storage-Administrator“ für ein Projekt.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/artifactregistry.admin'

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/storage.admin'

Ersetzen Sie die folgenden Werte:

  • PROJECT_ID ist die Google Cloud-Projekt-ID.
  • PRINCIPAL ist die E-Mail-Adresse des Kontos, das Sie aktualisieren. Beispiel: user:my-user@example.com

Projekteinrichtung validieren

Führen Sie den folgenden Befehl aus, um die Projekteinrichtung zu validieren:

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID --dry-run

Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

Artifact Registry sucht nach Repositories, die Container Registry-Hostnamen zugeordnet sind.

Artifact Registry kann die fehlenden gcr.io-Repositories zwar für Sie erstellen, wenn Sie die Weiterleitung aktivieren. Wir empfehlen jedoch, sie zuerst zu erstellen, damit Sie die folgenden Aktionen ausführen können, bevor Sie die Weiterleitung aktivieren:

Weiterleitung aktivieren

So aktivieren Sie die Weiterleitung für gcr.io-Traffic:

Console

  1. Öffnen Sie in der Google Cloud Console die Seite „Einstellungen“.

    Zur Seite "Einstellungen"

  2. Klicken Sie auf Route to Artifact Registry.

gcloud

Führen Sie den folgenden Befehl aus, um die Weiterleitung zu aktivieren:

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID

Ersetzen Sie PROJECT_ID durch Ihre Google Cloud-Projekt-ID.

Artifact Registry beginnt damit, die Weiterleitung zu aktivieren.

Führen Sie den folgenden Befehl aus, um den aktuellen Status der Weiterleitung zu prüfen:

gcloud artifacts settings describe

Wenn die Weiterleitung aktiviert ist, ergibt sich folgendes Ergebnis:

legacyRedirectionState: REDIRECTION_FROM_GCR_IO_ENABLED

Der gesamte Traffic zu gcr.io, asia.gcr.io, eu.gcr.io und us.gcr.io wird weitergeleitet, auch wenn Sie keine gcr.io-Repositories für alle Container Registry-Hostnamen erstellt haben. Wenn Sie ein Image per Push zu einem Hostnamen übertragen, der kein entsprechendes Artifact Registry-Repository hat, erstellt Artifact Registry das Repository, wenn Sie eine Rolle mit der Berechtigung artifactregistry.repositories.createOnPush haben. Die vordefinierten Rollen Create-on-Push Writer (artifactregistry.createOnPushWriter) und Create-on-Push Repository Administrator (artifactregistry.createOnPushRepoAdmin) haben diese Berechtigung.

Wenn die Weiterleitung aktiviert ist, können Sie Ihre Automatisierung testen und überprüfen, ob Sie mit Ihren neuen gcr.io-Repositories Images übertragen und abrufen können.

Weiterleitung überprüfen

Prüfen Sie, ob Pull- und Push-Anfragen an gcr.io-Hostnamen funktionieren.

  1. Übertragen Sie ein Test-Image über den Pfad gcr.io an eines Ihrer gcr.io-Repositories.

    1. Tagge das Bild mit dem Pfad gcr.io. Mit diesem Befehl wird das Image local-image beispielsweise als us.gcr.io/my-project/test-image getaggt:

      docker tag local-image us.gcr.io/my-project/test-image

    2. Übertragen Sie das getaggte Image per Push. Mit diesem Befehl wird beispielsweise das Image us.gcr.io/my-project/test-image per Push übertragen:

      docker push us.gcr.io/my-project/test-image

  2. Listen Sie Images im Repository auf, um zu prüfen, ob das Image erfolgreich hochgeladen wurde. Führen Sie beispielsweise den folgenden Befehl aus, um Images in us.gcr.io/my-project aufzulisten:

    gcloud container images list --repository=us.gcr.io/my-project

  3. Rufen Sie das Image aus seinem Repository-Pfad aus dem Repository ab. Mit diesem Befehl wird beispielsweise das Image us.gcr.io/my-project/test-image abgerufen.

    docker pull us.gcr.io/my-project/test-image

Prüfen Sie nach diesem ersten Test, ob die vorhandene Automatisierung zum Erstellen und Bereitstellen von Images wie erwartet funktioniert, einschließlich:

  • Nutzer und Dienstkonten, die Container Registry verwenden, können weiterhin Images hoch-, abrufen und bereitstellen, wenn die Weiterleitung aktiviert ist.
  • Ihre Automatisierung überträgt nur Images auf vorhandene Repositories.
  • Wenn das Artifact Analysis-Scannen auf Sicherheitslücken aktiviert ist, werden beim Scannen Images mit Sicherheitslücken in gcr.io-Repositories erkannt.
  • Wenn Sie die Binärautorisierung verwenden, funktionieren Ihre vorhandenen Richtlinien für Images, die aus gcr.io-Repositories bereitgestellt wurden, korrekt.
  • Konfigurierte Pub/Sub-Abos enthalten Benachrichtigungen über Änderungen an Ihren gcr.io-Repositories.

Container Registry-Images bereinigen

Wenn die Weiterleitung aktiviert ist, werden mit Befehlen zum Löschen von Images in gcr.io-Pfaden Images im entsprechenden gcr.io-Repository von Artifact Registry gelöscht. Durch Löschbefehle zum Löschen von Images in gcr.io-Pfaden werden keine Images gelöscht, die auf Container Registry-Hosts gespeichert sind.

Löschen Sie die Cloud Storage-Buckets für jeden Container Registry-Hostnamen, um alle Container Registry-Images sicher zu entfernen.

So löschen Sie jeden Container Registry-Storage-Bucket:

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Cloud Storage“ auf.

  2. Wählen Sie den zu löschenden Storage-Bucket aus. In den Bucket-Namen ist PROJECT-ID Ihre Google Cloud-Projekt-ID.

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

  3. Klicken Sie auf Löschen. Ein Bestätigungsdialogfeld wird angezeigt.

  4. Geben Sie den Bucket-Namen ein und klicken Sie auf Löschen, um das Löschen zu bestätigen.

gsutil

Wenn Sie hunderttausend Bilder in einem Bucket im Bulk löschen möchten, verwenden Sie gsutil nicht, da der Löschvorgang sehr lange dauert. Verwenden Sie stattdessen die Google Cloud Console, um den Vorgang auszuführen.

Verwenden Sie zum Löschen eines Buckets den Befehl gsutil rm mit dem Flag -r.

gsutil rm -r gs://BUCKET-NAME

Ersetzen Sie BUCKET-NAME durch den Namen des Container Registry-Storage-Buckets. In den Bucket-Namen ist PROJECT-ID Ihre Google Cloud-Projekt-ID.

  • gcr.io: artifacts.PROJECT-ID.appspot.com
  • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
  • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
  • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

Die Antwort sieht in etwa so aus:

Removing gs://artifacts.my-project.appspot.com/...

Wenn andere Google Cloud-Dienste im selben Google Cloud-Projekt ausgeführt werden, lassen Sie die Container Registry API aktiviert. Wenn Sie versuchen, die Container Registry API zu deaktivieren. Container Registry zeigt eine Warnung an, wenn andere Dienste mit einer konfigurierten Abhängigkeit im Projekt aktiviert sind. Wenn Sie die Container Registry API deaktivieren, werden im selben Projekt mit einer konfigurierten Abhängigkeit automatisch alle Dienste deaktiviert, auch wenn Sie Container Registry derzeit nicht mit diesen Diensten verwenden.

Nächste Schritte