Container Registry-Übersicht

Container Registry ist der Legacy-Dienst zum Speichern privater Container-Images in Google Cloud.

Der Dienst wird eingestellt. Sie können Ihre vorhandenen Images in die Artifact Registry verschieben und weiterhin über die gcr.io-Domain darauf zugreifen. Ab dem 15. Mai 2024 werden in Projekten ohne vorherige Container Registry-Nutzung nur Images für die Domain gcr.io in Artifact Registry gehostet.

Einen Vergleich zwischen Container Registry und Artifact Registry und Informationen zur Umstellung von Container Registry auf Artifact Registry finden Sie unter Von Container Registry wechseln.

Mit Images arbeiten

Dockerhub ist eine beliebte zentrale Registry zum Speichern öffentlicher Docker-Images. Wenn Sie Kontrolle über den Zugriff auf Ihre Images benötigen, müssen Sie eine private Registry wie Artifact Registry oder Container Registry verwenden.

Sie können über sichere HTTPS-Endpunkte auf die Registry zugreifen und Images aus einem beliebigen System, einer VM-Instanz oder Ihrer eigenen Hardware hochladen, herunterladen und verwalten.

• Sie können die Registry in Google Cloud CI/CD-Dienste oder Ihre bestehenden CI/CD-Tools einbinden.
  • Speichern Sie Container-Images aus Cloud Build.
  • Stellen Sie Container Images für Google Cloud-Laufzeiten wie Google Kubernetes Engine, Cloud Run, Compute Engine und die flexible App Engine-Umgebung bereit.
  • Die Identitäts- und Zugriffsverwaltung bietet konsistente Anmeldedaten und Zugriffssteuerung.
• Schützen Sie die Container-Softwarelieferkette.
  • Verwalten Sie Artefaktanalyse Containermetadaten und suchen Sie nach Container-Sicherheitslücken.
  • Erzwingen Sie Bereitstellungsrichtlinien mit Binärautorisierung.
• Schützen Sie die Registry in einem VPC Service Controls-Sicherheitsperimeter.

Registries

Sie können in jedem Google Cloud-Projekt mit Container Registry bis zu vier multiregionale Hosts erstellen. Wenn Sie diskrete Repositories mit separaten Zugriffsrichtlinien erstellen oder Images in Regionen statt in mehreren Regionen speichern möchten, verwenden Sie stattdessen Artifact Registry.

Die Registrys in Container Registry sind nach Host und Projekt-ID benannt. Zur Bearbeitung (wie Upload, Download, Löschen) geben Sie das Image im folgenden Format an:

HOSTNAME/PROJECT-ID/IMAGE:TAG

oder

HOSTNAME/PROJECT-ID/IMAGE@IMAGE-DIGEST

Dabei gilt:

• HOSTNAME ist der Standort, an dem das Image gespeichert wird:

  • gcr.io hostet die Images derzeit in den USA, wobei sich der Standort in Zukunft ändern kann.
  • us.gcr.io hostet die Images ebenfalls in den USA, jedoch in einem von gcr.io getrennten Storage-Bucket.
  • eu.gcr.io hostet die Bilder in Mitgliedsstaaten der Europäischen Union.
  • asia.gcr.io hostet die Images in Asien.

  Diese Standorte entsprechen den Multiregionen für Storage-Buckets von Cloud Storage. Wenn Sie ein Image in eine Registry mit einem neuen Hostnamen hochladen, erstellt Container Registry einen Storage-Bucket in der angegebenen Multiregion. Dieser Bucket wird als Speicher für die Registry verwendet. Innerhalb eines Projekts teilen sich alle Registrys mit demselben Hostnamen einen Storage-Bucket.

• PROJECT-ID ist Ihre Google Cloud Console Projekt-ID. Wenn die Projekt-ID einen Doppelpunkt (:) enthält, finden Sie weitere Informationen unter Auf Domains beschränkte Projekte.

