Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Änderungen für das Erstellen und Bereitstellen in Google Cloud

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

Weitere Informationen zu den Unterschieden zwischen Container Registry und Artifact Registry mithilfe eines Docker-Clients finden Sie unter Änderungen beim Übertragen und Abrufen mit Docker.

Verwenden Sie diese Informationen, um vorhandene Befehle, Konfigurationen oder Dokumentationen mit Container Registry an Cloud Build anzupassen.

Hinweis

In diesem Dokument wird davon ausgegangen, dass Sie über Folgendes verfügen:

  1. Artifact Registry in Ihrem Projekt aktiviert haben.
  2. Aktivieren Sie die Cloud Build API und die API für jeden anderen Google Cloud-Dienst, den Sie mit Artifact Registry verwenden.

Änderungen am Workflow

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

  1. Erstellen, taggen und übertragen Sie ein Image mit Cloud Build mithilfe eines Dockerfile oder einer Build-Konfigurationsdatei in das Repository.

    Im folgenden Beispiel wird das Image my-image erstellt, mit tag1 versehen und mit Push an den Host gcr.io im Projekt my-project übertragen:

    gcloud builds submit --tag gcr.io/my-project/my-image:tag1
    
  2. 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 in Cloud Run als my-service bereitgestellt.

    gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
    

Der Container Registry-Workflow kombiniert Administratoraufgaben mit der Erstellung und Bereitstellung.

  • 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 Images in Registrys übertragen und Registry-Hosts standardmäßig hinzufügen.
  • Das Cloud Build-Dienstkonto verfügt über Berechtigungen zum Erstellen von Cloud Storage-Speicher-Buckets. Dies bedeutet, dass das Konto Container Registry-Hosts automatisch einem Projekt hinzufügen kann, wenn es zum ersten Mal ein Image an den Host überträgt. Das bedeutet auch, dass das Konto im gesamten Projekt Projekte erstellen, lesen und schreiben kann. Dazu gehören auch Buckets, die nicht von Container Registry verwendet werden.

In Artifact Registry gibt es eine klare Trennung von Administrator- und Build-Rollen, die die Schritte im Build- und Deployment-Workflow ändern. Nehmen Sie die folgenden Änderungen vor, um den Container Registry-Workflow für Artifact Registry anzupassen. Jeder Schritt enthält zusätzliche Informationen zum Ändern des Workflows.

  1. 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.

  2. Neu: Erstellen Sie das Ziel-Docker-Repository, falls es noch nicht vorhanden ist. Sie müssen ein Repository erstellen, bevor Sie Images darauf hochladen können. Durch das Übertragen eines Images kann kein Erstellen eines Repositorys ausgelöst werden und das Cloud Build-Dienstkonto ist nicht berechtigt, Repositories zu erstellen.

  3. Geändert: Erstellen, taggen und übertragen Sie ein Image mit Cloud Build mithilfe eines Dockerfile oder einer Build-Konfigurationsdatei in das Repository.

    Der folgende Beispielbefehl ist mit dem Container Registry-Beispiel identisch, verwendet jedoch einen Artifact Registry-Repository-Pfad für das Image.

    gcloud builds submit --tag us-central1-docker.pkg.dev/my-repo/my-image:tag1
    
  4. Geändert: Stellen Sie das Image in einer Google Cloud-Laufzeitumgebung wie Cloud Run oder GKE bereit.

    Der folgende Beispielbefehl ist mit dem Container Registry-Beispiel identisch, verwendet jedoch den Artifact Registry-Repository-Pfad für das Image.

    gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-repo/my-image:tag1
    

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

  • Cloud Build- oder Google Cloud-Laufzeitumgebungen befinden sich in einem anderen Projekt als Artifact Registry.
  • Anstelle der Standarddienstkonten werden benutzerdefinierte Dienstkonten für Google Cloud-Dienste wie Cloud Build oder GKE verwendet.
  • Sie haben anderen Nutzern oder Dienstkonten Berechtigungen gewährt.

