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 die Komponenten auf die neuesten Versionen zu aktualisieren:

    gcloud components update

  2. Aktivieren Sie die Artifact Registry API und die Resource Manager API. Die gcloud CLI prüft mithilfe der Resource Manager API, ob eine der erforderlichen Berechtigungen vorhanden ist.

    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 für Artifact Registry.

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 zeigen Sie die vorhandene Container Registry-Konfiguration an, die auf Cloud Storage-Storage-Buckets angewendet wurde: Storage-Administrator (roles/storage.admin)
  • So erstellen Sie ein gcr.io-Repository, wenn Sie ein Image zum ersten Mal per Push an einen gcr.io-Hostnamen übertragen: Artifact Registry – Create-on-Push-Autor (roles/artifactregistry.createOnPushWriter)
  • So gewähren Sie Repository-Zugriff 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-Domainunterstützung:

  • Sie können einen Container Registry-Host nicht einem Artifact Registry-Repository in einem anderen Projekt zuordnen.
  • Jeder Container Registry-Hostname ist nur einem entsprechenden Artifact Registry-gcr.io-Repository in derselben Multiregion 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 zu Standard-Repositories in der Artifact Registry-Domain pkg.dev wechseln. Da Standard-Repositories die Domain gcr.io nicht unterstützen, erfordert dieser Umstellungsansatz weitere Änderungen an Ihren vorhandenen Automatisierungen und Workflows. Weitere Informationen zu den Funktionsunterschieden finden Sie unter Umstellungsoption auswählen.

Repositories erstellen

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

Schnelle Repository-Erstellung

Mit diesen Schritten werden gcr.io-Repositories erstellt, die mit Google-eigenen und von Google verwalteten Schlüsseln verschlüsselt sind. Wenn Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEKs) 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 auf 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 Artifact Registry-Repository-Name
gcr.io gcr.io
asia.gcr.io asia.gcr.io
eu.gcr.io eu.gcr.io
us.gcr.io us.gcr.io

Halten Sie den Mauszeiger über 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.

Manuelle Repository-Erstellung

Erstellen Sie gcr.io-Repositories manuell, wenn Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) zum Verschlüsseln von Repository-Inhalten verwenden möchten oder wenn in Ihrer Google Cloud-Organisation eine Standortbeschränkung besteht, 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 möchten, und gewähren Sie Berechtigungen zur Verwendung des Schlüssels. Siehe 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 Artifact Registry-Repository-Name
      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üsselt Repository-Inhalte mit einem von Google verwalteten und einem von Google verwalteten Schlü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 Artifact Registry-Repository-Name
      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 des Repository-Inhalts 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. Diese Rollen unterscheiden sich in Lese-, Schreib- und Repository-Verwaltungsrollen deutlicher als Container Registry.

Mit dem Rollenzuordnungstool können Sie vorhandene Berechtigungen für Storage-Buckets schnell 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 dem Tab "Berechtigungen" auf den Unter-Tab Nach Rolle ansehen.

  5. Maximieren Sie eine Rolle, um die Hauptkonten anzusehen, denen diese Rolle zugewiesen ist.

Die Liste enthält IAM-Rollen, die direkt für den Bucket gewährt wurden, und Rollen, die vom übergeordneten Projekt übernommen wurden. Je nach Rolle können Sie die Artifact Registry-Rolle auswählen, die am besten zugewiesen werden soll.

Cloud Storage und einfache Rollen

Gewähren Sie Nutzern und Dienstkonten, die derzeit auf Container Registry zugreifen, Zugriff auf Artifact Registry-Repositories. Bei Cloud Storage-Rollen, die vom übergeordneten Projekt übernommen wurden, sollten Sie prüfen, 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 bereits vor IAM vorhanden waren, haben eingeschränkten Zugriff auf Storage-Buckets. Sie gewähren nicht grundsätzlich den gesamten Zugriff auf Cloud Storage-Ressourcen, der ihre Namen implizieren, und bieten 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 Rollenzuordnung, um die richtigen Rollen zu gewähren, wenn der Artifact Registry-Zugriff angemessen ist.

In der folgenden Tabelle werden Artifact Registry-Rollen anhand der Berechtigungen zugeordnet, die durch vordefinierte Cloud Storage-Rollen für den Container Registry-Zugriff gewährt werden.