• IMAGE ist der Image-Name. Dieser kann vom lokalen Image-Namen abweichen. In der Google Cloud Console werden die Registrys des Projekts nach dem Image-Namen aufgelistet. Jedes Repository kann mehrere Images mit demselben Namen enthalten. Beispiel: mehrere Versionen des Images "my-image".

• Durch Hinzufügen von :TAG oder @IMAGE-DIGEST am Ende des Namens können Sie eine bestimmte Version des Images angeben, was jedoch optional ist. Wenn Sie weder ein Tag noch einen Digest angeben, sucht Container Registry nach dem Image mit dem Standard-Tag latest. Siehe Image-Versionen innerhalb einer Registry weiter unten.

Für das Image my-image in der Registry gcr.io/PROJECT-ID verwenden Sie dieses Format, um ein Image per Push zu übertragen oder abzurufen:

gcr.io/PROJECT-ID/my-image:tag1

Dabei ist PROJECT-ID Ihre Google Cloud Console Projekt-ID.

Achtung: Verwenden Sie nur Registry-Befehle, um mit Ihren gespeicherten Images zu arbeiten. Vermeiden Sie neben der Konfiguration der Zugriffssteuerung das direkte Konfigurieren oder Bearbeiten von Objekten in Cloud Storage-Storage-Buckets, die von Container Registry verwendet werden. Einige Cloud Storage-Features wie Berechtigungen auf Objektebene und Aufbewahrungsrichtlinien werden nicht unterstützt. Wenn diese Features konfiguriert sind, werden sie möglicherweise ignoriert oder Probleme verursachen.

Images mit Repositories organisieren

Sie können verwandte Images in einem Repository innerhalb einer Registry gruppieren. Wenn Sie ein Image taggen, per Push übertragen oder abrufen, geben Sie den Repository-Namen unter dem Projekt im Imagepfad an.

In Container Registry sind Repositories eine Organisationshilfe. Sie fungieren wie logische Ordner im Image-Pfad, spiegeln jedoch nicht die tatsächliche Dateisystemstruktur wider und unterstützen keine detailliertere Zugriffssteuerung.

Betrachten Sie die folgenden Images, die im Host us.gcr.io im Projekt builds gespeichert sind:

us.gcr.io/builds/product1/dev/product1-app:beta-2.0
us.gcr.io/builds/product1/stable/product1:1.0
us.gcr.io/builds/product2/dev/product2:alpha
us.gcr.io/builds/product2/stable/product2:1.0

Wenn ein Nutzer Schreibzugriff auf den Host us.gcr.io im builds-Projekt hat, hat er Schreibzugriff auf jeden Pfad unter us.gcr.io/builds, da sich alle Images im selben Storage-Bucket befinden und Sie können den Zugriff nicht auf Repository- oder Image-Ebene einschränken.

Wenn Sie eine detailliertere Zugriffssteuerung benötigen, können Sie stattdessen Artifact Registry verwenden. In Artifact Registry sind Repositories eigenständige Ressourcen, sodass Sie separate IAM-Richtlinien auf Repositories wie us-docker.pkg.dev/builds/product1 und us-docker.pkg.dev/builds/product2 anwenden können.

Image-Versionen innerhalb einer Registry

Eine Registry kann viele Images enthalten und diese können unterschiedliche Versionen haben. Zum Identifizieren einer bestimmten Version des Images in einer Registry können Sie das Tag oder den Digest des Images angeben.

• Tags dienen als Label. Sie können einem Tag mehrere Tags zuweisen. Ein Image kann beispielsweise das Tag v1.5 für eine Versionsnummer und release-candidate haben, um die Bereitschaft für einen endgültigen Test anzugeben.
• Digests werden automatisch generiert, kommen pro Version eines Images immer nur einmal vor und haben die Form @IMAGE-DIGEST, wobei IMAGE-DIGEST der sha256-Hash-Wert des Image-Inhalts ist.

So identifizieren Sie eine bestimmte Version des Images my-image:

• Fügen Sie das Image-Tag hinzu:

  gcr.io/PROJECT-ID/my-image:tag1
  

