Canary-Deployment einer Anwendung auf einem Ziel

Canary-Deployment einer Anwendung auf einem Ziel

In dieser Kurzanleitung erfahren Sie, wie Sie mit Cloud Deploy ein Beispielanwendungs-Image in einer Canary-Bereitstellung entweder in der Google Kubernetes Engine oder in Cloud Run bereitstellen. Sie können ein Canary-Deployment auch in GKE Enterprise ausführen. In diesem Schnellstart werden jedoch nur GKE und Cloud Run angezeigt.

Bei einem Canary-Deployment wird der Traffic zwischen einer bereits bereitgestellten Version der Anwendung und der neuen Version aufgeteilt. Cloud Run verteilt den Traffic basierend auf den Prozentsätzen, die Sie in der Bereitstellungspipeline konfigurieren. GKE stellt die neue Version für einen Teil der Pods bereit. Bei diesem Quickstart wird zuerst eine Bereitstellung auf 50% und dann auf 100 % durchgeführt.

In dieser Kurzanleitung gibt es nur ein Ziel (prod). Wir erstellen also nur einen GKE-Cluster oder einen Cloud Run-Dienst, um Ihre Anwendung auszuführen.

Dieser Schnellstart erläutert folgende Schritte:

1. Erstellen Sie einen GKE-Cluster oder definieren Sie einen Cloud Run-Dienst.

   Sie können Canary-Deployments auch in GKE Enterprise-Clustern durchführen. In dieser Kurzanleitung werden jedoch nur GKE und Cloud Run verwendet.

2. Erstellen Sie eine Skaffold-Konfiguration und ein Kubernetes-Manifest, um das (vordefinierte) Container-Image anzugeben.

3. Definieren Sie Ihre Cloud Deploy-Bereitstellungspipeline und das Bereitstellungsziel.

4. Rufen Sie Ihre Bereitstellungspipeline auf, indem Sie einen Release erstellen, der automatisch für ein Ziel bereitgestellt wird.

   Bei dieser ersten Version wird die Canary-Phase übersprungen.

5. Rufen Sie die Lieferpipeline und den Release in der Google Cloud Console auf.

6. Erstellen Sie einen zweiten Release und führen Sie diesmal die Canary-Phase aus, um die Anwendung zu 50 % bereitzustellen.

7. Stellen Sie den Release auf 100 % ein.

Hinweise

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. Enable the Cloud Deploy, Cloud Build, GKE, Cloud Run, and Cloud Storage APIs.

   Enable the APIs

5. Install the Google Cloud CLI.

6. To initialize the gcloud CLI, run the following command:

   gcloud init

   Note: You can run the gcloud CLI in the Google Cloud console without installing the Google Cloud CLI. To run the gcloud CLI in the Google Cloud console, use Cloud Shell.

7. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

8. Make sure that billing is enabled for your Google Cloud project.

9. Enable the Cloud Deploy, Cloud Build, GKE, Cloud Run, and Cloud Storage APIs.

   Enable the APIs

10. Install the Google Cloud CLI.

11. To initialize the gcloud CLI, run the following command:

    gcloud init

    Note: You can run the gcloud CLI in the Google Cloud console without installing the Google Cloud CLI. To run the gcloud CLI in the Google Cloud console, use Cloud Shell.

Wenn Sie die Befehlszeile bereits installiert haben, prüfen Sie, ob Sie die neueste Version verwenden:

gcloud components update

12. Achten Sie darauf, dass das Compute Engine-Standarddienstkonto ausreichend Berechtigungen hat.

    Das Dienstkonto hat möglicherweise bereits die erforderlichen Berechtigungen. Diese Schritte gelten für Projekte, die automatische Rollenzuweisungen für Standarddienstkonten deaktivieren.

    1. Fügen Sie zuerst die Rolle clouddeploy.jobRunner hinzu:

       gcloud projects add-iam-policy-binding PROJECT_ID \
           --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
           --format="value(projectNumber)")[e-mail] \
           --role="roles/clouddeploy.jobRunner"
       

    2. Fügen Sie die Entwicklerrolle für Ihre jeweilige Laufzeit hinzu.
    • Für GKE und GKE mit Gateway API:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")[e-mail] \
          --role="roles/container.developer"
      

    • Für Cloud Run:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")[e-mail] \
          --role="roles/run.developer"
      

    3. Fügen Sie die Rolle iam.serviceAccountUser hinzu, die die Berechtigung actAs zum Bereitstellen in der Laufzeit enthält:

       gcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe PROJECT_ID \
           --format="value(projectNumber)")[e-mail] \
           --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
           --format="value(projectNumber)")[e-mail] \
           --role="roles/iam.serviceAccountUser" \
           --project=PROJECT_ID
       

