Diese Seite wurde von der Cloud Translation API übersetzt.

Änderungen für die Erstellung und Bereitstellung in Google Cloud

In diesem Dokument werden die Unterschiede zwischen Container Registry und Artifact Registry beim Erstellen von Container-Images mit Cloud Build und deren Bereitstellung in Google Cloud Laufzeitumgebungen wie Cloud Run oder Google Kubernetes Engine erläutert.

In diesem Leitfaden konzentrieren sich die Vergleiche auf Standard-Artifact Registry-Repositories, also reguläre Artifact Registry-Repositories, die unabhängig von der Container Registry sind und alle Artifact Registry-Funktionen unterstützen. Wenn Ihr Administrator Repositories mit Unterstützung von gcr.io-Domains eingerichtet hat, werden Anfragen an gcr.io-Hostnamen automatisch an ein entsprechendes Artifact Registry-Repository weitergeleitet. Standarddienstkonten mit Zugriff auf Container Registry haben entsprechende Standardberechtigungen für Artifact Registry.

Informationen zu den Unterschieden zwischen Container Registry und Artifact Registry mit einem Docker-Client finden Sie unter Änderungen beim Hoch- und Herunterladen mit Docker.

Anhand dieser Informationen können Sie vorhandene Befehle, Konfigurationen oder Dokumentationen anpassen, die sich auf Container Registry mit Cloud Build beziehen.

Hinweis

In diesem Dokument wird davon ausgegangen, dass Sie Folgendes haben:

Artifact Registry ist in Ihrem Projekt aktiviert.
Sie haben die Cloud Build API und die API für alle anderen Google Cloud Dienste aktiviert, die Sie mit Artifact Registry verwenden.

Änderungen am Workflow

Wenn Sie Cloud Build mit Container Registry im selben Projekt verwenden, sieht der Workflow so aus:

Erstellen, taggen und pushen Sie ein Image mit Cloud Build in das Repository. Verwenden Sie dazu eine Dockerfile- oder eine Build-Konfigurationsdatei.

Im folgenden Beispiel wird das Image my-image erstellt, mit tag1 getaggt und an den Host gcr.io im Projekt my-project gepusht:
```
gcloud builds submit --tag gcr.io/my-project/my-image:tag1
```
Google Cloud Laufzeitumgebungen wie Cloud Run und Google Kubernetes Engine rufen Images aus der Registry ab.

Mit diesem Befehl wird beispielsweise das Image aus dem vorherigen Schritt als my-service in Cloud Run bereitgestellt.
```
gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
```

Der Container Registry-Workflow kombiniert die Aufgaben von Administratoren mit dem Erstellen und Bereitstellen.

Wenn Sie einige Google Cloud APIs aktivieren, wird die Container Registry API automatisch aktiviert. Das bedeutet, dass Nutzer dieser Dienste impliziten Zugriff auf Container Registry im selben Projekt haben. Nutzer, die Builds in Cloud Build ausführen können, können beispielsweise standardmäßig Images in Repositories pushen und Registry-Hosts hinzufügen.
Das Cloud Build-Dienstkonto hat Berechtigungen zum Erstellen von Cloud Storage-Buckets. Das Konto kann also einem Projekt automatisch Container Registry-Hosts hinzufügen, wenn zum ersten Mal ein Image an den Host gepusht wird. Außerdem kann das Konto Storage-Buckets im gesamten Projekt erstellen, lesen und darauf schreiben, einschließlich Buckets, die nicht von Container Registry verwendet werden.

In Artifact Registry gibt es eine klare Trennung zwischen Administrator- und Build-Rollen, die die Schritte im Build- und Bereitstellungsworkflow ändern. Nehmen Sie die folgenden Änderungen vor, um den Container Registry-Workflow für Artifact Registry anzupassen. Zu jedem Schritt gibt es einen Link zu weiteren Informationen zum Ändern des Workflows.

Neu: Aktivieren Sie die Artifact Registry API.

Sie müssen die Artifact Registry API aktivieren. Cloud Build und Laufzeitumgebungen wie Cloud Run und GKE aktivieren die API nicht automatisch für Sie.
Neu: Erstellen Sie das Ziel-Docker-Repository, falls es noch nicht vorhanden ist. Sie müssen ein Repository erstellen, bevor Sie Images per Push übertragen können. Durch das Übertragen eines Images kann die Erstellung eines Repositorys nicht ausgelöst werden und das Cloud Build-Dienstkonto verfügt nicht über die Berechtigungen zum Erstellen von Repositories.
Geändert: Mit Cloud Build können Sie ein Image mit einer Dockerfile oder einer Build-Konfigurationsdatei erstellen, taggen und in das Repository pushen.

