Standardmäßig in Artifact Registry gehosteter gcr.io

Hier erfahren Sie, wie Sie gcr.io-Repositories in Artifact Registry einrichten. mehr über die Unterschiede zwischen Artifact Registry- und Container Registry-Berechtigungen und Storage-Bucket Konfiguration.

Die in diesem Dokument beschriebenen manuellen Schritte können mit dem Tool für die automatische Migration. Wenn Sie die automatische Migrationstool zur Umstellung Ihrer Projekte mit aktiver Container Registry-Nutzung auf Artifact Registry-Standard-Repositories oder gcr.io-Repositories erhalten, siehe Migration zu Artifact Registry automatisieren.

Einstellung von Container Registry

Google Cloud-Projekte, die Container Registry bisher noch nicht verwendet haben Ab dem 15. Mai 2024 werden Bilder nur noch in Artifact Registry. Diese Änderung betrifft Folgendes:

  • Neu erstellte Projekte.
  • Vorhandene Projekte, für die Sie kein Image per Push an Container Registry übertragen haben.

Organisationen, die Container Registry noch nicht verwendet haben Ab dem 8. Januar 2024 werden neue gcr.io-Repositories in Standardmäßig Artifact Registry.

Wenn Sie die Artifact Registry API in diesen Projekten aktivieren, wird Artifact Registry die Erstellung von gcr.io Repositories in Artifact Registry automatisch durchführen und Anfragen an die Domain gcr.io an die entsprechende Artifact Registry weiterleiten zu erstellen. Im Gegensatz zu vorhandenem gcr.io-Domainsupport in Projekten bei aktiver Container Registry-Nutzung erfolgt die Weiterleitung zu Artifact Registry automatisch.

Container Registry bleibt in Projekten verfügbar, in denen eines der folgenden Elemente Aktionen vor dem 15. Mai 2024:

  • Sie haben die Container Registry API im Projekt aktiviert.
  • Sie haben ein Image an einen Registry-Host im Projekt übertragen.

Zur Vorbereitung auf die bevorstehende Änderung empfehlen wir Ihnen Folgendes:

  • Folgen Sie der Anleitung in diesem Dokument, um Projekte zu konfigurieren, in denen Sie Container Registry nicht verwenden, sodass sie nicht für die automatische Verarbeitung bereit sind von gcr.io Anfragen, wenn die Änderungen wirksam werden.
  • Support für gcr.io-Domains testen um zu überprüfen, ob Ihre bestehende Automatisierung weiterhin funktioniert.

gcr.io in Artifact Registry gehostete Repositories werden im selben Multi-Regionen, die von Container Registry unterstützt werden. Wenn Sie Ihre Bilder speichern möchten In anderen Regionen müssen Sie zu Standard-Repositories wechseln. in der Domain pkg.dev.

Erforderliche Rollen

Um die Berechtigungen zu erhalten, die Sie zum Einrichten von `gcr.io`-Repositories benötigen, bitten Sie Ihren Administrator, Ihnen folgenden IAM-Rollen:

  • So erstellen Sie Artifact Registry-Repositories und gewähren Zugriff auf einzelne Repositories: Artifact Registry-Administrator (roles/artifactregistry.admin) für das Projekt
  • So rufen Sie die vorhandene Container Registry-Konfiguration auf, die auf Cloud Storage-Storage-Buckets angewendet wurde: Storage-Administrator (roles/storage.admin) für das Projekt
  • So gewähren Sie Repository-Zugriff auf Projektebene: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) oder eine Rolle mit gleichwertigen Berechtigungen wie Ordneradministrator (roles/resourcemanager.folderAdmin) oder Organisationsadministrator (roles/resourcemanager.organizationAdmin) für das Projekt, den Ordner oder die Organisation
  • 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 verwalten.

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

Hinweise

Sie können Projekte auflisten, in denen mindestens ein Image in Container Registry gespeichert ist. Sie können sich dann darauf konzentrieren, andere Projekte zum Hosten von gcr.io-Anfragen einzurichten. in Artifact Registry anhand der Anleitung in diesem Dokument.

Führen Sie den folgenden Befehl aus, um die Container Registry-Nutzung in der Google Cloud-Organisation.

  gcloud container images list-gcr-usage \
      --organization=ORGANIZATION

