Umstellung auf Standard-Repositories

Wenn Sie derzeit Container Registry zum Verwalten Ihrer Container-Images verwenden, wird auf dieser Seite erläutert, wie Sie ein standardmäßiges Artifact Registry-Repository einrichten und wie sich die Verwendung von Repositories von der Verwendung von Container Registry unterscheidet.

Diese Anleitung richtet sich hauptsächlich an Repository-Administratoren. Informationen dazu, wie sich das Erstellen, Übertragen, Abrufen und Bereitstellen von Images geändert hat, finden Sie in den folgenden Informationen:

Hinweise

Aktivieren Sie die Artifact Registry API über die Google Cloud Console oder mit dem folgenden Befehl:
```
gcloud services enable artifactregistry.googleapis.com
```
Installieren Sie die gcloud CLI, falls sie noch nicht installiert ist. Führen Sie bei einer vorhandenen Installation den folgenden Befehl aus, um Komponenten auf die neueste Version zu aktualisieren:
```
gcloud components update
```
Informieren Sie sich vor der Umstellung über die pricing.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Google Cloud-Projekt zu gewähren, 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 wurde, und verwalten sie: Storage-Administrator (roles/storage.admin)
So gewähren Sie Zugriff auf das Repository auf Projektebene: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) oder eine Rolle mit entsprechenden Berechtigungen wie Ordneradministrator (roles/resourcemanager.folderAdmin) oder Organisationsadministrator (roles/resourcemanager.organizationAdmin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

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

Überblick

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 beide Dienste während der Umstellung auf Artifact Registry verwenden, sodass Sie die Einrichtungsschritte schrittweise ausführen 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 außerdem gcr.io-Repositories. Diese Repositories können gcr.io-Traffic von Ihren vorhandenen Registries an entsprechende Artifact Registry-Repositories weiterleiten. Sie bieten eine gewisse Abwärtskompatibilität mit Container Registry, haben aber auch einige Einschränkungen für Funktionen. Wenn Sie jedoch viele Toolkonfigurationen, Skripts oder Code mit gcr.io-Referenzen haben, ist möglicherweise ein taktischer Ansatz für die Umstellung auf Artifact Registry erforderlich. Eine entsprechende Entscheidung finden Sie in der Dokumentation zur Umstellung für Repositories mit Unterstützung für gcr.io-Domains.

Umstellungsschritte

In diesem Leitfaden werden die folgenden Schritte beschrieben:

Erstellen Sie ein Docker-Repository für Ihre Container. Sie müssen ein Repository erstellen, bevor Sie Images per Push übertragen können.
Gewähren Sie Berechtigungen für das Repository.
Konfigurieren Sie die Authentifizierung, damit Sie eine Verbindung zu Ihrem neuen Repository herstellen können.
Kopieren Sie bei Bedarf Images aus Container Registry, die Sie in Ihrem neuen Repository verwenden möchten.
Erteilen Sie einen Push- und Pull-Befehl für Container
Stellen Sie Images in einer Laufzeitumgebung bereit
Konfigurieren Sie zusätzliche Features.
Bereinigen Sie Images in Container Registry, wenn die Umstellung 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

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

Mit dem Tool für die Rollenzuordnung lassen sich vorhandene Berechtigungen, die für Storage-Buckets gewährt wurden, schnell den vorgeschlagenen Artifact Registry-Rollen zuordnen.

Alternativ können Sie in der Google Cloud Console eine Liste der Hauptkonten mit Zugriff auf Storage-Buckets aufrufen.

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

Buckets aufrufen
Klicken Sie auf den Storage-Bucket für den Registry-Host, den Sie ansehen möchten. In den Bucket-Namen ist PROJECT-ID 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
Klicken Sie auf den Tab Berechtigungen.
Klicken Sie auf den Tab „Berechtigungen“ und dann auf den Untertab Nach Rolle anzeigen.
Maximieren Sie eine Rolle, um die Hauptkonten mit dieser Rolle anzusehen.

Die Liste enthält IAM-Rollen, die direkt für den Bucket zugewiesen wurden, und Rollen, die aus dem übergeordneten Projekt übernommen wurden. Je nach Rolle können Sie die am besten geeignete Artifact Registry-Rolle zum Gewähren auswählen.

Cloud Storage und einfache Rollen

Gewähren Sie Nutzern und Dienstkonten, die derzeit auf Container Registry zugreifen, Zugriff auf Artifact Registry-Repositories. Prüfen Sie für Cloud Storage-Rollen, die vom übergeordneten Projekt übernommen wurden, ob das Hauptkonto derzeit Container Registry verwendet. 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 vorhanden waren, haben eingeschränkten Zugriff auf Storage-Buckets. Sie gewähren nicht grundsätzlich alle Zugriffsrechte für Cloud Storage-Ressourcen, die aus ihrem Namen hervorgeht, und bieten nicht 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 Tabelle für die Rollenzuordnung, um die richtigen Rollen zuzuweisen, wenn der Artifact Registry-Zugriff angemessen ist.

In der folgenden Tabelle werden Artifact Registry-Rollen basierend auf den Berechtigungen zugeordnet, die von vordefinierten Cloud Storage-Rollen für den Container Registry-Zugriff gewährt werden. Artifact Registry-Rollen bieten eine zusätzliche Trennung von Berechtigungen, die in den vordefinierten Cloud Storage-Rollen nicht verfügbar ist.

Erforderlicher Zugriff	Aktuelle Rolle	Artifact Registry-Rolle	Wo kann die Rolle gewährt werden?
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 übertragen und abrufen (Lese- und Schreibzugriff)	Autor alter Storage-Buckets (`roles/storage.legacyBucketWriter`)	Artifact Registry-Autor (`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 werden eigene Rollen auf Projektebene gewährt. 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 Ihr vorhandener Container Registry-Dienst ausführen.

Weitere Informationen zu den Berechtigungen in Dienst-Agent-Rollen finden Sie in der Referenz zu Dienst-Agent-Rollen.

Benutzerdefinierte Rollen

Die Tabelle für die Rollenzuordnung hilft Ihnen bei der Entscheidung, welche Rolle Nutzern oder Dienstkonten je nach der benötigten Zugriffsebene zugeteilt werden soll.

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

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 ausführliche Anleitung finden Sie unter Images aus Container Registry kopieren.

Images hoch- und abrufen

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 werden mit Standardberechtigungen für Repositories im selben Projekt konfiguriert.

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.

Sonstige Features

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. Die Dokumentation zur Artefaktanalyse umfasst beide Produkte.

Beide Produkte verwenden dieselben Artifact Analysis APIs. Wenn Sie Artifact Analysis APIs in Container Registry oder Artifact Registry aktivieren, werden die APIs für beide Produkte aktiviert.
Beide Produkte verwenden dieselben Pub/Sub-Themen für Artefaktanalyse-Benachrichtigungen.
Sie können weiterhin die Befehle gcloud container images verwenden, um Hinweise und Vorkommen aufzulisten, die mit gcr.io-Image-Pfaden verknüpft sind.

Container Registry	Artifact Registry
Scannt mit On-Demand-Scans nach Betriebssystem- und Sprachpaket-Sicherheitslücken in Images mit unterstütztem Betriebssystem. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken des Betriebssystems zurückgegeben. Weitere Informationen zu den Scantypen On-Demand-Scans Der Google Cloud CLI-Befehl gcloud bias docker images scan scannt lokale Images oder Images in Container Registry nach Sicherheitslücken. Der Google Cloud CLI-Befehl gcloudArtifact docker images list-vulnerabilities gibt Ergebnisse aus Scans auf Sicherheitslücken zurück. Scans geben Informationen zu Sicherheitslücken von Betriebssystem- und Sprachpaketen für Images in Container Registry mit unterstützten Betriebssystemen zurück. Automatischer Scan Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten. Scans geben nur Informationen zu Sicherheitslücken des Betriebssystems in Images in Container Registry mit unterstützten Betriebssystemen zurück.	Scannt sowohl on demand als auch automatisch nach Sicherheitslücken in Betriebssystem- und Sprachpaketen. Weitere Informationen zu den Scantypen On-Demand-Scans Mit dem Google Cloud CLI-Befehl gcloud bias docker images scan werden lokale Images oder Images in Artifact Registry nach Sicherheitslücken gescannt. Der Google Cloud CLI-Befehl gcloudArtifact docker images list-vulnerabilities gibt Ergebnisse aus Scans auf Sicherheitslücken zurück. Scans geben Informationen zu Sicherheitslücken von Betriebssystem- und Sprachpaketen für Images in Artifact Registry mit unterstützten Betriebssystemen zurück. Automatischer Scan Der Google Cloud CLI-Befehl gcloud Artifact docker images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten. Scans geben Informationen zu Sicherheitslücken des Betriebssystems in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken von Sprachpaketen für unterstützte und nicht unterstützte Betriebssysteme zurück.

Container Registry

Artifact Registry

Scannt mit On-Demand-Scans nach Betriebssystem- und Sprachpaket-Sicherheitslücken in Images mit unterstütztem Betriebssystem. Beim automatischen Scannen werden nur Informationen zu Sicherheitslücken des Betriebssystems zurückgegeben. Weitere Informationen zu den Scantypen

On-Demand-Scans

Der Google Cloud CLI-Befehl gcloud bias docker images scan scannt lokale Images oder Images in Container Registry nach Sicherheitslücken.
Der Google Cloud CLI-Befehl gcloudArtifact docker images list-vulnerabilities gibt Ergebnisse aus Scans auf Sicherheitslücken zurück.
Scans geben Informationen zu Sicherheitslücken von Betriebssystem- und Sprachpaketen für Images in Container Registry mit unterstützten Betriebssystemen zurück.

Automatischer Scan

Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
Scans geben nur Informationen zu Sicherheitslücken des Betriebssystems in Images in Container Registry mit unterstützten Betriebssystemen zurück.

Scannt sowohl on demand als auch automatisch nach Sicherheitslücken in Betriebssystem- und Sprachpaketen. Weitere Informationen zu den Scantypen

On-Demand-Scans

Mit dem Google Cloud CLI-Befehl gcloud bias docker images scan werden lokale Images oder Images in Artifact Registry nach Sicherheitslücken gescannt.
Der Google Cloud CLI-Befehl gcloudArtifact docker images list-vulnerabilities gibt Ergebnisse aus Scans auf Sicherheitslücken zurück.
Scans geben Informationen zu Sicherheitslücken von Betriebssystem- und Sprachpaketen für Images in Artifact Registry mit unterstützten Betriebssystemen zurück.

Automatischer Scan

Der Google Cloud CLI-Befehl gcloud Artifact docker images enthält Flags zum Ansehen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten.
Scans geben Informationen zu Sicherheitslücken des Betriebssystems in Artifact Registry mit unterstützten Betriebssystemen und Informationen zu Sicherheitslücken von Sprachpaketen für unterstützte und 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.

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. Dazu löschen Sie die Storage-Buckets für Container Registry.

So löschen Sie jeden Container Registry-Storage-Bucket:

Console

Rufen Sie in der Google Cloud Console die Seite „Cloud Storage“ auf.
Wählen Sie den zu löschenden Storage-Bucket aus. In den Bucket-Namen ist PROJECT-ID 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
Klicken Sie auf Löschen. Ein Bestätigungsdialogfeld wird angezeigt.
Geben Sie den Bucket-Namen ein und klicken Sie auf Löschen, um das Löschen zu bestätigen.

gsutil

Wenn Sie hunderttausend Bilder in einem Bucket im Bulk löschen möchten, verwenden Sie gsutil nicht, da der Löschvorgang sehr lange dauert. Verwenden Sie stattdessen die Google Cloud Console, um den Vorgang auszuführen.

Verwenden Sie zum Löschen eines Buckets den Befehl gsutil rm mit dem Flag -r.

gsutil rm -r gs://BUCKET-NAME

Ersetzen Sie BUCKET-NAME durch den Namen des Container Registry-Storage-Buckets. In den Bucket-Namen ist PROJECT-ID 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 im selben Projekt mit einer konfigurierten Abhängigkeit automatisch alle Dienste deaktiviert, auch wenn Sie Container Registry derzeit nicht mit diesen Diensten verwenden.

Nächste Schritte

Docker-Kurzanleitung ausführen