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 erläutert. und Artifact Registry beim Erstellen von Container-Images mit Cloud Build und in Google Cloud-Laufzeitumgebungen wie Cloud Run oder Google Kubernetes Engine.

In diesem Leitfaden wird hauptsächlich die standardmäßige Artifact Registry verglichen. reguläre Artifact Registry-Repositories, die unabhängig sind, von Container Registry und unterstützen alle Artifact Registry-Features. Wenn Ihr Administrator Repositories mit gcr.io-Domainunterstützung 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.

Verwenden Sie diese Informationen, um vorhandene Befehle, Konfigurationen oder Dokumentation zu Container Registry mit Cloud Build.

Hinweise

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

Artifact Registry wurde 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 ruft Images aus der Registry ab.

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

Der Container Registry-Workflow vereint Administratoraufgaben mit erstellen und bereitstellen.

Wenn Sie einige Google Cloud APIs aktivieren, Die Container Registry API wird automatisch aktiviert. Das bedeutet, dass Nutzende dieser Dienste haben impliziten Zugriff auf Container Registry im selben Projekt. Für Nutzer, die Builds in Cloud Build ausführen können, können z. B. Images an Registry-Hosts standardmäßig 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. Es bedeutet auch, dass das Konto Speicher-Buckets im gesamten Projekt erstellen, lesen und 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. Jeder Schritt ist mit zusätzlichen Informationen zum Ändern des Workflows verknüpft.

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 ist mit dem Container Registry-Beispiel identisch: Für das Image wird jedoch ein Artifact Registry-Repository-Pfad verwendet.
```
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
```
Geändert: Image in einer Google Cloud-Laufzeit bereitstellen wie Cloud Run oder GKE.

Der folgende Beispielbefehl ist mit dem Container Registry-Beispiel identisch: Für das Image wird jedoch der Artifact Registry-Repository-Pfad verwendet.
```
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 des Standarddienstes Konten.
Sie haben anderen Nutzer- oder Dienstkonten Berechtigungen erteilt.

API aktivieren

Wichtige Fakten

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

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

Container Registry

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

Flexible App Engine-Umgebung
Cloud Build
Cloud Run-Funktionen
Cloud Run
Scannen von Containern oder On-Demand-Scans 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 in Google 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 wie Cloud Build, Cloud Run und GKE die Artifact Registry API nicht automatisch aktivieren.

Mit gcloud können Sie mehrere APIs im selben Projekt aktivieren. Um beispielsweise die Cloud Build API und die API Artifact Registry API den folgenden Befehl aus:

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

Registrys 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 an einer einzigen 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 ID Die Rolle „Storage Admin“ auf Projektebene überträgt ein anfängliches Image.

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. gcr.io-Host zum Projekt hinzufügen
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 um einen Storage-Bucket zu erstellen, sodass das anfängliche Image und die nachfolgenden Push-Vorgänge die nicht unterscheidbar sind.

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. Eines 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 ist nicht berechtigt, ein Standardrepository in der Artifact Registry-Domain pkg.dev zu erstellen.

Ein Konto mit dem Artifact Registry-Repository Die Administratorrolle muss Folgendes erstellen: bevor Sie Images per Push in das Repository übertragen. Anschließend können Sie anderen Nutzern Berechtigungen für das Repository erteilen.

In Artifact Registry ist jedes Repository eine separate Ressource. Dementsprechend wird Alle Image-Pfade müssen 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

Die folgenden Beispiele zeigen Situationen, in denen ein Bild per Push-Funktion fehlendes Repository schlägt fehl.

Bild per Push an us-central1-docker.pkg.dev/my-project/team1 übertragen, wenn us-central1-docker.pkg.dev/my-project/team1 ist nicht vorhanden.
Bild per Push an us-central1-docker.pkg.dev/my-project/team2 übertragen, wenn us-central1-docker.pkg.dev/my-project/team1 ist vorhanden, aber us-central1-docker.pkg.dev/my-project/team2 ist nicht vorhanden.

Berechtigungen gewähren

Wichtige Fakten

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

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

Container Registry

Container Registry verwendet die Cloud Storage-Rollen, um den Zugriff zu steuern. Cloud Build hat die erforderlichen Berechtigungen in der Rolle „Storage Admin“, um Container Registry-Hosts einem Projekt hinzuzufügen.

Storage-Objekt-Betrachter auf Storage-Bucket-Ebene: Images von vorhandenen Registry-Hosts im Projekt abrufen bzw. lesen.
Autor alter Storage-Buckets auf Storage-Bucket-Ebene: Images für vorhandene Registry-Hosts im Projekt per Push (Schreiben) und Pull (Lesezugriff) senden.
Storage-Administrator 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 Steuerung des Zugriffs. 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. Artefakte herunterladen, neues Artefakt hochladen und fügen Sie Tags hinzu oder aktualisieren Sie sie.
Repository-Administrator für Artifact Registry: Artifact Registry-Autoren – Berechtigungen und Berechtigungen zum Löschen Artefakte und Tags.
Artifact Registry-Administrator: Berechtigungen und Berechtigungen des Artifact Registry-Repository-Administrators zum Erstellen, Aktualisieren, Löschen und Erteilen von Berechtigungen für Repositories.

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

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

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

Images erstellen und per Push übertragen

Wichtige Fakten

Sie müssen vor der Übertragung ein Artifact Registry-Docker-Repository erstellen ein Bild hinzufügen.
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 noch nicht im Google Cloud-Projekt vorhanden ist. 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 Images per Push an sie übertragen.
Image-Pfade in der Build-Konfigurationsdatei oder gcloud builds submit aktualisieren .

Mit einer Build-Konfigurationsdatei erstellen

Ersetzen Sie Container Registry-Pfade für Images, die Sie mit der 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 folgenden Befehl erstellen:

gcloud builds submit --config cloudbuild.yaml

Mit einem Dockerfile erstellen

Ersetzen Sie Container Registry-Pfade für Images, die Sie mit der Pfad zu einem vorhandenen Artifact Registry-Repository.

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

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.

Aktualisieren Sie Image-Pfade in Ihrer Bereitstellung, um einen Container Registry-Workflow anzupassen Konfigurations- und Bereitstellungsbefehle. In den folgenden Abschnitten finden Sie Beispiele für Cloud Build, Cloud Run und GKE, für alle anderen Google Cloud-Dienste gilt, die Images bereitstellen.

Cloud Build

Ersetzen Sie Container Registry-Pfade für Images, die Sie mit dem Pfad zu einem vorhandenen Artifact Registry-Repository.

Die folgende Beispieldatei cloudbuild.yaml stellt das Beispiel-Image bereit us-docker.pkg.dev/cloudrun/container/hello.

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 bereitgestellt. us-docker.pkg.dev/cloudrun/container/hello

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

GKE

Ersetzen Sie Container Registry-Pfade für Images, die Sie mit der Pfad zu einem vorhandenen Artifact Registry-Repository.

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

Cluster über die Befehlszeile erstellen:

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

Image in einem Bereitstellungsmanifest angeben:

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/artifact-registry-samples/containers/gke/hello-app:1.0