Erforderlicher Zugriff Aktuelle Rolle Artifact Registry-Rolle Wo wird die Rolle gewährt?
Nur Bilder abrufen (schreibgeschützt) Storage-Objekt-Betrachter
(roles/storage.objectViewer)		 Artifact Registry-Leser
(roles/artifactregistry.reader) 		Artifact Registry-Repository oder Google Cloud-Projekt
  • Images hoch- und herunterladen (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 ein gcr.io-Repository in Artifact Registry, wenn ein Image zum ersten Mal per Push an einen gcr.io-Hostnamen in einem Projekt übertragen wird. Storage-Administrator
(roles/storage.admin)		 Artifact Registry-Repository-Administrator für die Erstellung per Push
(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 haben eigene Rollen auf Projektebene. 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 Ihren vorhandenen 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 Rollenzuordnung hilft Ihnen bei der Entscheidung, welche Rolle Nutzern oder Dienstkonten je nach erforderlicher Zugriffsebene zugewiesen werden soll.

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

Container aus Container Registry kopieren

Wir empfehlen unser Tool für automatische Migration, um Ihre Images von Container Registry nach Artifact Registry zu kopieren.

Wenn Sie andere Tools zum Kopieren Ihrer Images verwenden möchten, finden Sie weitere Informationen unter Images aus Container Registry kopieren.

Weitere Funktionen einrichten

In diesem Abschnitt wird die Konfiguration weiterer Features beschrieben, die Sie möglicherweise in Container Registry eingerichtet haben.

Artefaktanalyse

Artefaktanalyse unterstützt sowohl Container Registry als auch Artifact Registry. Beide Produkte verwenden dieselben Artefaktanalyse-APIs für das Scannen von Bildmetadaten und 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 eingeschlossen.

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

Container Registry Artifact Registry
Scannt auf Sicherheitslücken von Betriebssystem- und Sprachpaketen mit On-Demand-Scans in Images mit einem unterstützten Betriebssystem. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken des Betriebssystems zurückgegeben. Weitere Informationen zu den verschiedenen Arten des Scans
On-Demand-Scans
Automatisches Scannen
  • Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Beim Scan werden nur Informationen zu Sicherheitslücken des Betriebssystems von Images in Container Registry mit unterstützten Betriebssystemen zurückgegeben.
Scannt mit On-Demand- und automatischen Scans auf Sicherheitslücken von Betriebssystem- und Sprachpaketen. Weitere Informationen zu den verschiedenen Arten des Scans
On-Demand-Scans
Automatisches Scannen
  • Der Google Cloud CLI-Befehl gcloud artifact docker images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Bei Scans werden Informationen zu Sicherheitslücken des Betriebssystems von Images in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken von Sprachpaketen für unterstützte und nicht unterstützte Betriebssysteme zurückgegeben.

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 erst Nachrichten für gcr.io-Repositories, wenn 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-Zugriffen aktivieren

Nachdem Sie Ihre gcr.io-Repositories erstellt und Berechtigungen und die 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 zu Container Registry weiterleiten und die Weiterleitung wieder aktivieren, nachdem 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 befindet sich in der Rolle „Artifact Registry-Administrator“ (roles/artifactregistry.admin).
  • storage.buckets.update – Berechtigungen zum Aktualisieren von Storage-Buckets im gesamten Projekt. Diese Berechtigung befindet sich in der Rolle „Storage-Administrator“ (roles/storage.admin).

Wenn Sie diese Berechtigungen nicht haben, bitten Sie einen Administrator, sie auf Projektebene zu erteilen.

Mit den folgenden Befehlen werden die Rollen „Artifact Registry-Administrator“ und „Storage-Administrator“ für ein Projekt gewährt.

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 für das Konto, 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 automatisch erstellen lassen, 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 aktiviert die Weiterleitung.

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, lautet das 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 an einen Hostnamen senden, für den kein entsprechendes Artifact Registry-Repository vorhanden ist, erstellt Artifact Registry das Repository, wenn Sie eine Rolle mit der Berechtigung artifactregistry.repositories.createOnPush haben. Die vordefinierten Rollen Create-on-Push-Autor (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 prüfen, ob Sie Images mit Ihren neuen gcr.io-Repositories ü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. Taggen Sie das Image 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. Dieser Befehl überträgt beispielsweise das Image us.gcr.io/my-project/test-image per Push:

      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. Wenn Sie beispielsweise Images in us.gcr.io/my-project auflisten möchten, führen Sie den folgenden Befehl aus:

    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 Ihre vorhandene Automatisierung zum Erstellen und Bereitstellen von Images wie erwartet funktioniert. Dazu gehören:

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

Container Registry-Images bereinigen

Wenn die Weiterleitung aktiviert ist, löschen Befehle zum Löschen von Images in gcr.io-Pfaden Images im entsprechenden gcr.io-Repository von Artifact Registry. Löschbefehle zum Löschen von Images in gcr.io-Pfaden löschen keine Images, die auf Container Registry-Hosts gespeichert sind.

Wenn Sie alle Container Registry-Images sicher entfernen möchten, löschen Sie die Cloud Storage-Buckets für jeden Container Registry-Hostnamen.

So löschen Sie die einzelnen Container Registry-Storage-Buckets:

Console

  1. Rufen Sie in der Google Cloud Console die Cloud Storage-Seite 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 100.000 oder mehr Bilder in einem Bucket im Bulk löschen möchten, sollten Sie gsutil nicht verwenden, da der Löschvorgang 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. Durch das Deaktivieren der Container Registry API werden alle Dienste im selben Projekt mit einer konfigurierten Abhängigkeit automatisch deaktiviert, auch wenn Sie Container Registry derzeit nicht mit diesen Diensten verwenden.

Nächste Schritte