Laufzeitumgebung erstellen

GKE

Erstellen Sie einen GKE Autopilot-Cluster:

 gcloud container clusters create-auto canary-quickstart-cluster \
                  --project=PROJECT_ID \
                  --region=us-central1

GKE + Gateway API

1. Erstellen Sie einen GKE-Cluster mit den empfohlenen Einstellungen für die Verwendung mit Istio:

   gcloud container clusters create canary-quickstart-cluster \
          --machine-type=n1-standard-1 \
          --num-nodes 4 \
          --region=us-central1 \
          --project=PROJECT_ID
   

2. Rufen Sie die Clusteranmeldedaten ab:

   gcloud container clusters get-credentials canary-quickstart-cluster \
          --project=PROJECT_ID \
          --region=us-central1
   

3. Installieren Sie die CRDs der Kubernetes Gateway API, falls sie noch nicht im Cluster vorhanden sind.

   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.6.2/standard-install.yaml
   

4. Aktivieren Sie die Gateway-Controller-Implementierung von Istio, indem Sie Istio installieren.

   curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.17.2 sh - \
   && ./istio-1.17.2/bin/istioctl install --set profile=minimal -y
   

Cloud Run

Wenn Sie Cloud Run verwenden, können Sie diesen Befehl überspringen.

Skaffold-Konfiguration und Anwendungsmanifest vorbereiten

Cloud Deploy verwendet Skaffold, um Details zu den bereitzustellenden Elementen und deren korrekte Bereitstellung für das Ziel anzugeben.

In dieser Kurzanleitung erstellen Sie eine skaffold.yaml-Datei, in der das zu implementierende Kubernetes-Manifest oder die zu implementierende Cloud Run-Dienstkonfiguration angegeben ist.

1. Öffnen Sie ein Terminalfenster.

2. Erstellen Sie ein neues Verzeichnis und rufen Sie es auf.

   GKE

   mkdir deploy-canary-quickstart-gke
   cd deploy-canary-quickstart-gke
   

   GKE + Gateway API

   mkdir deploy-canary-quickstart-gke-gatewayapi
   cd deploy-canary-quickstart-gke-gatewayapi
   

   Cloud Run

   mkdir deploy-canary-quickstart-run
   cd deploy-canary-quickstart-run
   

3. Erstellen Sie eine Datei mit dem Namen skaffold.yaml und mit folgendem Inhalt:

   GKE

   apiVersion: skaffold/v4beta7
   kind: Config
   manifests:
     rawYaml:
     - kubernetes.yaml
   deploy:
     kubectl: {}
   

   GKE + Gateway API

   apiVersion: skaffold/v4beta7
   kind: Config
   manifests:
     rawYaml:
     - kubernetes.yaml
   deploy:
     kubectl: {}
   

   Cloud Run

   apiVersion: skaffold/v4beta7
   kind: Config
   manifests:
     rawYaml:
     - run.yaml
   deploy:
     cloudrun: {}
   

   Diese Datei ist eine minimale Skaffold-Konfiguration, in der Ihr Manifest angegeben ist. In dieser Kurzanleitung erstellen Sie die Datei. Sie können aber auch Cloud Deploy bitten, eine für Sie zu erstellen, wenn es sich um einfache Anwendungen handelt, die nicht für die Produktion bestimmt sind.

   Weitere Informationen zu dieser Datei finden Sie in der skaffold.yaml-Referenz.

