Manuelle Migration zu gcr.io-Repositories in Artifact Registry

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

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

Hinweise

  1. Installieren Sie die Google Cloud CLI, falls sie noch nicht installiert ist. Führen Sie für eine vorhandene Installation den folgenden Befehl aus, um 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 verwendet die Resource Manager API, um eine der erforderlichen Berechtigungen zu prüfen.

    Führen Sie dazu diesen Befehl aus:

    gcloud services enable \
        cloudresourcemanager.googleapis.com \
        artifactregistry.googleapis.com
    
  3. Informieren Sie sich über die Preise für Artifact Registry, bevor Sie mit der Umstellung beginnen.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, 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) für das Google Cloud -Projekt
  • So rufen Sie die vorhandene Container Registry-Konfiguration auf, die auf Cloud Storage-Buckets angewendet wird, und verwalten sie: Storage-Administrator (roles/storage.admin) für das Google Cloud Projekt
  • 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 Writer (roles/artifactregistry.createOnPushWriter) für das Google Cloud -Projekt
  • So gewähren Sie Repository-Zugriff auf Projektebene: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) für das Google Cloud Projekt
  • So listen Sie aktivierte Dienste in einer Organisation auf: Betrachter von Cloud-Assets (roles/cloudasset.viewer) für die Organisation

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

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

Beschränkungen

Für Artifact Registry gcr.io-Repositories gelten die folgenden Einschränkungen:

  • Bei der Umstellung von Container Registry können Sie keinen Container Registry-Host einem Artifact Registry-Repository in einem anderen Projekt zuordnen.

  • Jeder Container Registry-Hostname wird nur einem entsprechenden gcr.io-Repository in Artifact Registry in derselben Multiregion zugeordnet.

  • 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 pkg.dev-Repositories in Artifact Registry migrieren. Da pkg.dev-Repositories die gcr.io-Domain nicht unterstützen, sind bei diesem Übergangsansatz mehr Änderungen an Ihrer vorhandenen Automatisierung und Ihren Workflows erforderlich. Unter Übergangsoption auswählen finden Sie Informationen zu den Funktionsunterschieden.

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.

Repository manuell erstellen

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 IhrerGoogle Cloud -Organisation eine Standorteinschränkung vorhanden ist, die das Erstellen neuer Ressourcen an bestimmten Standorten verhindert.

So erstellen Sie manuell ein gcr.io-Repository:

  1. Wenn Sie CMEK verwenden, müssen Sie den Schlüssel für dieses Repository erstellen und Berechtigungen für die Verwendung des Schlüssels gewähren. 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 Google 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 die multiregionale Option für das Repository an:

      Container Registry-Hostname Speicherort des Artifact Registry-Repositorys Artifact Registry-Repository-Name
      gcr.io us gcr.io
      asia.gcr.io Asien asia.gcr.io
      eu.gcr.io Europa eu.gcr.io
      us.gcr.io us us.gcr.io
    6. Fügen Sie eine Beschreibung für das Repository hinzu. Geben Sie keine vertraulichen 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.

      • Google-managed encryption key: Repository-Inhalte mit einem Google-owned and Google-managed encryption keyverschlüsseln.
      • 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 die Multiregion für das Repository:

      Container Registry-Hostname Speicherort des Artifact Registry-Repositorys Artifact Registry-Repository-Name
      gcr.io us gcr.io
      asia.gcr.io Asien asia.gcr.io
      eu.gcr.io Europa eu.gcr.io
      us.gcr.io us us.gcr.io
    • DESCRIPTION ist eine Beschreibung des Repositorys. Nehmen Sie keine vertraulichen Daten auf, da Repository-Beschreibungen nicht verschlüsselt werden.

    • 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 nutzen. 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 mit dem folgenden Befehl prüfen, ob das Repository erstellt wurde:

    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 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 trennen Lese-, Schreib- und Repository-Administratorrollen deutlicher als Container Registry.

Mit dem Tool zur Rollenzuordnung können Sie vorhandene Berechtigungen für Storage-Buckets schnell den vorgeschlagenen Artifact Registry-Rollen zuordnen.