API aktivieren

Wichtige Fakten:

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

Container Registry

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

  • Flexible App Engine-Umgebung
  • Cloud Build
  • Cloud Functions
  • Cloud Run
  • Containerscans oder On-Demand-Scans in Artifact Analysis
  • Google Kubernetes Engine

Mit den Standardberechtigungen können Nutzer, die Builds in Cloud Build ausführen, Container mit Artifact Analysis scannen oder Container in Google Cloud-Laufzeiten bereitstellen, implizit implizit auf Images in Container Registry zugreifen, wenn sich die Registry in der Projekt verwendet wird.

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. Verwenden Sie beispielsweise den folgenden Befehl, um die Cloud Build API und die Artifact Registry API zu aktivieren:

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

Registrys und Repositories hinzufügen

Wichtige Fakten:

  • Sie müssen ein Artifact Registry-Docker-Repository erstellen, bevor Sie ein Image hochladen.
  • Container Registry speichert alle Images in einem multiregionalen Speicherort im selben Storage-Bucket. In Artifact Registry können Sie mehrere Repositories in derselben Region oder Mehrfachregion mit separaten Zugriffsrichtlinien erstellen.

Der folgende Vergleich beschreibt die Einrichtung des Repositorys in jedem Dienst:

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.

  1. Wenn Sie Ihrem Projekt eine Registry wie gcr.io hinzufügen möchten, sendet ein Konto mit der Rolle "Storage-Administrator" auf Projektebene ein erstes Image.

    Wenn der gcr.io-Host beispielsweise nicht im Projekt my-project vorhanden ist, werden beim Hochladen des Images gcr.io/my-project/my-image:1.0 die folgenden Schritte ausgelöst:

    1. Fügen Sie dem Projekt den Host gcr.io hinzu.
    2. Erstellen Sie einen Storage-Bucket für gcr.io im Projekt.
    3. Speichern Sie das Image als gcr.io/my-project/my-image:1.0
  2. Nach diesem ersten Push können Sie dem Storage-Bucket für andere Nutzer Berechtigungen erteilen.

Standardmäßig hat Cloud Build die erforderlichen Berechtigungen zum Erstellen eines Storage-Buckets, sodass die Images für den ersten Image-Push und die nachfolgenden Push-Vorgänge nicht voneinander unterschieden werden können.

Innerhalb eines Projekts speichert ein Registry-Host alle Images im selben Storage-Bucket. Im folgenden Beispiel hat das Projekt my-project zwei Images mit dem Namen web-app in der Registry gcr.io. Eine befindet sich direkt unter der Projekt-ID my-project. Das andere Image 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 Repository zu erstellen.

Ein Konto mit der Rolle "Artefakte-Repository-Administrator" muss das Repository erstellen, bevor Sie Images darauf übertragen. Sie können dem Repository dann Berechtigungen für andere Nutzer erteilen.

In Artifact Registry ist jedes Repository eine separate Ressource. Daher müssen alle Image-Pfade 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 das Hochladen eines Images in ein fehlendes Repository fehlschlägt.

  • Übertragen eines Images an us-central1-docker.pkg.dev/my-project/team1, wenn us-central1-docker.pkg.dev/my-project/team1 nicht vorhanden ist.
  • Übertragen eines Images an us-central1-docker.pkg.dev/my-project/team2, wenn us-central1-docker.pkg.dev/my-project/team1 vorhanden ist, aber us-central1-docker.pkg.dev/my-project/team2 nicht existiert.

Berechtigungen gewähren

Wichtige Fakten:

  • Google Cloud-Dienste haben entsprechenden Lese- oder Schreibzugriff auf Container Registry und Artifact Registry. Mit dem Cloud Build-Standarddienstkonto können jedoch keine Repositories erstellt werden.
  • 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 der einzelnen Dienste beschrieben:

Container Registry

