Umstellung auf Standard-Repositories

Wenn Sie Ihre Container-Images derzeit mit Container Registry verwalten, wird erläutert, wie Sie ein standardmäßiges Artifact Registry-Repository einrichten Repositories unterscheiden sich von der Verwendung von Container Registry.

Diese Anleitung richtet sich hauptsächlich an Repository-Administratoren. Weitere Informationen zu den Änderungen beim Erstellen, Pushen, Pullen und Bereitstellen von Images finden Sie unter den folgenden Links:

Hinweis

  1. Aktivieren Sie die Artifact Registry API über die Google Cloud Console oder mit dem Befehl:

    gcloud services enable artifactregistry.googleapis.com

  2. Installieren Sie die gcloud CLI, falls noch nicht geschehen. Führen Sie bei einer vorhandenen Installation den folgenden Befehl aus, um Komponenten auf die neuesten Versionen zu aktualisieren:

    gcloud components update

  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 für das Google Cloud-Projekt 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)
  • 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)
  • So gewähren Sie Repository-Zugriff auf Projektebene: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) oder eine Rolle mit entsprechenden Berechtigungen, z. B. Ordneradministrator (roles/resourcemanager.folderAdmin) oder Organisationsadministrator (roles/resourcemanager.organizationAdmin)

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.

Übersicht

Standard-Repositories sind reguläre Artifact Registry-Repositories, die alle Funktionen unterstützen.

Der Einfachheit halber wird bei den Anleitungen auf dieser Seite davon ausgegangen, dass sich sowohl Container Registry als auch Artifact Registry im selben Google Cloud-Projekt befinden. Sie können während der Umstellung auf Artifact Registry weiterhin beide Dienste verwenden, sodass Sie die Einrichtungsschritte schrittweise vornehmen und Ihre Automatisierung aktualisieren können. Bei Bedarf können Sie Artifact Registry in einem separaten Projekt einrichten und dieselben Schritte ausführen.

Artifact Registry bietet auch gcr.io-Repositories. Diese Repositories können gcr.io-Traffic von Ihren vorhandenen Registrys weiterleiten den entsprechenden Artifact Registry-Repositories zugeordnet. Sie bieten einige Abwärtskompatibilität mit Container Registry, bieten aber auch Einschränkungen. Wenn Sie jedoch viele Toolkonfigurationen, Scripts oder Code mit gcr.io-Referenzen haben, ist für die Umstellung auf Artifact Registry möglicherweise ein taktischer Ansatz erforderlich. Lesen Sie die Umstellungsdokumentation für mit gcr.io-Domainunterstützung, um eine Entscheidung zu treffen.

Umstellungsschritte

In diesem Leitfaden erfahren Sie, wie Sie die folgenden Schritte ausführen:

  1. Erstellen Sie ein Docker-Repository für Ihre Container. Sie müssen ein Repository erstellen, bevor Sie Images per Push übertragen können.
  2. Gewähren Sie Berechtigungen für das Repository.
  3. Konfigurieren Sie die Authentifizierung, damit Sie eine Verbindung zu Ihrem neuen Repository herstellen können.
  4. Bei Bedarf können Sie Images aus Container Registry kopieren, die Sie in Ihrem neuen Repository verwenden möchten.
  5. Erteilen Sie einen Push- und Pull-Befehl für Container
  6. Stellen Sie Images in einer Laufzeitumgebung bereit
  7. Konfigurieren Sie zusätzliche Features.
  8. Images in Container Registry bereinigen, wenn der Übergang abgeschlossen ist.

Repositories erstellen

Container Registry erstellt automatisch einen Storage-Bucket in mehreren Regionen, wenn Sie vorher kein Image hochgeladen haben.

In Artifact Registry müssen Sie ein Repository erstellen, bevor Sie Images hochladen können. Beim Erstellen eines Repositorys müssen Sie Folgendes angeben:

  • Das Format des Repositorys. Artifact Registry speichert Container in Docker-Repositories.

  • Ein regionaler oder multiregionaler Standort für das Repository.

    Berücksichtigen Sie bei der Wahl eines Speicherorts für Ihre Artifact Registry-Repositories die Nähe der Repositories zu Ihrer anderen Infrastruktur und Ihren Nutzern. Wenn Sie Images von Container Registry nach Artifact-Registry kopieren möchten, können sich Unterschiede im Speicherort auf die Kosten für das Kopieren auswirken.

  • Einen Cloud Key Management Service-Schlüssel, wenn Sie für die Verschlüsselung vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) verwenden.

    In Container Registry konfigurieren Sie den Container Registry-Storage-Bucket für die Verwendung von CMEK. In Artifact Registry konfigurieren Sie Repositories so, dass CMEK beim Erstellen verwendet werden. Weitere Informationen zur Verwendung von CMEK mit Artifact Registry finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel aktivieren.

Container Registry hostet Container in der Domain gcr.io. Artifact Registry hostet Container in der Domain pkg.dev.

Informationen zum Erstellen von Repositories, einschließlich Repositories, die CMEK für die Verschlüsselung verwenden, finden Sie unter Repositories erstellen.

Berechtigungen 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.

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 über die Google Cloud Console eine Liste der Hauptberechtigungen mit Zugriff auf Speicher-Buckets ansehen.

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

Cloud Storage und einfache Rollen

Gewähren Sie Nutzern und Dienstkonten, die derzeit auf Container Registry zugreifen, 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. Artifact Registry Rollen bieten eine zusätzliche Trennung von Berechtigungen, die nicht verfügbar ist. in den vordefinierten Cloud Storage-Rollen.

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) Autor alter Storage-Buckets
(roles/storage.legacyBucketWriter)		 Artifact Registry-Writer
(roles/artifactregistry.writer)		 Artifact Registry-Repository oder Google Cloud-Projekt
Images übertragen, abrufen und löschen Autor alter Storage-Buckets
(roles/storage.legacyBucketWriter)		 Artifact Registry-Repository-Administrator
(roles/artifactregistry.repoAdmin)		 Artifact Registry-Repository oder 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. 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 Gewähren von Artifact Registry-Rollen finden Sie unter Konfigurieren Sie Rollen und Berechtigungen.