Alternativ können Sie mit der Google Cloud -Konsole eine Liste der Identitäten mit Zugriff auf Speicher-Buckets aufrufen.

  1. Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.

    Buckets aufrufen

  2. Klicken Sie auf den Speicher-Bucket für den Registrierungshost, den Sie aufrufen möchten. In den Bucket-Namen ist PROJECT-ID IhreGoogle 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 Untertab Nach Rolle anzeigen.

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

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 am besten geeignete Artifact Registry-Rolle auswählen, die Sie zuweisen möchten.

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 der Prinzipal derzeit Container Registry verwendet. Einige Identitäten greifen möglicherweise nur auf andere Cloud Storage-Buckets zu, die nicht mit Container Registry zusammenhängen.

Die einfachen Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“, die es vor IAM gab, haben eingeschränkten Zugriff auf Speicher-Buckets. Sie gewähren nicht automatisch den gesamten Zugriff auf die Cloud Storage-Ressourcen, die an ihrem Namen abgelesen werden können, 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 Rollenzuordnungstabelle, um die richtigen Rollen zu gewähren, wenn der Zugriff auf Artifact Registry angemessen ist.

In der folgenden Tabelle werden Artifact Registry-Rollen den 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 Sie die Rolle zuweisen
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 hoch- und herunterladen (Lesen und Schreiben)
  • Bilder löschen