Der folgende Beispielbefehl entspricht dem Container Registry-Beispiel, verwendet aber einen Artifact Registry-Repositorypfad für das Image.
```
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```
Geändert: Bereitstellen Sie das Image in einer Google Cloud Laufzeitumgebung wie Cloud Run oder GKE.

Der folgende Beispielbefehl entspricht dem Container Registry-Beispiel, verwendet aber den Pfad zum Artifact Registry-Repository für das Image.
```
gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```

Außerdem werden in Artifact Registry andere Rollen als in Container Registry verwendet, um den Zugriff auf Images zu steuern. In den folgenden Fällen müssen Sie Berechtigungen konfigurieren:

Cloud Build- oder Google Cloud Laufzeitumgebungen befinden sich in einem anderen Projekt als Artifact Registry.
Sie verwenden benutzerdefinierte Dienstkonten für Google Cloud Dienste wie Cloud Build oder GKE anstelle der Standarddienstkonten.
Sie haben anderen Nutzer- oder Dienstkonten Berechtigungen erteilt.

API aktivieren

Wichtige Fakten:

Sie müssen zusätzlich zur API für andere Google Cloud Dienste wie Cloud Build, Cloud Run und GKE die Artifact Registry API aktivieren.

Im folgenden Vergleich wird beschrieben, wie die API für jeden Dienst aktiviert wird:

Container Registry

Wenn Sie die folgenden Google Cloud APIs aktivieren, wird auch die Container Registry API automatisch aktiviert:

Flexible App Engine-Umgebung
Cloud Build
Cloud Run-Funktionen
Cloud Run
Container-Scan oder On-Demand-Scan in der Artefaktanalyse
Google Kubernetes Engine

Mit den Standardberechtigungen haben Nutzer, die Builds in Cloud Build ausführen, Container mit der Artefaktanalyse scannen oder Container inGoogle Cloud -Laufzeiten bereitstellen können, implizit Zugriff auf Images in Container Registry, wenn sich die Registry im selben Projekt befindet.

Artifact Registry

Sie müssen die Artifact Registry API aktivieren. Dienste wie Cloud Build, Cloud Run und GKE aktivieren die Artifact Registry API nicht automatisch.

Mit gcloud können Sie mehrere APIs im selben Projekt aktivieren. Wenn Sie beispielsweise die Cloud Build API und die Artifact Registry API aktivieren möchten, führen Sie den Befehl aus:

gcloud services enable
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com

Registries und Repositories hinzufügen

Wichtige Fakten:

Sie müssen ein Docker-Repository in Artifact Registry erstellen, bevor Sie ein Image dorthin übertragen können.
Container Registry speichert alle Images in einer einzelnen Multiregion im selben Storage-Bucket. In Artifact Registry können Sie mehrere Repositories in derselben Region oder Multiregion mit separaten Zugriffsrichtlinien erstellen.

Im folgenden Vergleich wird die Repository-Einrichtung in den einzelnen Diensten beschrieben:

Container Registry

In Container Registry können Sie Ihrem Projekt bis zu vier Registry-Hosts hinzufügen. Sie fügen einen Registry-Host hinzu, indem Sie das erste Image per Push übertragen.

Wenn Sie Ihrem Projekt eine Registry wie gcr.io hinzufügen möchten, muss ein Konto mit der Rolle „Storage-Administrator“ auf Projektebene ein erstes Image per Push übertragen.

Wenn der Host gcr.io beispielsweise nicht im Projekt my-project vorhanden ist, werden durch das Pushen des Images gcr.io/my-project/my-image:1.0 die folgenden Schritte ausgelöst:
1. Fügen Sie dem Projekt den gcr.io-Host hinzu.
2. Erstellen Sie im Projekt einen Speicher-Bucket für gcr.io.
3. Bild als gcr.io/my-project/my-image:1.0 speichern
Nach diesem ersten Push können Sie anderen Nutzern Berechtigungen für den Speicher-Bucket erteilen.

Standardmäßig hat Cloud Build die erforderlichen Berechtigungen zum Erstellen eines Speicher-Buckets. Daher sind der erste Image-Push und nachfolgende Pushes nicht zu unterscheiden.

