Manuelle Migration zu gcr.io-Repositories in Artifact Registry

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

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 Manuelles Erstellen eines Repositories.

Hinweise

  1. Installieren Sie die Google Cloud CLI, falls noch nicht geschehen. 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 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) im Google Cloud -Projekt
  • So rufen Sie die vorhandene Container Registry-Konfiguration auf, die auf Cloud Storage-Speicher-Buckets angewendet wird, und verwalten sie: Speicherverwaltung (roles/storage.admin) im 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) im Google Cloud -Projekt
  • So gewähren Sie Repositoryzugriff auf Projektebene: Project IAM Admin (roles/resourcemanager.projectIamAdmin) für das Google Cloud -Projekt
  • So rufen Sie eine Liste der aktivierten 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 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 pkg.dev-Repositories in Artifact Registry wechseln. Da pkg.dev-Repositories die gcr.io-Domain nicht unterstützen, erfordert dieser Übergangsansatz mehr Änderungen an Ihren vorhandenen Automatisierungen und Workflows. 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.

Manuelles Repository 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 gilt, die das Erstellen neuer Ressourcen an bestimmten Standorten verhindert.

So erstellen Sie manuell ein gcr.io-Repository:

  1. Wenn Sie CMEK verwenden, erstellen Sie den Schlüssel, den Sie für dieses Repository verwenden möchten, und gewähren Sie Berechtigungen für die 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 Google Cloud -Konsole 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-Repositories
      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 Region für das Repository an:

      Container Registry-Hostname Speicherort des Artifact Registry-Repositories Name des Artifact Registry-Repositories
      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 werden.

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

      • von Google verwalteter Verschlüsselungsschlü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-Repositories
      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-Repositories Name des Artifact Registry-Repositories
      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. Fügen Sie keine vertraulichen Daten hinzu, 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 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 Berechtigungen, um Zugriff auf Repositories zu gewähren.

Berechtigungen für Repositories erteilen

In Container Registry wird der Zugriff über Cloud Storage-Rollen gesteuert. Artifact Registry hat eigene IAM-Rollen. Diese Rollen unterscheiden Lese-, Schreib- und Repository-Verwaltungsrollen deutlicher als Container Registry.

Mit dem Tool zur Rollenzuordnung können Sie vorhandene Berechtigungen, die für Speicher-Buckets gewährt wurden, schnell den vorgeschlagenen Rollen der Artifact Registry zuordnen.

Alternativ können Sie sich in der Google Cloud -Console eine Liste der Principals mit Zugriff auf Speicher-Buckets ansehen.

  1. Rufen Sie in der Google Cloud -Konsole die Seite Cloud Storage-Buckets auf.

    Buckets aufrufen

  2. Klicken Sie auf den Speicher-Bucket für den Registry-Host, den Sie aufrufen möchten. In den Bucket-Namen steht PROJECT-ID für 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 Untertab Nach Rolle ansehen.

  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.

Cloud Storage und grundlegende 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 Prinzipal derzeit Container Registry verwendet. Einige Prinzipale greifen möglicherweise nur auf andere Cloud Storage-Buckets zu, die nichts mit der Container Registry zu tun haben.

Die einfachen Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“, die es schon vor der Einführung von IAM gab, haben einen eingeschränkten Zugriff auf Speicher-Buckets. Sie gewähren nicht automatisch den Zugriff auf alle Cloud Storage-Ressourcen, der durch ihre Namen impliziert wird, und bieten zusätzliche Berechtigungen für andere Google Cloud- Dienste. Prüfen Sie, welche Nutzer und Dienstkonten Zugriff auf die Artifact Registry benötigen, und verwenden Sie die Tabelle Rollenzuordnung, um die richtigen Rollen zu gewähren, wenn der Zugriff auf die Artifact Registry erforderlich ist.

In der folgenden Tabelle werden Artifact Registry-Rollen basierend auf 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 kann ich eine Rolle gewähren?
Nur Bilder abrufen (schreibgeschützt) Storage-Objekt-Betrachter
(roles/storage.objectViewer)		 Artifact Registry-Leser
(roles/artifactregistry.reader) 		Artifact Registry-Repository oder Google Cloud -Projekt
  • Bilder hoch- und herunterladen (Lesen und Schreiben)
  • 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 zum ersten Mal ein Image in einem Projekt auf einen gcr.io-Hostnamen gepusht wird. Storage Admin