Autor alter Storage-Buckets
(roles/storage.legacyBucketWriter)
Repository-Administrator für Artifact Registry
(roles/artifactregistry.repoAdmin)
Artifact Registry-Repository oder Google Cloud -Projekt
Erstellen Sie ein gcr.io-Repository in Artifact Registry, wenn zum ersten Mal ein Image per Push-Befehl an einen gcr.io-Hostnamen in einem Projekt übertragen wird. Storage-Administrator
(roles/storage.admin)
Artifact Registry Create-on-push Repository Administrator
(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, die auf Projektebene gewährt werden. Der Dienst-Agent für Cloud Run hat beispielsweise die Rolle „Cloud Run Service Agent“.

In den meisten Fällen enthalten diese Dienst-Agent-Rollen gleichwertige 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 für Dienst-Agent-Rollen.

Benutzerdefinierte Rollen

Anhand der Rollenzuordnungstabelle können Sie entscheiden, welche Rolle Sie Nutzern oder Dienstkonten basierend auf der erforderlichen Zugriffsebene zuweisen.

Eine Anleitung zum Zuweisen von Artifact Registry-Rollen finden Sie unter Rollen und Berechtigungen konfigurieren.

Container aus Container Registry kopieren

Wir empfehlen, unser Tool für die automatische Migration zu verwenden, um Ihre Images aus Container Registry in Artifact Registry zu kopieren.

Wenn Sie andere Tools zum Kopieren Ihrer Images verwenden möchten, lesen Sie den Abschnitt Images aus Container Registry kopieren.

Andere Funktionen einrichten

In diesem Abschnitt wird die Konfiguration anderer Features beschrieben, die Sie 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 Artifact Analysis-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äten in Pub/Sub-Benachrichtigungen einbeziehen

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

Container Registry Artifact Registry
Scannen von Betriebssystem- und Sprachpaketsicherheitslücken mit On-Demand-Scans in Images mit einem unterstützten Betriebssystem. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken im Betriebssystem zurückgegeben. Weitere Informationen zu den verschiedenen Arten von Scans
On-Demand-Scanning
Automatisches Scannen
  • Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Aufrufen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Scans geben nur Informationen zu Sicherheitslücken im Betriebssystem für Images in Container Registry mit unterstützten Betriebssystemen zurück.
Sowohl On-Demand- als auch automatisches Scannen auf Sicherheitslücken im Betriebssystem und in Sprachpaketen. Weitere Informationen zu den verschiedenen Arten von Scans
On-Demand-Scanning
Automatisches Scannen
  • Der Google Cloud CLI-Befehl gcloud artifacts docker images enthält Flags zum Aufrufen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Bei Scans werden Informationen zu Betriebssystem-Sicherheitslücken für Bilder in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken in 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 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 die gcr.io-Repositories erstellt und die Berechtigungen und die Authentifizierung für Drittanbieter-Clients konfiguriert haben, können Sie die Weiterleitung von gcr.io-Traffic aktivieren.

Wenn nach der Aktivierung der Weiterleitung ein Problem auftritt, können Sie den Traffic mit dem Befehl gcloud artifacts settings disable-upgrade-redirection zurück zu Container Registry leiten. Aktivieren Sie die Weiterleitung dann wieder, wenn Sie das Problem behoben haben.

Berechtigungen zum Aktivieren der Weiterleitung prüfen

Damit Sie die Weiterleitung aktivieren können, 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 Speicher-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 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 Google Cloud die Projekt-ID.
  • PRINCIPAL ist die E-Mail-Adresse des Kontos, das Sie aktualisieren. Beispiel: my-user@example.com

Projekteinrichtung validieren

Führen Sie den folgenden Befehl aus, um die Einrichtung Ihres Projekts 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 zwar die fehlenden gcr.io-Repositories für Sie erstellen, wenn Sie die Weiterleitung aktivieren. Wir empfehlen jedoch, sie zuerst zu erstellen, damit Sie diese Aktionen ausführen können, bevor Sie die Weiterleitung aktivieren:

Weiterleitung aktivieren

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

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 mit der Aktivierung der 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 in einen Hostnamen hochladen, für den kein entsprechendes Artifact Registry-Repository vorhanden ist, wird das Repository in Artifact Registry erstellt, sofern 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 prüfen, ob Sie Images mit Ihren neuen gcr.io-Repositories übertragen und abrufen können.

Weiterleitung prüfen

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

  1. Laden Sie über den Pfad gcr.io ein Test-Image in eines Ihrer gcr.io-Repositories hoch.

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

      docker tag local-image us.gcr.io/my-project/test-image
      
    2. Laden Sie das getaggte Bild hoch. Mit diesem Befehl wird beispielsweise das Image us.gcr.io/my-project/test-image übertragen:

      docker push us.gcr.io/my-project/test-image
      
  2. Listen Sie die Images im Repository auf, um zu prüfen, ob das Image erfolgreich hochgeladen wurde. Führen Sie beispielsweise den folgenden Befehl aus, um die 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 heruntergeladen.

    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 weiterhin Images per Push übertragen, abrufen und bereitstellen, wenn die Weiterleitung aktiviert ist.
  • Ihre Automatisierung überträgt Images nur per Push in vorhandene Repositories.
  • Wenn das Scannen auf Sicherheitslücken der Artefaktanalyse aktiviert ist, werden beim Scannen Images mit Sicherheitslücken in gcr.io-Repositories identifiziert.
  • Wenn Sie die Binärautorisierung verwenden, funktionieren Ihre vorhandenen Richtlinien für Images, die aus gcr.io-Repositories bereitgestellt werden, weiterhin korrekt.
  • Konfigurierte Pub/Sub-Abos enthalten Benachrichtigungen für Änderungen in 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 Artifact Registry-gcr.io-Repository gelöscht. Mit Löschbefehlen zum Löschen von Bildern in gcr.io-Pfaden werden keine Bilder gelöscht, 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-Speicher-Buckets:

Console

  1. Rufen Sie in der Google Cloud -Console die Seite „Cloud Storage“ auf.
  2. Wählen Sie den Storage-Bucket aus, den Sie löschen möchten. In den Bucket-Namen ist PROJECT-ID Ihre Projekt-ID. Google Cloud

    • 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 den Löschvorgang zu bestätigen.

gcloud

Wenn Sie mehrere Hunderttausend Bilder in einem Bucket im Bulk löschen möchten, sollten Sie die gcloud CLI nicht verwenden, da der Löschvorgang sehr lange dauert. Verwenden Sie stattdessen die Google Cloud Console, um den Vorgang auszuführen. Weitere Informationen finden Sie unter Cloud Storage-Objekte im Bulk löschen.

Verwenden Sie den Befehl gcloud storage rm mit dem Flag --recursive, um einen Bucket zu löschen.

gcloud storage rm gs://BUCKET-NAME --recursive

Ersetzen Sie BUCKET-NAME durch den Namen des Container Registry-Speicher-Buckets. In den Bucket-Namen ist PROJECT-ID IhreGoogle 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 CloudProjekt ausgeführt werden, lassen Sie die Container Registry API aktiviert. Wenn Sie versuchen, die Container Registry API zu deaktivieren. In Container Registry wird eine Warnung angezeigt, wenn andere Dienste mit einer konfigurierten Abhängigkeit im Projekt aktiviert sind. Wenn Sie die Container Registry API deaktivieren, werden automatisch alle Dienste im selben Projekt mit einer konfigurierten Abhängigkeit deaktiviert, auch wenn Sie Container Registry derzeit nicht mit diesen Diensten verwenden.

Nächste Schritte