Von Container Registry wechseln

Artifact Registry ist der empfohlene Dienst für die Speicherung und Verwaltung von Container-Images in Google Cloud. Als vollständig verwalteter Dienst, der sowohl Container-Images als auch Artefakte ohne Container unterstützt, erweitert Artifact Registry die Möglichkeiten von Container Registry.

Wenn Sie derzeit Container Registry verwenden, nutzen Sie die Informationen auf dieser Seite, um mehr über die Umstellung auf Artifact Registry zu erfahren. Obwohl Container Registry weiterhin als Google Enterprise API verfügbar ist und unterstützt wird, sind neue Funktionen nur in Artifact Registry verfügbar. Container Registry erhält nur kritische Sicherheitsupdates.

Übersicht

Artifact Registry bietet dieselben Features zur Containerverwaltung wie Container Registry, hat aber auch zusätzliche Features und Vorteile:

Zusätzliche Artefaktformate

Sie können Repositories für die folgenden Artefaktformate erstellen:

Container-Images: Docker, Helm
Sprachpakete: Java, Node.js, Python
Betriebssystempakete: Debian, RPM

Regionale Repositorys

Container Registry bietet nur multiregionale Hosts für die Registrierung. Artifact Registry bietet sowohl regionale als auch multiregionale Registrierungshosts.

Mehrere separate Repositories an einem Ort

In Container Registry können Sie nur einen Registry-Host an einem multiregionalen Standort erstellen und alle Repositories in der Registry teilen sich denselben Storage-Bucket. In Artifact Registry ist jedes Repository eine separate Ressource. Sie können für jedes Repository andere Labels und Richtlinien für die Identitäts- und Zugriffsverwaltung verwenden.

Berechtigungen auf Repository-Ebene

In Container Registry erteilen Sie Berechtigungen für jeden multiregionalen Registry-Host. Sie können keine separaten Berechtigungen auf Repository-Ebene anwenden. Artifact Registry bietet Zugriff auf Repository-Ebene.

Artifact Registry-IAM-Rollen

In Container Registry verwenden Sie Cloud Storage-Rollen, um den Zugriff zu steuern. Außerdem müssen Sie ein Image an einen Registry-Host senden, bevor Sie Berechtigungen für den Host konfigurieren können. In Artifact Registry verwenden Sie Artifact Registry-Rollen, um Zugriff zu gewähren. Es gibt eine klare Trennung zwischen den Rollen „Repository-Administrator“ und „Repository-Nutzer“.

Google Kubernetes Engine-Image-Streaming

GKE kann Daten aus zulässigen Images wie von Ihren Anwendungen angefordert streamen, sodass Arbeitslasten initialisiert werden können, ohne auf den Download des gesamten Images warten zu müssen. Image-Streaming ermöglicht schnelleres Autoscaling, einen schnelleren Pod-Start und eine reduzierte Latenz beim Abrufen großer Images.

Quellbereitstellung von Cloud Run

Mit einem einzigen Google Cloud CLI-Befehl können Sie neue Dienste und neue Überarbeitungen direkt aus Quellcode in Cloud Run bereitstellen. Bei der Quellbereitstellung wird ein Container-Image aus Ihrem Code erstellt, in Artifact Registry gespeichert und in Cloud Run bereitgestellt.

Abwärtskompatibilität und Koexistenz

Sie können Artifact Registry und Container Registry im selben Projekt verwenden. Wenn Sie eine Liste von Repositories mit gcloud oder der Google Cloud Console ansehen, listet Artifact Registry auch Container Registry-Repositories im selben Projekt auf.

Sie können Ihre Container und Ihre Automatisierung auf Artifact Registry umstellen, um die erweiterten Funktionen von Artifact Registry zu nutzen.

Umstellungsoptionen

Sie haben folgende Möglichkeiten, zu Artifact Registry zu wechseln:

Standard-Repositories (empfohlen)

Reguläre Artifact Registry-Repositories, die alle Features unterstützen und vollständig von vorhandenen Container Registry-Hosts unabhängig sind.

Repositories mit Unterstützung der gcr.io-Domain