(roles/storage.admin)		 Artifact Registry Create-on-push Repository Administrator
(roles/artifactregistry.createOnPushRepoAdmin)		 Google Cloud -Projekt
Repositories erstellen, verwalten und löschen Storage Admin
(roles/storage.admin)		 Artifact Registry-Administrator
(roles/artifactregistry.Admin)		 Google Cloud -Projekt
Vom Projekt übernommene Rollen für Dienst-Agenten

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-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 den Rollen von Dienst-Agents finden Sie in der Referenz zu Dienst-Agent-Rollen.

Benutzerdefinierte Rollen

Anhand der Tabelle Rollenzuordnung können Sie die Rolle festlegen, die Sie Nutzern oder Dienstkonten basierend auf der erforderlichen Zugriffsebene gewähren möchten.

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

Container aus Container Registry kopieren

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

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

Weitere 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-Repositoryaktivitäten in Pub/Sub-Benachrichtigungen einschließen

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

Container Registry Artifact Registry
Scannet mit On-Demand-Scans in Images mit einem unterstützten Betriebssystem auf Sicherheitslücken in Betriebssystem- und Sprachpaketen. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken im Betriebssystem zurückgegeben. Weitere Informationen zu den verschiedenen Arten von Scans
On-Demand-Scanning
Automatischer Scan
  • Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderen Metadaten.
  • Bei Scans werden nur Informationen zu Sicherheitslücken im Betriebssystem für Images in Container Registry mit unterstützten Betriebssystemen zurückgegeben.
Es werden sowohl on-demand als auch automatisch Betriebssystem- und Sprachpakete auf Sicherheitslücken geprüft. Weitere Informationen zu den verschiedenen Arten von Scans
On-Demand-Scanning
Automatischer Scan
  • Der Google Cloud CLI-Befehl gcloud artifacts docker images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Scans geben Informationen zu Betriebssystemlücken für Images in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken in Sprachpaketen sowohl für unterstützte als auch 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 erst dann 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-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 und die Weiterleitung dann wieder aktivieren, sobald das Problem behoben ist.

Berechtigungen für die Weiterleitung prüfen

Um die Weiterleitung zu aktivieren, benötigen Sie die folgenden Berechtigungen auf Projektebene:

  • artifactregistry.projectsettings.update: Berechtigungen zum Aktualisieren der Projekteinstellungen der Artifact Registry. 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 Ihnen auf Projektebene zu erteilen.

Mit den folgenden Befehlen werden die Rollen „Artifact Registry Administrator“ und „Storage Admin“ 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 des Kontos, das Sie aktualisieren. Beispiel: my-user@example.com

Projekteinrichtung prüfen

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

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

Ersetzen Sie PROJECT_ID durch die Projekt-ID Ihres Google Cloud-Abos.

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

Artifact Registry kann 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 die Projekt-ID Ihres Google Cloud-Abos.

In Artifact Registry wird die Weiterleitung aktiviert.

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, geschieht Folgendes:

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 auf einen Hostnamen hochladen, für den kein entsprechendes Artifact Registry-Repository vorhanden ist, wird das Repository in Artifact Registry erstellt, wenn Sie eine Rolle mit der Berechtigung artifactregistry.repositories.createOnPush haben. Die vordefinierten Rollen „Create-on-push-Schreiber“ (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 pushen und pullen 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 mit us.gcr.io/my-project/test-image getaggt:

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

    2. Sende das Bild, das du getaggt hast. Mit diesem Befehl wird beispielsweise das Bild us.gcr.io/my-project/test-image gepusht:

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

  2. Listen Sie die Bilder im Repository auf, um zu prüfen, ob das Bild 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. Dazu gehören:

  • Nutzer und Dienstkonten, die Container Registry verwenden, können weiterhin Images pushen, pullen und bereitstellen, wenn die Weiterleitung aktiviert ist.
  • Ihre Automatisierung sendet nur Images an vorhandene Repositories.
  • Wenn das Scannen auf Sicherheitslücken der Artefaktanalyse 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 werden, ordnungsgemäß.
  • Konfigurierte Pub/Sub-Abos umfassen Benachrichtigungen zu Ä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. Löschbefehle zum Löschen von Images in gcr.io-Pfaden löschen keine auf Container Registry-Hosts gespeicherten Images.

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 jeden Container Registry-Speicher-Bucket:

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 steht PROJECT-ID für 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 Bucketnamen 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-Verfahren 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 steht PROJECT-ID für 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 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