Ersetzen Sie ORGANIZATION durch Ihre Google Cloud Organisations-ID.

Sie können auch die Container Registry-Nutzung für Ihr Projekt oder Ordner auflisten. Weitere Informationen Informationen zur Ermittlung der Container Registry-Nutzung finden Sie unter Nutzung von Container Registry prüfen

API aktivieren

Aktivieren Sie die Artifact Registry API, damit Anfragen an die Domain gcr.io: wird automatisch von Artifact Registry verarbeitet, wenn das automatische gcr.io-Hosting wirksam wird.

  1. Führen Sie dazu diesen Befehl aus:

    gcloud services enable \
    artifactregistry.googleapis.com

  2. Wenn Sie die Container Registry API normalerweise in einem VPC Service Controls-Dienstperimeter, müssen Sie auch die Artifact Registry API im Perimeter platzieren. Weitere Informationen finden Sie unter Repositories in einem Dienstperimeter sichern .

Berechtigungen für Repositories erteilen

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

Vorhandene Berechtigungen für Storage-Buckets schnell vorgeschlagenen Berechtigungen zuordnen Für Artifact Registry-Rollen verwenden Sie das Rollenzuordnungstool.

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

  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 Ihr 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 einfache 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 vor IAM haben eingeschränkten Zugriff auf Storage-Buckets. Sie gewähren nicht grundsätzlich den gesamten Zugriff auf Cloud Storage Ressourcen, die ihr Name andeuten, 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 Sie gewähren 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 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
gcr.io-Repository in Artifact Registry erstellen, wenn ein Image zum ersten Mal wird an einen gcr.io-Hostnamen in einem Projekt gesendet. Storage-Administrator
(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 Dienst-Agent-Rollen

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 gleichwertige Standardeinstellungen Berechtigungen für Container Registry und Artifact Registry erhalten. keine weiteren Änderungen vornehmen müssen, wenn Sie Artifact Registry befindet sich im selben Projekt wie Ihr vorhandenes Container Registry .

Weitere Informationen finden Sie im Rollenreferenz für Dienst-Agent für Details zu den Berechtigungen in Dienst-Agent-Rollen.

Benutzerdefinierte Rollen

Anhand der Tabelle Rollenzuordnung können Sie sich für die Rolle, die Nutzern oder Dienstkonten je nach Zugriffsebene zugewiesen werden soll die sie benötigen.

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

Storage-Bucket-Konfiguration

Wenn Sie ein Repository in Artifact Registry erstellen, wird in Artifact Registry kein Cloud Storage-Buckets in Ihrem Projekt. Wenn Sie Automatisierung nutzen für Container Registry, das direkt mit Storage-Buckets interagiert, müssen Sie um entsprechende Änderungen am Artifact Registry-Repository vorzunehmen.

Wenn Sie beispielsweise Cloud Storage-Berechtigungen Storage-Buckets für Container Registry verwenden möchten, müssen Sie diese Automatisierung aktualisieren, um Artifact Registry-Berechtigungen für die Artifact Registry-Repositories, für die Images gehostet werden die Domain gcr.io.

In Artifact Registry legen Sie die Verschlüsselungsmethode für gespeicherte Daten in einem Repository fest statt eines Storage-Buckets. Automatisches gcr.io-Hosting in Artifact Registry wird erstellt gcr.io Repositories, 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 den gcr.io Repositories selbst und geben Sie CMEK als Verschlüsselungsmethode an, wenn wenn Sie sie erstellen.

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 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 Asien
      eu.gcr.io Europa
      us.gcr.io us

    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 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 Asien
      eu.gcr.io Europa
      us.gcr.io us

    • 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 zur Cloud KMS-Verschlüsselung. Schlüssel, wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel verwenden um Repository-Inhalte zu verschlüsseln. 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 auflisten mit dem folgenden Befehl:

    gcloud artifacts repositories list

Nächste Schritte

Support für gcr.io-Domains einrichten in einem Testprojekt durchgeführt werden, um zu überprüfen, wie Cloud Build, Google Kubernetes Engine oder Cloud Functions zu erwarten war.