Container Registry verwendet die Cloud Storage-Rollen, um den Zugriff zu steuern. Cloud Build verfügt in der Rolle "Storage-Administrator" über die erforderlichen Berechtigungen, um einem Projekt Container Registry-Hosts hinzuzufügen.

Storage-Objekt-Betrachter auf Storage-Bucket-Ebene
Pull-Images von vorhandenen Registry-Hosts im Projekt abrufen.
Storage-Objekt-Administrator auf Storage-Bucket-Ebene
Hochladen (Schreiben) und Abrufen (Lesen) von Images für vorhandene Registry-Hosts im Projekt.
Storage-Administrator auf Projektebene
Fügen Sie einem Projekt einen Registry-Host hinzu, indem Sie ein erstes Image an den Host übertragen.

Nach dem ersten Image-Push in eine Registry weisen Sie anderen Konten, die Zugriff auf den Storage-Bucket benötigen, Cloud Storage-Rollen zu. Beachten Sie, dass jedes Konto mit allen Berechtigungen in der Rolle "Storage-Administrator" Storage-Buckets und Speicherobjekte im gesamten Projekt lesen, schreiben und löschen kann.

Berechtigungen für einen Storage-Bucket gelten für alle Repositories in der Registry. Beispielsweise kann jeder Nutzer mit den Storage-Objekt-Betrachter-Berechtigungen im Bucket für gcr.io/my-project Images in allen diesen 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 verfügt über eigene Rollen, um den Zugriff zu steuern. Diese Rollen ermöglichen eine klare Trennung zwischen Administrator- und Repository-Nutzerrollen.

Cloud Build verfügt über Berechtigungen in der Rolle "Artefakte-Registry-Autor", da es nur Images übertragen und abrufen kann.

Nur Konten, die Repositories verwalten, sollten die Administratorrolle "Artefakte-Repository" oder "Artifact Registry-Administrator" 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
Artefakte-Berechtigungen und Berechtigungen zum Löschen von Artefakten und Tags.
Artifact Registry-Administrator
Artifact Registry-Repository-Administrator 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:

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

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

Images erstellen und hochladen

Wichtige Fakten:

  • Sie müssen ein Artifact Registry-Docker-Repository erstellen, bevor Sie ein Image hochladen.
  • Die Artifact Registry-Hostnamen unterscheiden sich von Container Registry-Hostnamen.

Mit Cloud Build können Sie in einem einzigen Schritt ein Image erstellen, taggen und per Push übertragen.

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

So passen Sie einen Container Registry-Workflow an:

  1. Richten Sie Ihre Repositories ein, bevor Sie Images per Push übertragen.
  2. Aktualisieren Sie die Image-Pfade in der Build-Konfigurationsdatei oder im Befehl gcloud builds submit.

Mit einer Build-Konfigurationsdatei erstellen

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

Die folgende Beispieldatei cloudbuild.yaml erstellt das Image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1:

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 dem Pfad zu einem vorhandenen Artifact Registry-Repository erstellen.

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-repo/my-image:tag1

Images bereitstellen

Wichtigstes Thema:

  • Die Artifact Registry-Hostnamen unterscheiden sich von Container Registry-Hostnamen.

Aktualisieren Sie Image-Pfade in den Bereitstellungs- und Bereitstellungsbefehlen, um einen Container Registry-Workflow anzupassen. In den folgenden Abschnitten werden Beispiele für Cloud Build, Cloud Run und GKE gezeigt. Der gleiche Ansatz gilt aber auch für alle anderen Google Cloud-Dienste, die Images bereitstellen.

Cloud Build

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

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

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 Container Registry-Pfade für Images, die Sie mit dem Pfad zu einem vorhandenen Artifact Registry-Repository bereitstellen.

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 Container Registry-Pfade für Images, die Sie mit dem Pfad zu einem vorhandenen Artifact Registry-Repository erstellen.

In den folgenden Beispielen für Artifact Registry wird das Beispiel-Image us-docker.pkg.dev/artifact-registry-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/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