Innerhalb eines Projekts speichert ein Registry-Host alle Images im selben Storage-Bucket. Im folgenden Beispiel hat das Projekt my-project zwei Images namens web-app in der Registry gcr.io. Eine befindet sich direkt unter der Projekt-ID my-project. Das andere Bild befindet sich im Repository team1.

gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app

Artifact Registry

Cloud Build hat keine Berechtigungen zum Erstellen eines Standard-Repositories in der Artifact Registry-Domain pkg.dev.

Ein Konto mit der Rolle „Artifact Registry Repository Administrator“ muss das Repository erstellen, bevor Sie Images per Push übertragen können. Anschließend können Sie anderen Nutzern Berechtigungen für das Repository erteilen.

In Artifact Registry ist jedes Repository eine separate Ressource. Daher müssen alle Bildpfade ein Repository enthalten.

Gültige Bildpfade:

us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0

Ungültiger Image-Pfad (enthält kein Repository) :

us-central1-docker.pkg.dev/my-project/web-app:1.0

In den folgenden Beispielen wird gezeigt, in welchen Fällen das Pushen eines Images in ein fehlendes Repository fehlschlägt.

Ein Bild wird an us-central1-docker.pkg.dev/my-project/team1 gesendet, wenn us-central1-docker.pkg.dev/my-project/team1 nicht vorhanden ist.
Ein Bild wird an us-central1-docker.pkg.dev/my-project/team2 gepusht, obwohl us-central1-docker.pkg.dev/my-project/team1 vorhanden ist, aber us-central1-docker.pkg.dev/my-project/team2 nicht.

Berechtigungen gewähren

Wichtige Fakten:

Google Cloud -Dienste haben Lese- oder Schreibzugriff auf Container Registry und Artifact Registry. Das standardmäßige Cloud Build-Dienstkonto kann jedoch keine Standard-Repositories in der Domain pkg.dev erstellen.
Weisen Sie anderen Konten, die auf Artifact Registry zugreifen, die entsprechenden Artifact Registry-Rollen zu.
Container Registry unterstützt die Zugriffssteuerung auf Storage-Bucket-Ebene. Artifact Registry unterstützt die Zugriffssteuerung auf Repository-Ebene.

Im folgenden Vergleich werden die Berechtigungen für die einzelnen Dienste beschrieben:

Container Registry

In Container Registry wird der Zugriff mithilfe der Cloud Storage-Rollen gesteuert. Cloud Build hat die erforderlichen Berechtigungen in der Rolle „Storage-Administrator“, um einem Projekt Container Registry-Hosts hinzuzufügen.

Storage-Objekt-Betrachter auf Ebene des Storage-Buckets: Images von vorhandenen Registry-Hosts im Projekt abrufen (lesen).
Autor alter Storage-Buckets auf Ebene des Storage-Buckets: Images für vorhandene Registry-Hosts im Projekt hochladen (schreiben) und abrufen (lesen).
Storage Admin auf Projektebene: Fügen Sie einem Projekt einen Registry-Host hinzu, indem Sie ein anfängliches Image auf den Host übertragen.

Nach dem ersten Push des Images an eine Registry gewähren Sie anderen Konten, die Zugriff auf den Storage-Bucket benötigen, Cloud Storage-Rollen. Hinweis: Jedes Konto mit allen Berechtigungen der Rolle „Storage Admin“ kann Storage-Buckets und -Objekte im gesamten Projekt lesen, schreiben und löschen.

Berechtigungen für einen Storage-Bucket gelten für alle Repositories in der Registry. So kann beispielsweise jeder Nutzer mit Storage Object Viewer-Berechtigungen für den Bucket für gcr.io/my-project Bilder in allen folgenden Repositories lesen:

gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production

Artifact Registry

Artifact Registry hat eigene Rollen zur Zugriffssteuerung. Diese Rollen sorgen für eine klare Trennung zwischen Administrator- und Repository-Nutzerrollen.

Cloud Build hat Berechtigungen für die Rolle „Artifact Registry Writer“, da nur Images mit Standard-Repositories in der Domain pkg.dev gepusht und gepullt werden müssen.

Nur Konten, die Repositories verwalten, sollten die Rolle „Repository-Administrator für Artifact Registry“ oder „Administrator für Artifact Registry“ haben.

Artifact Registry-Leser: Artefakte und Repositories auflisten. Artefakte herunterladen.
Artifact Registry-Autor: Artefakte und Repositories auflisten. Sie können Artefakte herunterladen, neue Artefaktversionen hochladen und Tags hinzufügen oder aktualisieren.
Repository-Administrator für Artifact Registry: Artifact Registry Writer-Berechtigungen und Berechtigungen zum Löschen von Artefakten und Tags.
Artifact Registry-Administrator: Berechtigungen für Artifact Registry-Repository-Administratoren und Berechtigungen zum Erstellen, Aktualisieren, Löschen und Gewähren von Berechtigungen für Repositories.