• oder das Image-Digest:

  gcr.io/PROJECT-ID/my-image@sha256:4d11e24ba8a615cc85a535daa17b47d3c0219f7eeb2b8208896704ad7f88ae2d
  

Dabei ist PROJECT-ID Ihre Google Cloud Console Projekt-ID. Wenn die Projekt-ID einen Doppelpunkt (:) enthält, finden Sie weitere Informationen unter Auf Domains beschränkte Projekte.

In der Google Cloud Console werden die Image-Tags unter Images in der Spalte Tags aufgelistet. Klicken Sie auf eine Image-Version, um sich die Metadaten anzusehen, einschließlich des Image-Digests.

Weitere Informationen zur Bearbeitung von Tags finden Sie unter Images taggen.

Auf Domains beschränkte Projekte

Wenn Ihr Projekt auf Ihre Domain beschränkt ist, enthält die Projekt-ID den Namen der Domain, gefolgt von einem Doppelpunkt (:). Aufgrund der Art und Weise, wie Docker Doppelpunkte behandelt, müssen Sie den Doppelpunkt durch einen Schrägstrich ersetzen, wenn Sie einen Image-Digest in Container Registry angeben. Identifizieren Sie Images in diesen Projekttypen im folgenden Format:

HOSTNAME/[DOMAIN]/[PROJECT]/IMAGE

Das Projekt mit der ID example.com:my-project könnte beispielsweise folgendes Image haben:

gcr.io/example.com/my-project/image-name

Hinweis: Die Beschränkung von Projekten auf eine Domain ist eine Legacy-Funktion. Auf Domains beschränkte Projekte können nicht mehr erstellt werden.

Registry-Namen als URLs

Die URL https://HOSTNAME/PROJECT-ID/IMAGE ist eine URL für ein Image in der Google Cloud Console. Jeder authentifizierte Nutzer, der berechtigt ist, auf den Registry-Host zuzugreifen, kann Links zum Aufrufen aller gespeicherten Images verwenden. Weitere Informationen zum Format des Image-Pfads finden Sie unter Registries.

Die folgenden URLs verweisen beispielsweise auf öffentliche Registries in Google Cloud Console:

• https://gcr.io/google-appengine/python
• https://gcr.io/google-containers/pause

Container-Image-Formate

Container Registry unterstützt die Image-Formate Docker Image Manifest V2 und OCI. Weitere Informationen finden Sie im Artikel über Container-Image-Formate.

Wenn Sie Images und andere Artefakte zentral speichern möchten, sollten Sie Artifact Registry anstelle von Container Registry verwenden.

Zugriffssteuerung

Container Registry speichert Tags und Ebenendateien für Container-Images in einem Cloud Storage-Bucket im selben Projekt wie die Registry. Der Zugriff auf den Bucket wird mithilfe der IAM-Einstellungen (Identity and Access Management) von Cloud Storage konfiguriert.

Ein Nutzer, der Zugriff auf einen Registry-Host hat, kann auf jedes Image im Storage-Bucket des Hosts zugreifen. Wenn Sie eine detailliertere Zugriffssteuerung benötigen, können Sie Artifact Registry verwenden. Artifact Registry bietet Zugriffssteuerung auf Repository-Ebene.

Projektinhaber und Bearbeiter sind standardmäßig zum Hoch- und Herunterladen von Images für den Cloud Registry-Bucket dieses Projekts berechtigt. Projektbetrachter haben nur die Berechtigung zum Herunterladen.

Weitere Informationen zu Container Registry-Berechtigungen finden Sie unter Zugriffssteuerung konfigurieren.

Unter Hinweise zu veralteten Versionen für Container Registry finden Sie Informationen zur geplanten Verschiebung von Image-Metadaten aus Cloud Storage in eine leistungsstarke Backend-Datenbank.

Authentication

Bevor Sie Images hoch- oder herunterladen können, müssen Sie die Authentifizierung konfigurieren. Sie können Docker so konfigurieren, dass die Google Cloud CLI zum Authentifizieren von Anfragen an Container Registry verwendet wird. Container Registry unterstützt auch erweiterte Authentifizierungsmethoden mit Zugriffstoken oder JSON-Schlüsseldateien.