Spezielle Repositories, die gcr.io-Hostnamen in Container Registry zugeordnet sind. Diese Repositories unterstützen die Weiterleitung von Traffic von gcr.io-Hostnamen zu den entsprechenden gcr.io-Repositories in Ihrem Projekt.

Für diese Repositories gelten einige Funktionseinschränkungen. Wenn Sie jedoch viele Tools, Skripts oder Code mit gcr.io-Referenzen haben, ist für die Umstellung auf Artifact Registry möglicherweise ein taktischerer Ansatz erforderlich.

Beide Arten von Repositories können gleichzeitig vorhanden sein, damit Sie schrittweise wechseln können. Beispiel:

Sie können gcr.io-Repositories in Artifact Registry erstellen, um die vorhandene Container Registry-Einrichtung zu übertragen und Standard-Repositories für neue Aufgaben zu erstellen.
Bei der Umstellung können Sie einen mehrstufigen Ansatz wählen. Wechseln Sie zu gcr.io-Repositories in Artifact Registry und stellen Sie dann nach und nach auf Standard-Repositories um, während Sie Ihre Automatisierung aktualisieren, um Artifact Registry-Repository- und -Image-Pfade vollständig zu unterstützen.

Repositories einrichten

In Artifact Registry müssen Sie Repositories erstellen, bevor Sie Images per Push übertragen können. Ein wichtiger Teil der Umstellung auf Artifact Registry ist das Einrichten von Artifact Registry-Repositories und die Integration in Ihre CI/CD-Automatisierung.

Um die Flexibilität zu erhöhen, gibt es einige Änderungen in der Darstellung von Repositories von Artifact Registry.

Container Registry

Jeder multiregionale Standort ist einem einzelnen Storage-Bucket zugeordnet. Das Organisieren Ihrer Images in Repositories unter einem Hostnamen ist optional. Im folgenden Beispiel wird das Image webapp an drei Speicherorten angezeigt:

us.gcr.io/my-project/webapp
us.gcr.io/my-project/team1/webapp
us.gcr.io/my-project/team2/webapp

Repositories dienen nur zur Organisation und schränken den Zugriff nicht ein. Jeder Nutzer mit Zugriff auf den Storage-Bucket für us.gcr.io in diesem Projekt kann auf alle Versionen des Container-Images webapp zugreifen.

Artifact Registry

Jedes Repository ist eine separate Ressource in Ihrem Projekt. Da jedes Repository eine eindeutige Ressource ist, haben Sie folgende Möglichkeiten:

Jedem Repository einen Namen, eine Beschreibung und Labels zuweisen
Mehrere Repositories am selben Speicherort erstellen
Repository-spezifische Berechtigungen konfigurieren

Außerdem kann der Speicherort eines Repositorys eine Region oder mehrere Regionen sein.

Mit diesen Änderungen haben Sie mehr Kontrolle über Ihre Repositories. Wenn Sie beispielsweise Teams in São Paulo und Sydney haben, können Sie für jedes Team in einer Region, die geografisch näher am nächsten multiregionalen Standort liegt, ein Repository erstellen.

southamerica-east1-docker.pkg.dev/my-project/team1/webapp
australia-southeast1-docker.pkg.dev/my-project/team2/webapp

Sie können dann jedem Team nur die Berechtigungen für das Team-Repository erteilen.

Eine Anleitung zum Wechsel zu Artifact Registry finden Sie im Einrichtungsleitfaden.

Images hoch- und herunterladen

Mit den folgenden Informationen können Sie vorhandene Konfigurationen, Befehle und Dokumentationen für Container Registry anpassen und Images erstellen, per Push übertragen, abrufen und bereitstellen.

Funktionsvergleich

In diesem Abschnitt werden Änderungen und Verbesserungen der Container Registry-Features zusammengefasst.

