Manuelle Migration zu gcr.io-Repositories in Artifact Registry

In diesem Dokument wird die manuelle Einrichtung von gcr.io-Repositories in Artifact Registry.

Wir empfehlen, unser Tool für die automatische Migration zu verwenden, um zu gcr.io-Repositories in Artifact Registry zu wechseln.

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 Vorab aus und folgen Sie dann der Anleitung unter Manuelles Erstellen eines Repositories.

Hinweis

  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-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 ein Image zum ersten Mal per Push an einen gcr.io-Hostnamen übertragen: Artifact Registry – Create-on-Push-Autor (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 listen Sie aktivierte Dienste in einer Organisation auf: Cloud-Asset-Betrachter (roles/cloudasset.viewer) für das Unternehmen

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 kein Container Registry zuordnen. in einem Artifact Registry-Repository in einem anderen Projekt gehostet werden.
  • 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 Standort Ihrer Repositories benötigen, können Sie Umstellung auf Standard-Repositories in Artifact Registry pkg.dev-Domain. Da Standard-Repositories die gcr.io-Domain nicht unterstützen, sind bei diesem Übergangsansatz mehr Änderungen an Ihren vorhandenen Automatisierungen und Workflows erforderlich. Weitere Informationen finden Sie unter [Übergangsoption auswählen][Optionen]. Funktionsunterschiede.

Repositories erstellen

Erstellen Sie gcr.io-Repositories, damit Sie den Zugriff für Ihre Nutzer und Vorhandene Container Registry-Images vor der Aktivierung in Artifact Registry kopieren Weiterleitung.

Schnelle Repository-Erstellung

Wenn Sie die vom Kunden verwaltete Verschlüsselung verwenden möchten Schlüssel (CMEK) haben, müssen Sie Repositories erstellen manuell. Andernfalls können Sie diese Schritte ausführen, um gcr.io Repositories, die mit Google-eigenen und von Google verwalteten Schlüsseln verschlüsselt sind.

So erstellen Sie gcr.io-Repositories:

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

    Zur Seite „Repositories“

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

  2. Öffnen Sie die Seite Einstellungen der Artifact Registry.

    Zur Seite "Einstellungen"

  3. Klicken Sie im Banner auf gcr.io Repositories erstellen.

    Der Bereich gcr.io-Repositories erstellen wird geöffnet. Die Seite Bilder kopieren enthält die voll qualifizierten Namen jedes Repositorys, das erstellt. Sie benötigen diese Repository-Namen, wenn Sie sie kopieren möchten Images aus Container Registry erstellt, bevor Sie die Weiterleitung aktivieren.

  4. Klicken Sie auf Erstellen.

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

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

Wenn Sie die Artifact Registry-URL für das Repository sehen möchten, halten Sie den Mauszeiger über dem Warnsymbol ( ) neben dem Repository-Namen.

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.

Manuelles Erstellen eines Repositories

Erstellen Sie gcr.io-Repositories manuell, wenn Sie sie verwenden möchten Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) zum Verschlüsseln oder wenn eine Standortbeschränkung in Ihrem Google Cloud-Organisation, die das Erstellen neuer Ressourcen in an bestimmten Standorten suchen.

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 erteilen 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-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-Repositorys 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 sensiblen Daten, 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: Repository-Inhalte verschlüsseln mit einer Google-eigener und von Google verwalteter 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 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-Repositorys 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. Das sollten Sie nicht tun: enthalten sensible Daten, 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 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 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 eine eigene IAM-Rolle Rollen und diese Rollen Lese-, Schreib- und Repository-Verwaltungsrollen deutlicher Container Registry.

So ordnen Sie vorhandene Berechtigungen, die für Storage-Buckets erteilt wurden, schnell den Vorschlägen zu Für Artifact Registry-Rollen verwenden Sie das Rollenzuordnungstool.

Alternativ können Sie eine Liste der Hauptkonten mit Zugriff auf den Speicher aufrufen Buckets mithilfe der Google Cloud Console.

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

    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 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 am besten zu gewährende Artifact Registry-Rolle.

Cloud Storage und grundlegende Rollen

Nutzern und Dienstkonten gewähren, die derzeit auf Container Registry zugreifen mit Zugriff auf Artifact Registry-Repositories. Für Cloud Storage vom übergeordneten Projekt übernommen haben, sollten Sie überprüfen, verwendet derzeit Container Registry. 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 es vor der Einführung von IAM gab, haben einen 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, für welche Nutzer und Dienstkonten Folgendes erforderlich ist: Zugriff auf Artifact Registry und die Tabelle Rollenzuordnung zur Unterstützung gewähren Sie die richtigen Rollen, wenn der Zugriff auf Artifact Registry angemessen ist.

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

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
  • 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 zum ersten Mal ein Image in einem Projekt auf einen gcr.io-Hostnamen gepusht wird. Storage Admin