4. Erstellen Sie das Anwendungsmanifest.

   GKE

   Erstellen Sie im Verzeichnis deploy-canary-quickstart-gke eine Datei namens kubernetes.yaml mit folgendem Inhalt:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-deployment
     labels:
       app: my-app
     namespace: default
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: nginx
           image: my-app-image
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
     namespace: default
   spec:
     selector:
       app: my-app
     ports:
       - protocol: TCP
         port: 80
   

   Diese Datei ist ein Kubernetes-Manifest, das auf den Cluster angewendet wird, um die Anwendung bereitzustellen. Dieses Manifest enthält die für die Canary-Bereitstellung erforderlichen Dienst- und Bereitstellungsressourcen sowie eine HTTPRoute und die Gateway-Ressource, die für die Verwendung der Gateway API erforderlich sind.

   Das bereitzustellende Container-Image wird hier als Platzhalter (my-app-image) festgelegt. Es wird durch das spezifische Image ersetzt, wenn Sie den Release erstellen.

   GKE + Gateway API

   Erstellen Sie im Verzeichnis deploy-canary-quickstart-gke-gatewayapi eine Datei namens kubernetes.yaml mit folgendem Inhalt:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: my-gateway
     annotations:
       networking.istio.io/service-type: "ClusterIP"
   spec:
     gatewayClassName: istio
     listeners:
     - name: default
       hostname: "*.example.com"
       port: 80
       protocol: HTTP
       allowedRoutes:
         namespaces:
           from: All
   ---
   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: my-httproute
   spec:
     parentRefs:
     - kind: Gateway
       name: my-gateway
     hostnames:
     - "test.example.com"
     rules:
     - backendRefs:
       - name: my-service
         port: 80
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
   spec:
     selector:
       app: my-app
     ports:
     - name: tcp-port
       protocol: TCP
       port: 80
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-deployment
     labels:
       app: my-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: nginx
           image: my-app-image
   

   Diese Datei ist ein Kubernetes-Manifest, das auf den Cluster angewendet wird, um die Anwendung bereitzustellen. Dieses Manifest enthält die für die Canary-Bereitstellung erforderlichen Dienst- und Bereitstellungsressourcen sowie eine HTTPRoute und die Gateway-Ressource, die für die Verwendung der Gateway API erforderlich sind.

   Das bereitzustellende Container-Image wird hier als Platzhalter (my-app-image) festgelegt. Es wird durch das spezifische Image ersetzt, wenn Sie den Release erstellen.

   Cloud Run

   Erstellen Sie im Verzeichnis deploy-canary-quickstart-run eine Datei namens run.yaml mit folgendem Inhalt:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: my-canary-run-service
   spec:
     template:
       spec:
         containers:
         - image: my-app-image
   

   Diese Datei ist eine grundlegende Cloud Run-Dienstdefinition, die zum Zeitpunkt der Bereitstellung angewendet wird, um Ihren Dienst in Cloud Run zu erstellen. Das bereitzustellende Container-Image wird hier als Platzhalter my-app-image festgelegt, der beim Erstellen der Version durch das entsprechende Image ersetzt wird.

Hinweis: Wenn Sie pro Ziel verschiedene Manifeste verwenden möchten, lesen Sie diesen Artikel zum Verwalten von Manifesten, um mehr über die Verwendung von Skaffold-Profilen zu erfahren.

Lieferpipeline und Ziele erstellen

Sie können die Lieferpipeline und die Ziele in einer Datei oder in separaten Dateien definieren. In dieser Kurzanleitung erstellen wir eine Datei für unsere Pipeline und unser einziges Ziel:

GKE

Erstellen Sie im Verzeichnis deploy-canary-quickstart-gke eine Datei namens clouddeploy.yaml mit folgendem Inhalt:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-canary-demo-app-1
description: main application pipeline
serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "my-service"
              deployment: "my-deployment"
        canaryDeployment:
          percentages: [50]
          verify: false
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: prod GKE cluster
gke:
 cluster: projects/PROJECT_ID/locations/us-central1/clusters/canary-quickstart-cluster

GKE + Gateway API

Erstellen Sie im Verzeichnis deploy-canary-quickstart-gke-gatewayapi eine Datei namens clouddeploy.yaml mit folgendem Inhalt:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-canary-demo-app-1
description: main application pipeline
serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "my-httproute"
              service: "my-service"
              deployment: "my-deployment"
        canaryDeployment:
          percentages: [50]
          verify: false
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: prod GKE cluster
gke:
 cluster: projects/PROJECT_ID/locations/us-central1/clusters/canary-quickstart-cluster

Cloud Run

Erstellen Sie im Verzeichnis deploy-canary-quickstart-run eine Datei namens clouddeploy.yaml mit folgendem Inhalt:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-canary-demo-app-1
description: main application pipeline
serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [50]
          verify: false
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: prod Run Service
run:
  location: projects/PROJECT_ID/locations/us-central1

1. Registrieren Sie Ihre Pipeline und Ziele beim Cloud Deploy-Dienst:

   gcloud deploy apply --file=clouddeploy.yaml --region=us-central1 --project=PROJECT_ID
   

   Sie haben jetzt eine Pipeline mit einem Ziel, das für eine Canary-Bereitstellungsstrategie konfiguriert ist.

