Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Run-Anwendung mit Cloud Deploy bereitstellen

1. Übersicht

In diesem Lab stellen Sie mit Cloud Deploy eine .NET-Anwendung in Cloud Run bereit. Sie erstellen ein Container-Image mit Cloud Build, ohne Dockerfile zu verwenden. Sie richten mit Cloud Deploy eine Pipeline mit drei Zielumgebungen ein und führen die Schritte aus, um den Release in die verschiedenen Umgebungen zu verschieben. Abschließend genehmigen Sie die Bereitstellung des Release in der Produktionsumgebung.

Was ist Cloud Build?

Mit Cloud Build können Sie Software schnell in allen Programmiersprachen erstellen.

Was ist Cloud Deploy?

Cloud Deploy ist ein vollständig verwalteter Continuous Delivery-Dienst. Mit Cloud Deploy können Sie Bereitstellungspipelines für GKE, Anthos und Cloud Run erstellen.

Was ist Cloud Run?

Mit Cloud Run können Sie skalierbare Containeranwendungen in einer beliebigen Sprache (z. B. Go, Python, Java, Node.js, .NET und Ruby) auf einer vollständig verwalteten Plattform bereitstellen.

Was ist Skaffold?

Skaffold ist ein Befehlszeilentool, das die kontinuierliche Entwicklung für Kubernetes-native Anwendungen ermöglicht. Cloud Deploy verwendet Skaffold für Rendering- und Bereitstellungsvorgänge.

Lerninhalte

In diesem Lab lernen Sie Folgendes:

Cloud Deploy-Pipeline erstellen
Container-Image für .NET-Anwendung mit Cloud Build ohne Dockerfile erstellen
Anwendung mit Cloud Deploy in Cloud Run bereitstellen
Cloud Deploy-Releases veröffentlichen

Vorbereitung

Für dieses Lab wird davon ausgegangen, dass Sie mit der Cloud Console und mit Shell-Umgebungen vertraut sind.

2. Einrichtung und Anforderungen

Cloud-Projekt einrichten

Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Gerät testen, um zu sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Wenn Sie die Ressourcen deaktivieren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Umgebung einrichten

Klicken Sie zum Aktivieren von Cloud Shell auf das Symbol rechts neben der Suchleiste.

Führen Sie in Cloud Shell den folgenden Befehl aus, um Projektumgebungsvariablen festzulegen:

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
--format='value(projectNumber)')
export REGION=us-central1

APIs aktivieren:

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

Erstellen Sie ein Artifact Registry-Repository zum Speichern von Anwendungscontainer-Images:

gcloud artifacts repositories create containers-repo \
  --repository-format=docker \
  --location=${REGION} \
  --description="Containers repository"

3. Konfigurationsdateien prüfen

Quellcode der Anwendung klonen:

git clone https://github.com/gitrey/deploy-cloudrun-app-with-clouddeploy.git
cd deploy-cloudrun-app-with-clouddeploy

Cloud Deploy-Pipelinekonfiguration prüfen:

clouddeploy.yaml

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: cloud-run-pipeline
description: application deployment pipeline
serialPipeline:
 stages:
 - targetId: dev-env
   profiles: [dev]
 - targetId: qa-env
   profiles: [qa]
 - targetId: prod-env
   profiles: [prod]
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: dev-env
description: Cloud Run development service
run:
 location: projects/_PROJECT_ID/locations/us-west1
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: qa-env
description: Cloud Run QA service
run:
 location: projects/_PROJECT_ID/locations/us-central1
---

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: prod-env
description: Cloud Run PROD service
run:
 location: projects/_PROJECT_ID/locations/us-south1

Sehen Sie sich die Datei skaffold.yaml an, in der drei Umgebungen definiert sind und Cloud Run als Zieldienst verwendet wird.

skaffold.yaml

apiVersion: skaffold/v3alpha1
kind: Config
metadata: 
  name: cloud-run-app
profiles:
- name: dev
  manifests:
    rawYaml:
    - deploy-dev.yaml
- name: qa
  manifests:
    rawYaml:
    - deploy-qa.yaml
- name: prod
  manifests:
    rawYaml:
    - deploy-prod.yaml
deploy:
  cloudrun: {}

Prüfen Sie die Dienstkonfigurationsdateien.

deploy-dev.yaml

kind: Service
metadata:
  name: app-dev
spec:
  template:
    spec:
      containers:
      - image: app
        resources:
          limits:
            cpu: 1000m
            memory: 128Mi

deploy-qa.yaml

kind: Service
metadata:
  name: app-dev
spec:
  template:
    spec:
      containers:
      - image: app

