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.