2. Bestätigen Sie Pipeline und Ziele:

   Rufen Sie in der Google Cloud Console die Seite Lieferpipelines von Cloud Deploy auf, um eine Liste der verfügbaren Lieferpipelines aufzurufen.

   Zur Seite der Lieferpipelines

   Die soeben erstellte Delivery-Pipeline wird angezeigt und das von Ihnen konfigurierte Ziel wird in der Spalte Ziele aufgeführt.

   

Release erstellen

Ein Release ist die zentrale Cloud Deploy-Ressource, die die bereitgestellten Änderungen darstellt. Die Bereitstellungspipeline definiert den Lebenszyklus dieser Version. Weitere Informationen zu diesem Lebenszyklus finden Sie unter Cloud Deploy-Dienstarchitektur.

Führen Sie folgenden Befehl im Verzeichnis deploy-canary-quickstart-gke, deploy-canary-quickstart-gke-gatewayapi oder deploy-canary-quickstart-run aus, um eine release-Ressource zu erstellen, die das bereitzustellende Container-Image darstellt:

GKE

 gcloud deploy releases create test-release-001 \
   --project=PROJECT_ID \
   --region=us-central1 \
   --delivery-pipeline=my-canary-demo-app-1 \
   --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa

GKE + Gateway API

 gcloud deploy releases create test-release-001 \
   --project=PROJECT_ID \
   --region=us-central1 \
   --delivery-pipeline=my-canary-demo-app-1 \
   --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa

Cloud Run

 gcloud deploy releases create test-release-001 \
   --project=PROJECT_ID \
   --region=us-central1 \
   --delivery-pipeline=my-canary-demo-app-1 \
   --images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:4a856b6f1c3ce723a456ddc2adfbb794cbfba93f727e2d96fcf6540bd0d6fff4

Beachten Sie das --images=-Flag, mit dem Sie den Platzhalter (my-app-image) im Manifest oder in der Dienstdefinition durch das spezifische, SHA-qualifizierte Image ersetzen. Google empfiehlt, Ihre Manifeste auf diese Weise zu modellieren und beim Erstellen von Releases SHA-qualifizierte Image-Namen zu verwenden.

Wenn Sie einen Release erstellen, wird in Cloud Deploy automatisch auch eine Rollout-Ressource erstellt, um die Bereitstellung sofort auf das einzige Ziel prod vorzunehmen.

Wir springen zur stabilen Phase

Bei diesem ersten Release überspringen wir die Canary-Phase und führen ein Deployment zu 100% (stabile Phase) durch. Das liegt daran, dass die Anwendung noch nicht bereitgestellt wurde. Daher können 50% der Pods (für GKE) oder die Aufteilung des Traffics für den Dienst (für Cloud Run) nicht berechnet werden. Die Pods (GKE) oder Revisionen (Cloud Run) existieren noch nicht.

Da wir die Canary-Phase übersprungen haben, können wir jetzt mit der stabilen Phase beginnen, in der der Traffic zu 100 % auf die neue Version umgestellt wird. Danach erstellen wir einen weiteren Release, mit dem der Canary ausgeführt wird.

In der Praxis führen Sie in der Regel eine Canary-Bereitstellung aus, bei der Ihre Anwendung bereits ausgeführt wird. Daher wird diese Phase selten übersprungen.

Release in der Google Cloud Console ansehen

Nachdem Sie den ersten Release erstellt haben, wird das Roll-out erstellt. Sie können sich den Release und das Roll-out in der Google Cloud Console ansehen. Sie können sich auch die Pipelinevisualisierung ansehen, in der der aktuelle Status der Veröffentlichung angezeigt wird.

1. Rufen Sie in der Google Cloud Console die Cloud Deploy-Seite Bereitstellungspipelines auf, um Ihre Bereitstellungspipeline my-canary-demo-app-1 aufzurufen.

   Zur Seite der Lieferpipelines

2. Klicken Sie auf den Namen der Lieferpipeline „my-canary-demo-app-1“.

   Die Pipelinevisualisierung zeigt den Bereitstellungsstatus der App. Da es nur eine Phase in der Pipeline gibt, wird in der Visualisierung nur ein Knoten angezeigt.

   

   Ihre Version wird auf dem Tab Releases unter Details zur Lieferpipeline aufgeführt.