Funktion	Container Registry	Artifact Registry
Unterstützte Formate	Nur Container-Images	Mehrere Artefakt-Formate, einschließlich Container-Images, Sprachpakete und Betriebssystempakete
Repositories	Erstellung: Erstellt ein Repository automatisch an einem multiregionalen Standort, wenn Sie noch kein Image dorthin hochgeladen haben. Standort: Nur multiregionale Repositories. Organisation – Alle Repositories auf demselben multiregionalen Host in einem Google Cloud-Projekt verwenden einen einzelnen Storage-Bucket. Zugriffssteuerung: Sie können Berechtigungen auf Projektebene oder im Storage-Bucket für jeden multiregionalen Host erteilen.	Erstellung: Sie müssen ein Repository erstellen, bevor Sie Images per Push übertragen. Standort: Erstellen Sie Standard-Repositories in einer mehreren Region oder Region. Beispielsweise ist Asien die nächstgelegene Multiregion. Mit regionaler Unterstützung können Sie ein Repository im Rechenzentrum von Sydney erstellen. Organisation: Sie können mehrere, separate Repositories in jeder Region oder Mehrfachregion erstellen. Wenden Sie Labels an, um sie nach Team, Entwicklungsphase oder anderen Kategorien zu gruppieren. Zugriffssteuerung: Sie können Berechtigungen für das Projekt oder für einzelne Repositories erteilen.
Hostnamen	Hosts sind in der Domain `gcr.io`.	Hosts sind in der Domain `pkg.dev`. Weitere Informationen zum Namensformat finden Sie unter Repository- und Artefaktnamen. Mit der Unterstützung von gcr.io-Domains können Sie Traffic von Ihren `gcr.io>`-Hosts automatisch an die entsprechenden Artifact Registry-Repositories im selben Projekt weiterleiten.
Berechtigungen	Gewähren Sie Zugriff mit Cloud Storage-Berechtigungen. Sie können den Zugriff auf alle Images beschränken, die in mehreren Regionen gespeichert sind, aber nicht auf einzelne Repositories. Sie können beispielsweise den Zugriff auf `us.gcr.io` im Projekt `my-project` einschränken, aber keine Berechtigungen für Images unter `us.gcr.io/my-project/team1` und `us.gcr.io/my-project/team2` gewähren.	Gewähren Sie den Zugriff über die Artifact Registry-Berechtigungen. Sie können den Zugriff auf einzelne Repositories beschränken. Sie können beispielsweise den Zugriff auf Images in `us-docker.pkg.dev/my-project/team1` und `us-docker.pkg.dev/my-project/team2` separat steuern.
Authentifizierung	Bietet mehrere Authentifizierungsmethoden zum Übertragen und Abrufen von Images mit dem Client eines Drittanbieters	Artifact Registry unterstützt dieselben Authentifizierungsmethoden wie Container Registry. Weitere Informationen finden Sie unter Authentifizierung für Docker einrichten. Wenn Sie Docker Credential Helper verwenden: Version 2.0.0 oder höher ist erforderlich. Docker-Client-Versionen vor Version 18.03 werden nicht mehr unterstützt. Sie müssen die Artifact Registry-Standorte hinzufügen, die Sie in der Konfiguration von Credential Helper verwenden werden.
Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK)	Verschlüsseln Sie Ihre der Storage-Buckets, die Ihre Images enthalten, mit CMEK.	Verschlüsseln Sie einzelne Repositories mit CMEK.
Über die Google Cloud Console	Container Registry-Images im Bereich Container Registry der Google Cloud Console ansehen und verwalten	Eine Liste Ihrer Artifact Registry- und Container Registry-Repositories finden Sie in der Google Cloud Console im Abschnitt Artifact Registry. Sie können die Artifact Registry-Repositories und -Images von dieser Seite aus verwalten. Wenn Sie auf ein Container Registry-Repository klicken, werden Sie zur Liste der Images im Abschnitt Container Registry der Google Cloud Console weitergeleitet.
gcloud- und API-Befehle verwenden	Verwendet gcloud container images-Befehle. Befehle unterstützen verkürzte Digests. Wenn Sie den vollständigen Digest-String nicht angeben, versucht Container Registry anhand des unvollständigen Strings, das richtige Image zu finden.	Verwendet die Befehle gcloudArtefakte-Docker. Gekürzte Digests werden von Befehlen nicht unterstützt. Einen Vergleich der gcloud-Befehle von Container Registry und Artifact Registry finden Sie unter gcloud command comparison. Artifact Registry enthält auch eine API zum Verwalten von Repositories und Artefakten in allen Formaten.
Pub/Sub-Benachrichtigungen	Änderungen am Thema `gcr` veröffentlichen.	Änderungen am Thema `gcr` veröffentlichen. Wenn Sie Repositories im selben Projekt wie Ihren vorhandenen Container Registry-Dienst erstellen, funktioniert Ihre vorhandene Pub/Sub-Konfiguration automatisch. Weitere Informationen finden Sie unter Pub/Sub-Benachrichtigungen konfigurieren.
Im Cache gespeicherte Docker Hub-Images	Speichert die am häufigsten angeforderten Docker Hub-Images auf `mirror.gcr.io` im Cache.	`mirror.gcr.io` speichert weiterhin häufig angeforderte Images vom Docker Hub im Cache.
VPC Service Controls	Sie können einem Dienstperimeter Container Registry hinzufügen.	Sie können einem Dienstperimeter eine Artifact Registry hinzufügen.
Metadatenspeicher und -analyse mit Container Analysis	Scans auf Sicherheitslücken des Betriebssystems und der Sprachpakete mit On-Demand-Scans in Images mit einem unterstützten Betriebssystem. Beim automatischen Scan werden nur Informationen zu Sicherheitslücken des Betriebssystems zurückgegeben. Weitere Informationen zu Scantypen On-Demand-Scan Der Google Cloud CLI-Befehl gcloud Artefakte Docker-Images-Scan scannt auf Sicherheitslücken in lokalen Images oder Images in Container Registry. Der Google Cloud CLI-Befehl gcloud Artefakte Docker-Images list-vulnerabilities gibt Ergebnisse zum Scannen auf Sicherheitslücken zurück. Scans geben Informationen zu Sicherheitslücken von Betriebssystem und Sprache für Images in Container Registry mit unterstützten Betriebssystemen zurück. Automatisches Scannen Der Google Cloud CLI-Befehl gcloud container images enthält Flags zum Aufrufen von Scanergebnissen, einschließlich Sicherheitslücken und anderer Metadaten. Scans geben nur Informationen zu Sicherheitslücken des Betriebssystems für Images in Container Registry mit unterstützten Betriebssystemen zurück.	Scans auf Sicherheitslücken des Betriebssystems und der Sprachpakete mit On-Demand- und automatischen Scans. Weitere Informationen zu Scantypen On-Demand-Scan Der Google Cloud CLI-Befehl gcloud Artefakte Docker-Scans sucht nach Sicherheitslücken in lokalen Images oder Images in der Artifact Registry. Der Google Cloud CLI-Befehl gcloud Artefakte Docker-Images list-vulnerabilities gibt Ergebnisse zum Scannen auf Sicherheitslücken zurück. Scans geben Informationen zu Sicherheitslücken von Betriebssystem und Sprache für Images in Artifact Registry mit unterstützten Betriebssystemen zurück. Automatisches Scannen Der Google Cloud CLI-Befehl gcloudArtefakte 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ützten Betriebssystemen und Informationen zu Sicherheitslücken im Sprachpaket für unterstützte und nicht unterstützte Betriebssysteme zurück.
Von Google bereitgestellte Images	Von Google bereitgestellte Images werden auf `gcr.io` gehostet. Hier einige Beispiele: Im Cache gespeicherte Images auf `mirror.gcr.io` Cloud Build-Builder Basis-Images	Von Google bereitgestellte Images sind weiterhin auf `gcr.io` verfügbar.
Image-Streaming	Nicht verfügbar	GKE kann Daten aus zulässigen Images in Artifact Registry streamen. Dies ermöglicht ein schnelleres Autoscaling, einen schnelleren Pod-Start und eine reduzierte Latenz beim Abrufen großer Images.
Cloud Run-Quellbereitstellung	Nicht verfügbar	Bei der Quellbereitstellung können Sie mit einem einzigen gcloud-Befehl ein Container-Image aus Ihrem Quellcode erstellen, das Image in Artifact Registry speichern und in Cloud Run bereitstellen.
Preise	Die Container Registry-Preise basieren auf der Nutzung von Cloud Storage, einschließlich Speicher und ausgehendem Netzwerktraffic.	Artifact Registry hat eigene Preise basierend auf Speicher und ausgehenden Netzwerktraffic.