Docker Credential Helper

Docker muss zum Hoch- und Herunterladen von Images Zugriff auf Container Registry haben. Mithilfe des Befehlszeilentools Docker Credential Helper können Sie Ihre Container Registry-Anmeldedaten für die Verwendung mit Docker konfigurieren.

Credential Helper ruft Ihre Container Registry-Anmeldedaten ab – entweder automatisch oder von einem mit dem Flag --token-source angegebenen Speicherort – und schreibt sie in die Konfigurationsdatei von Docker. Auf diese Weise können Sie das Docker-Befehlszeilentool docker verwenden, um direkt mit Container Registry zu interagieren.

Weitere Informationen finden Sie unter Erweiterte Authentifizierung.

Container Registry-Dienstkonto

Wenn Sie die Container Registry API aktivieren, fügt Container Registry Ihrem Projekt ein Dienstkonto hinzu. Dieses Dienstkonto hat folgende ID:

service-[PROJECT_NUMBER]@containerregistry.iam.gserviceaccount.com

Das Container Registry-Dienstkonto dient ausschließlich dem Zweck, dass Container Registry Ihr Projekt bearbeiten kann. Google verwaltet zwar dieses Konto, das Konto ist aber für Ihr Projekt spezifisch.

Wenn Sie dieses Dienstkonto löschen oder die damit verbundenen Berechtigungen ändern, werden einige Funktionen von Container Registry nicht mehr richtig funktionieren. Löschen Sie das Konto nicht und ändern Sie keine Rollen.

Weitere Informationen zu diesem Dienstkonto und den zugehörigen Berechtigungen finden Sie unter Container Registry-Dienstkonto.

Cache zum Abrufen

Die Registry mirror.gcr.io speichert häufig angeforderte öffentliche Images von Docker Hub

Die Verwendung von im Cache gespeicherten Images kann das Abrufen aus Docker Hub beschleunigen. Ihr Client prüft immer, ob eine im Cache gespeicherte Kopie eines Docker Hub-Images vorhanden ist, bevor er versucht, es direkt aus Docker Hub abzurufen.

Weitere Informationen finden Sie unter Im Cache gespeicherte Docker Hub-Images abrufen.

Mitteilungen

Sie können Pub/Sub verwenden, um Benachrichtigungen über Änderungen an Ihren Container-Images zu erhalten.

Weitere Informationen finden Sie unter Pub/Sub-Benachrichtigungen konfigurieren.

Container Registry mit Google Cloud verwenden

Compute Engine-Instanzen und Google Kubernetes Engine-Cluster können Container Registry-Images basierend auf Cloud Storage-Bereichen auf den Instanzen übertragen und abrufen. Weitere Informationen finden Sie unter Container Registry mit Google Cloud verwenden.

In der Container Registry gespeicherte Images können über die flexible App Engine-Umgebung bereitgestellt werden.

Einbindung von Continuous Delivery-Tools

Container Registry funktioniert mit gängigen Continuous-Integration- und Continuous-Delivery-Systemen wie Cloud Build und Tools von Drittanbietern wie Jenkins.

Container Registry lässt sich nahtlos in Google Cloud-Dienste einbinden. Beispielsweise kann Cloud Build Images standardmäßig an Container Registry-Hosts im selben Projekt übertragen und daraus abrufen. Laufzeitumgebungen wie Google Kubernetes Engine und Cloud Run können auch standardmäßig Images von Registry-Hosts im selben Projekt abrufen.

Alternativ können Sie Tools von Drittanbietern wie Jenkins zum Erstellen, Abrufen und Übertragen Ihrer Images verwenden. Wenn Sie ein Drittanbietertool verwenden, müssen Sie Berechtigungen und die Authentifizierung für das Konto konfigurieren, das im Auftrag des Containers mit Container Registry im Rahmen des Tools interagiert.

Beispiele für Integrationen finden Sie in den technischen Leitfäden von Google Cloud, die Container Registry enthalten.