3. Klicken Sie auf den Releasenamen, test-release-001.

   Ihre Einführungen werden unter Einführungen angezeigt. Sie können auf ein Roll-out klicken, um die Details aufzurufen, einschließlich des Bereitstellungslogs.

   

   Der Roll-out-Status ist „Ausstehender Fortschritt“ und das in der Pipeline-Visualisierung angezeigte Ziel enthält einen Link zu „Auf stabile Version umstellen“.

Roll-out-Phase fortsetzen

Nach dem ersten Release wurde die Canary-Phase übersprungen und das Roll-out wartet auf den Beginn der „stabilen“ Phase, in der die Anwendung zu 100 % bereitgestellt wird:

1. Klicken Sie in der Pipelinevisualisierung auf Zu „Stable“ wechseln.

2. Klicken Sie zur Bestätigung auf Advance.

Nach einigen Minuten befindet sich das Roll-out in der Phase „Stable“ (Stabil) und die Anwendung ist zu 100 % bereitgestellt.

Canary-Deployment ausführen

Da bei der ersten Version die Canary-Phase übersprungen wurde, erstellen wir jetzt eine weitere Version, bei der dieses Mal ein Canary-Deployment ausgeführt wird.

1. Führen Sie den folgenden Befehl aus dem Verzeichnis deploy-canary-quickstart-gke, deploy-canary-quickstart-gke-gatewayapi oder deploy-canary-quickstart-run aus, um ein neues release zu erstellen:

   GKE

   gcloud deploy releases create test-release-002 \
     --project=PROJECT_ID \
     --region=us-central1 \
     --delivery-pipeline=my-canary-demo-app-1 \
     --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa
   

   GKE + Gateway API

   gcloud deploy releases create test-release-002 \
     --project=PROJECT_ID \
     --region=us-central1 \
     --delivery-pipeline=my-canary-demo-app-1 \
     --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa
   

   Cloud Run

   gcloud deploy releases create test-release-002 \
     --project=PROJECT_ID \
     --region=us-central1 \
     --delivery-pipeline=my-canary-demo-app-1 \
     --images=my-app-image=us-docker.pkg.dev/cloudrun/container/hello@sha256:4a856b6f1c3ce723a456ddc2adfbb794cbfba93f727e2d96fcf6540bd0d6fff4
   

   Nach einigen Minuten wird ein Roll-out erstellt und diesmal wird die Canary-Phase ausgeführt:

   

   Nach Abschluss der ersten Roll-out-Phase befindet sich das Roll-out in der Canary-Phase:

   

   Das bedeutet, dass die Anwendung jetzt zu 50 % bereitgestellt ist. Bei GKE mit serviceNetworking wird es auf die Hälfte Ihrer Pods bereitgestellt. Für Gateway API-basierten GKE- und Cloud Run-Traffic werden 50 % zugewiesen.

2. Klicken Sie auf Roll-out beschleunigen und dann auf Weiter.

   Dadurch wird das Roll-out in die Phase „Stable“ (Stabil) fortgesetzt und die Anwendung zu 100 % bereitgestellt.

   

Bereinigen

Mit den folgenden Schritten vermeiden Sie, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden:

1. canary-quickstart-cluster-Cluster löschen (nur GKE):

   gcloud container clusters delete canary-quickstart-cluster --region=us-central1 --project=PROJECT_ID
   

2. my-canary-run-service-Dienst löschen (nur Cloud Run):

   gcloud run services delete my-canary-run-service --region=us-central1 --project=PROJECT_ID
   

3. Löschen Sie die Bereitstellungspipeline, das Ziel und alle Release- und Roll-out-Ressourcen:

   gcloud deploy delete --file=clouddeploy.yaml --force --region=us-central1 --project=PROJECT_ID
   

4. Löschen Sie die von Cloud Deploy erstellten Cloud Storage-Buckets.

   Eine endet mit _clouddeploy und die andere mit [region].deploy-artifacts.[project].appspot.com.

   Die Cloud Storage-Browserseite öffnen

Das war alles. Sie haben diesen Schnellstart abgeschlossen!

Nächste Schritte

• Weitere Informationen zu Cloud Deploy

• Grundlagen zum Bereitstellen von Anwendungen

• Probieren Sie die Schritt-für-Schritt-Anleitung für Cloud Deploy aus.

• Erfahren Sie, wie Sie Manifeste verwalten.

• Informationen zum Kombinieren von Google Cloud-CI/CD-Tools, um Software effektiv für GKE zu entwickeln und bereitzustellen