Beim Repository authentifizieren

Artifact Registry unterstützt dieselben Authentifizierungsmethoden wie Container Registry.

Wenn Sie Docker Credential Helper verwenden:

  • Zur Interaktion mit Artifact Registry-Repositories benötigen Sie Version 2.0 oder höher. Die eigenständige Version ist in GitHub verfügbar.
  • Konfigurieren Sie den Credential Helper mit den Speicherorten von Artifact Registry, die Sie verwenden möchten. Standardmäßig konfiguriert Credential Helper nur den Zugriff auf Container Registry-Hosts.

Weitere Informationen zum Einrichten der Authentifizierung finden Sie unter Authentifizierung für Docker einrichten.

Container aus Container Registry kopieren

Sollten sich Container in Container Registry befinden, die Sie weiterhin in Artifact Registry verwenden möchten, haben Sie mehrere Möglichkeiten zum Kopieren. Eine detaillierte Anleitung finden Sie unter Images aus Container Registry kopieren.

Images hoch- und herunterladen

Die Docker-Befehle, die Sie zum Taggen, Übertragen und Abrufen von Images in Artifact Registry verwenden, ähneln denen, die Sie in Container Registry verwenden. Es gibt zwei Hauptunterschiede:

  • Der Hostname für die Artifact Registry-Docker-Repositories enthält ein Standortpräfix, gefolgt von -docker.pkg.dev. Beispiele sind australia-southeast1-docker.pkg.dev, europe-north1-docker.pkg.dev und europe-docker.pkg.dev.
  • Da Artifact Registry mehrere Docker-Repositories in einem einzelnen Projekt unterstützt, müssen Sie den Repository-Namen in Befehlen angeben.

Mit diesem Befehl wird z. B. in Container Registry das Image my-image in die Registry eu.gcr.io des Projekts my-project verschoben.

docker push eu.gcr.io/my-project/my-image

In Artifact Registry verschiebt dieser Befehl das Image my-image in das regionale Repository europe-north1-docker.pkg.dev im Repository my-repo und im Projekt my-project.

docker push europe-north1-docker.pkg.dev/my-project/my-repo/my-image

Weitere Informationen zum Hoch- und Herunterladen von Images in Artifact Registry finden Sie unter Images hoch- und herunterladen.

Images bereitstellen

Dienstkonten für gängige Google Cloud-Integrationen mit Standardberechtigungen für Repositories im Projekt arbeiten.

Das Erstellen von Images und das Übertragen in ein Repository mit Cloud Build funktioniert im Allgemeinen genauso wie bei Container Registry. Der Hauptunterschied in Artifact Registry besteht darin, dass ein Ziel-Repository vorhanden sein muss, bevor Sie Images per Push übertragen, einschließlich des ersten Images, das Sie übertragen.

Erstellen Sie die benötigten Repositories, bevor Sie Befehle zum Übertragen von Images ausführen, einschließlich des Docker-Befehls docker push und des Cloud Build-Befehls gcloud builds submit.

Cloud Build-Builder werden weiterhin auf gcr.io gehostet. Weitere Informationen finden Sie unter In Cloud Build einbinden.

Weitere Funktionen

In diesem Abschnitt wird die Konfiguration anderer Features beschrieben, die Sie in Container Registry eingerichtet haben.

Artefaktanalyse

Artefaktanalyse unterstützt sowohl Container Registry als auch Artifact Registry. Dokumentation zur Artefaktanalyse umfasst beide Produkte.

  • Beide Produkte verwenden dieselben Artefaktanalyse-APIs. Wenn Sie Artifact Analysis APIs in Container Registry oder Artifact Registry aktivieren, sind die APIs für beide Produkte aktiviert.
  • Beide Produkte verwenden dieselben Pub/Sub-Themen für Benachrichtigungen zur Artefaktanalyse.
  • 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 Scannen.
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.
  • 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 Sicherheitslücken des Betriebssystems für Images in Artifact Registry mit unterstützte Betriebssysteme und Sprachpakete Informationen zu Sicherheitslücken für unterstützte und nicht unterstützte Betriebsarten Systeme.

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.

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.

Dienstperimeter

Mit VPC Service Controls können Sie Sicherheitsperimeter für die Ressourcen Ihrer von Google verwalteten Dienste konfigurieren und die Übertragung von Daten in und aus dem Perimeter steuern.

Eine Anleitung finden Sie unter Repositories in einem Dienstperimeter sichern.

Container Registry-Images bereinigen

Wenn Sie Container Registry nicht mehr verwenden möchten, löschen Sie die verbleibenden Images, indem Sie die Speicher-Buckets für Container Registry löschen.

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 100.000 oder mehr Bilder in einem Bucket im Bulk löschen möchten, Vermeiden Sie die Verwendung der gcloud CLI, da der Löschvorgang lange dauert. abgeschlossen werden muss. Führen Sie den Vorgang stattdessen über die Google Cloud Console aus. Weitere Informationen finden Sie unter Cloud Storage-Objekte im Bulk-Verfahren löschen.

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

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

BUCKET-NAME durch den Container Registry-Speicher ersetzen Bucket-Name. 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

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, die Container Registry API zu deaktivieren 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 einem konfigurierten auch wenn Sie Container Registry derzeit nicht mit diesen Dienstleistungen.

Nächste Schritte