Sie können diese Berechtigungen auf Repository-Ebene anwenden. Beispiel:

Team 1 Zugriff auf us-central1-docker.pkg.dev/my-project/team1 gewähren
Gewähren Sie Team 2 Zugriff auf us-central1-docker.pkg.dev/my-project/team2.

Weitere Informationen zum Gewähren von Artifact Registry-Berechtigungen finden Sie in der Dokumentation zur Zugriffssteuerung.

Images erstellen und per Push übertragen

Wichtige Fakten:

Sie müssen ein Docker-Repository in Artifact Registry erstellen, bevor Sie ein Image dorthin übertragen können.
Die Hostnamen von Artifact Registry unterscheiden sich von den Hostnamen der Container Registry.

Mit Cloud Build können Sie ein Image in einem einzigen Schritt erstellen, taggen und pushen.

Mit Container Registry kann Cloud Build ein Image erfolgreich an einen Registry-Host übertragen, der im Projekt noch nicht vorhanden ist. Google Cloud Für diesen ersten Image-Push hat Cloud Build die Berechtigung, dem Projekt automatisch den Registry-Host hinzuzufügen.

So passen Sie einen Container Registry-Workflow an:

Richten Sie Ihre Repositories ein, bevor Sie Bilder per Push übertragen.
Aktualisieren Sie die Imagepfade in Ihrer Build-Konfigurationsdatei oder in gcloud builds submit-Befehlen.

Mit einer Build-Konfigurationsdatei erstellen

Ersetzen Sie die Container Registry-Pfade für von Ihnen erstellte Images durch den Pfad zu einem vorhandenen Artifact Registry-Repository.

In der folgenden Beispiel-cloudbuild.yaml-Datei wird das Image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 erstellt:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1'

Sie können das Image dann mit dem Befehl erstellen:

gcloud builds submit --config cloudbuild.yaml

Mit einem Dockerfile erstellen

Ersetzen Sie die Container Registry-Pfade für von Ihnen erstellte Images durch den Pfad zu einem vorhandenen Artifact Registry-Repository.

Mit dem folgenden Beispielbefehl wird das Image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1 mit einer Dockerfile im aktuellen Verzeichnis erstellt:

gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1

Images bereitstellen

Wichtiger Punkt:

Die Hostnamen von Artifact Registry unterscheiden sich von den Hostnamen der Container Registry.

Wenn Sie einen Container Registry-Workflow anpassen möchten, aktualisieren Sie die Imagepfade in Ihrer Bereitstellungskonfiguration und Ihren Bereitstellungsbefehlen. In den folgenden Abschnitten finden Sie Beispiele für Cloud Build, Cloud Run und GKE. Derselbe Ansatz gilt jedoch für alle anderen Google Cloud Dienste, die Images bereitstellen.

Cloud Build

Ersetzen Sie die Container Registry-Pfade für die bereitgestellten Images durch den Pfad zu einem vorhandenen Artifact Registry-Repository.

In der folgenden Beispiel-cloudbuild.yaml-Datei wird das Beispielbild us-docker.pkg.dev/cloudrun/container/hello bereitgestellt.

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args:
  - 'run'
  - 'deploy'
  - 'cloudrunservice'
  - '--image'
  - 'us-docker.pkg.dev/cloudrun/container/hello'
  - '--region'
  - 'us-central1'
  - '--platform'
  - 'managed'
  - '--allow-unauthenticated'

Cloud Run

Ersetzen Sie die Container Registry-Pfade für die bereitgestellten Images durch den Pfad zu einem vorhandenen Artifact Registry-Repository.

Mit diesem Befehl wird beispielsweise das Beispiel-Image us-docker.pkg.dev/cloudrun/container/hello bereitgestellt.

gcloud run deploy my-service --image us-docker.pkg.dev/cloudrun/container/hello

GKE

Ersetzen Sie die Container Registry-Pfade für von Ihnen erstellte Images durch den Pfad zu einem vorhandenen Artifact Registry-Repository.

In den folgenden Beispielen für Artifact Registry wird das Beispielbild us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 verwendet.

So erstellen Sie einen Cluster über die Befehlszeile:

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

So geben Sie ein Image in einem Bereitstellungsmanifest an:

In a deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0