(roles/storage.admin)
Artifact Registry-Repository-Administrator für Erstellung und Push-Funktion
(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 Rollen für Dienst-Agenten

Standarddienstkonten für Google Cloud-Dienste haben eigene die auf Projektebene gewährt wurden. Zum Beispiel der Dienst-Agent für Cloud Run hat 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 Gewähren von Artifact Registry-Rollen finden Sie unter Konfigurieren Sie Rollen und Berechtigungen.

Container aus Container Registry kopieren

Wir empfehlen die Verwendung unseres automatischen Migrationstools, um von Container Registry in Artifact Registry übertragen können.

Wenn Sie andere Tools zum Kopieren Ihrer Bilder verwenden möchten, lesen Sie 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

Die Artefaktanalyse unterstützt beides Container Registry und 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
Scannt nach Sicherheitslücken in Betriebssystem- und Sprachpaketen mit On-Demand-Scans in Images mit einem unterstützten Betriebssystem. Beim automatischen Scannen wird nur das Betriebssystem zurückgegeben Informationen zu Sicherheitslücken. Weitere Informationen zu den verschiedenen Arten von Scans
On-Demand-Scans
Automatisches Scannen
  • Mit dem Google Cloud CLI-Befehl gcloud container images enthält Flags zum Anzeigen von Scanergebnissen. einschließlich Sicherheitslücken und anderer Metadaten.
  • Bei Scans werden nur Informationen zu Sicherheitslücken im Betriebssystem für Images in Container Registry mit unterstützten Betriebssystemen zurückgegeben.
Scannt nach Sicherheitslücken in Betriebssystem- und Sprachpaketen mit On-Demand- und automatisches Scannen. Weitere Informationen zu den verschiedenen Arten von Scannen.
On-Demand-Scanning
Automatischer Scan
  • Mit dem Google Cloud CLI-Befehl gcloud Artefakte Docker-Images enthalten Flags zum Anzeigen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
  • Bei Scans werden 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ü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 nicht Nachrichten für gcr.io Repositories senden, 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-Zugriffen aktivieren

Nachdem Sie Ihre gcr.io-Repositories erstellt haben und konfigurierte Berechtigungen und die Authentifizierung für Ihr Drittanbieter-Clients verwenden, 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ückleiten in Container Registry hochladen, indem Sie den gcloud artifacts settings disable-upgrade-redirection und aktivieren Sie dann die Umleitung wieder, wenn Sie das Problem zu lösen.

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 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 für das gesamte Projekt. Diese Berechtigung befindet sich in der Rolle „Storage-Administrator“ (roles/storage.admin)

Wenn Sie diese Berechtigungen nicht haben, bitten Sie einen Administrator, Gewähren auf Projektebene zuweisen können.

Mit den folgenden Befehlen gewähren Sie dem 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: 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 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:

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

legacyRedirectionState: REDIRECTION_FROM_GCR_IO_ENABLED

Der gesamte Verkehr nach gcr.io, asia.gcr.io, eu.gcr.io und us.gcr.io ist weitergeleitet, auch wenn Sie nicht gcr.io Repositories für alle Container Registry-Hostnamen. Wenn Sie ein Image auf einen Hostnamen hochladen, für den es kein entsprechendes Artifact Registry-Repository gibt, 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 per Push oder Pull übertragen.

Weiterleitung prüfen

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

  1. Übertragen Sie ein Testbild mithilfe der gcr.io an eines Ihrer gcr.io-Repositories Pfad.

    1. Taggen Sie das Bild mit dem Pfad gcr.io. Dieser Befehl taggt das Image local-image als us.gcr.io/my-project/test-image:

      docker tag local-image us.gcr.io/my-project/test-image
      
    2. Senden Sie das Bild, das Sie getaggt haben. Mit diesem Befehl wird z. B. die Methode Bild us.gcr.io/my-project/test-image:

      docker push us.gcr.io/my-project/test-image
      
  2. Images im Repository auflisten, um zu prüfen, ob das Image hochgeladen wurde erfolgreich war. 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 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 pushen, pullen und bereitstellen, wenn die Weiterleitung aktiviert ist.
  • Ihre Automatisierung überträgt nur Images in 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.

Löschen Sie das Cloud Storage-Objekt, um alle Container Registry-Images sicher zu entfernen. 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 Cloud Storage-Seite auf.
  2. Wählen Sie den zu löschenden Storage-Bucket aus. In den Bucket-Namen PROJECT-ID ist Ihr Google Cloud-Team 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.

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. Führen Sie den Vorgang stattdessen über die Google Cloud Console aus. Weitere Informationen finden Sie unter Bulk-Löschen von Cloud Storage-Objekten

Verwenden Sie zum Löschen eines Buckets den gcloud storage rm mit dem Flag --recursive.

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 in derselben Google Cloud ausgeführt werden Projekt erstellen, lassen Sie die Container Registry API aktiviert. Wenn Sie versuchen, Deaktivieren Sie die Container Registry API. Container Registry zeigt eine Warnung an, wenn andere Dienste mit einer konfigurierten Abhängigkeit im Projekt aktiviert sind. Container Registry API deaktivieren deaktiviert automatisch alle Dienste im selben Projekt mit einer auch wenn Sie Container Registry derzeit nicht mit diesen Dienstleistungen.

Nächste Schritte