deploy-prod.yaml

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: app-prod
spec:
  template:
    spec:
      containers:
      - image: app

Sehen Sie sich die cloudbuild.yaml-Datei mit den Schritten zum Erstellen eines Container-Images und zum Erstellen eines Cloud Deploy-Release an:

cloudbuild.yaml

steps:
- name: 'gcr.io/k8s-skaffold/pack'
  entrypoint: 'pack'
  args: ['build',
         '--builder=gcr.io/buildpacks/builder',
         '--publish', '${_REGION}-docker.pkg.dev/${PROJECT_ID}/containers-repo/app:$BUILD_ID']
  id: Build and package .net app
- name: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  args: 
      [
        "deploy", "releases", "create", "release-$_RELEASE_TIMESTAMP",
        "--delivery-pipeline", "cloud-run-pipeline",
        "--region", "${_REGION}",
        "--images", "app=${_REGION}-docker.pkg.dev/${PROJECT_ID}/containers-repo/app:$BUILD_ID"
      ]
  entrypoint: gcloud

4. Cloud Deploy-Pipeline erstellen

Ersetzen Sie den Wert _PROJECT_ID in der Datei „clouddeploy.yaml“:

sed -i "s/_PROJECT_ID/$PROJECT_ID/g" clouddeploy.yaml

Cloud Deploy-Pipeline erstellen:

gcloud deploy apply \
  --file=clouddeploy.yaml \
  --region=${REGION} \
  --project=${PROJECT_ID}

Überprüfen Sie die erstellte Pipeline in Cloud Deploy.

5. Container-Image erstellen und Release erstellen

Fügen Sie dem Cloud Build-Dienstkonto Cloud Deploy-Berechtigungen für den Operator hinzu:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/clouddeploy.operator

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/iam.serviceAccountUser

Erstellen Sie ein Container-Image und eine Cloud Deploy-Version:

export RELEASE_TIMESTAMP=$(date '+%Y%m%d-%H%M%S')

gcloud builds submit \
  --config cloudbuild-plus.yaml \
  --substitutions=_REGION=${REGION},_RELEASE_TIMESTAMP=${RELEASE_TIMESTAMP}

Prüfen Sie den erstellten Release in Cloud Deploy. Warten Sie, bis die Bereitstellung in der Entwicklungsumgebung abgeschlossen ist.

6. Release in die QA- und PROD-Umgebungen hochstufen

Veröffentlichen Sie die Version mit der Cloud Console oder der Cloud Shell für das nächste Ziel(qa-env).

Führen Sie den Befehl „gcloud“ aus, um den Release mit Cloud Shell hochzustufen.

gcloud beta deploy releases promote \
    --release="release-${RELEASE_TIMESTAMP}" \
    --delivery-pipeline=cloud-run-pipeline \
    --region=${REGION} \
    --quiet

Warten Sie, bis die Bereitstellung in der QA-Umgebung abgeschlossen ist. Release zum nächsten Ziel(prod-env) hochstufen.

gcloud beta deploy releases promote \
    --release="release-${RELEASE_TIMESTAMP}" \
    --delivery-pipeline=cloud-run-pipeline \
    --region=${REGION} \
    --quiet

Öffnen Sie Cloud Deploy in der Cloud Console und genehmigen Sie die Bereitstellung für die Produktion.

Prüfen Sie den Pipelinestatus von Cloud Deploy und die verfügbaren DORA-Messwerte („Bereitstellungsanzahl“, „Bereitstellungshäufigkeit“, „Bereitstellungsfehlerrate“).

Messwert	Beschreibung
Anzahl der Bereitstellungen	Die Gesamtzahl der erfolgreichen und fehlgeschlagenen Bereitstellungen für das endgültige Ziel in Ihrer Bereitstellungspipeline.
Bereitstellungshäufigkeit	Wie oft Bereitstellungen über die Bereitstellungspipeline für das endgültige Ziel der Pipeline erfolgen.Dies ist einer der vier wichtigen Messwerte des DORA-Programms (DevOps Research and Assessment).
Bereitstellungsfehlerrate	Der Prozentsatz der fehlgeschlagenen Rollouts für das endgültige Ziel in Ihrer Bereitstellungspipeline.

Bereitgestellte Anwendungen in Cloud Run prüfen:

7. Glückwunsch!

Herzlichen Glückwunsch, Sie haben das Codelab abgeschlossen.

Behandelte Themen:

Cloud Deploy-Pipeline erstellen
Container-Image für .NET-Anwendung mit Cloud Build erstellen
Anwendung mit Cloud Deploy in Cloud Run bereitstellen
Cloud Deploy-Release hochstufen

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten durch Löschen des für die Anleitung erstellten Projekts.