Cloud Run-Canary-Deployments mit Git-Branches und Cloud Build implementieren

Umgebung vorbereiten

1. Erstellen Sie in Cloud Shell Umgebungsvariablen, die Sie in dieser Anleitung verwenden:

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

2. Aktivieren Sie folgende APIs:

   • Resource Manager
   • GKE
   • Cloud Build
   • Container Registry
   • Cloud Run

   gcloud services enable \
       cloudresourcemanager.googleapis.com \
       container.googleapis.com \
       secretmanager.googleapis.com \
       cloudbuild.googleapis.com \
       containerregistry.googleapis.com \
       run.googleapis.com
   

3. Gewähren Sie dem Cloud Build-Dienstkonto die Rolle roles/run.adminCloud Run-Dienstkonto:

   gcloud projects add-iam-policy-binding $PROJECT_ID \
     --member=serviceAccount:[email protected] \
     --role=roles/run.admin
   

4. Weisen Sie dem Cloud Build-Dienstkonto für das Cloud Run-Laufzeitdienstkonto die Rolle roles/iam.serviceAccountUserIAM-Dienstkontonutzer zu:

   gcloud iam service-accounts add-iam-policy-binding \
   [email protected] \
     --member=serviceAccount:[email protected] \
     --role=roles/iam.serviceAccountUser
   

Git-Werte festlegen

Wenn Sie Git noch nicht über Cloud Shell verwendet haben, legen Sie die Werte für user.name und user.email fest, die Sie verwenden möchten:

    git config --global user.email YOUR_EMAIL_ADDRESS
    git config --global user.name YOUR_USERNAME
    git config --global credential.helper store

• YOUR_EMAIL_ADDRESS: die mit Ihrem GitHub-Konto verwendete E-Mail-Adresse
• YOUR_USERNAME: Ihre GitHub-Nutzer-ID

Wenn Sie MFA mit GitHub verwenden, erstellen Sie ein persönliches Zugriffstoken und verwenden Sie es als Passwort, wenn Sie über die Befehlszeile mit GitHub interagieren.

• Folgen Sie diesem Link, um ein Zugriffstoken zu erstellen.
• Lassen Sie die GitHub-Seite geöffnet.

Speichern Sie Ihre GitHub-Nutzer-ID für einen einfacheren Zugriff in einer Umgebungsvariablen:

export GH_USER=YOUR_GITHUB_ID

Projekt-Repository verzweigen

Zum Erstellen einer eigenen beschreibbaren Version des Lab-Repositorys verzweigen Sie das Beispiel-Repository über die GitHub-Benutzeroberfläche in Ihr GitHub-Konto.

Beispiel-Repository klonen

Klonen und bereiten Sie das Beispiel-Repository vor:

git clone https://github.com/$GH_USER/software-delivery-workshop.git cloudrun-progression

cd cloudrun-progression/labs/cloudrun-progression

Stellen Sie eine Verbindung zu Ihrem Git-Repository her.

Mit Cloud Build können Sie Verbindungen zu Quellcode-Repositories über die Google Cloud Console erstellen und verwalten. Sie können Verbindungen mit der ersten oder der zweiten Generation von Cloud Build-Repositories erstellen und verwalten. In dieser Anleitung werden Cloud Build-Repositories der zweiten Generation verwendet.

Erforderliche Berechtigungen erteilen

Zum Verbinden Ihres GitHub-Hosts weisen Sie dem Nutzerkonto die Rolle „Cloud Build-Verbindungsadministrator“ (roles/cloudbuild.connectionAdmin) zu:

PN=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
CLOUD_BUILD_SERVICE_AGENT="service-${PN}@gcp-sa-cloudbuild.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
 --member="serviceAccount:${CLOUD_BUILD_SERVICE_AGENT}" \
 --role="roles/secretmanager.admin"

Hostverbindung erstellen

1. Konfigurieren Sie die Cloud Build-Repository-Verbindung:

   gcloud alpha builds connections create github $GH_USER --region=us-central1
   

2. Klicken Sie auf den Link in der Ausgabe und folgen Sie der Anleitung auf dem Bildschirm, um die Verbindung herzustellen.

3. Prüfen Sie die Installation der GitHub-Verbindung:

   gcloud alpha builds connections describe $GH_USER --region=us-central1
   

Beispiel-Repository verknüpfen

Verknüpfen Sie mithilfe der soeben konfigurierten Hostverbindung den Link im Beispiel-Repository, das Sie verzweigt haben:

 gcloud alpha builds repositories create cloudrun-progression \
     --remote-uri=https://github.com/$GH_USER/software-delivery-workshop.git \
     --connection=$GH_USER \
     --region=us-central1

Variable für Repository-Namen festlegen

Speichern Sie den Repository-Namen für die spätere Verwendung:

export REPO_NAME=projects/$PROJECT_ID/locations/us-central1/connections/$GH_USER/repositories/cloudrun-progression

Cloud Run-Dienst bereitstellen

In diesem Abschnitt erstellen Sie die erste Produktionsanwendung, die Sie in dieser Anleitung verwenden, und stellen sie bereit.

Dienst bereitstellen

• Erstellen und implementieren Sie in Cloud Shell die Anwendung, einschließlich eines Dienstes, der eine Authentifizierung erfordert. Verwenden Sie zum Veröffentlichen eines öffentlichen Dienstes das Flag --allow-unauthenticated.

      gcloud builds submit --tag gcr.io/$PROJECT_ID/hello-cloudrun
  
      gcloud run deploy hello-cloudrun \
        --image gcr.io/$PROJECT_ID/hello-cloudrun \
        --platform managed \
        --region us-central1 \
        --tag=prod -q
  

  Die Ausgabe sieht in etwa so aus:

  Deploying container to Cloud Run service [hello-cloudrun] in project [sdw-mvp6] region [us-central1]
  ✓ Deploying new service... Done.
    ✓ Creating Revision...
    ✓ Routing traffic...
  Done.
  Service [hello-cloudrun] revision [hello-cloudrun-00001-tar] has been deployed and is serving 100 percent of traffic.
  Service URL: https://hello-cloudrun-apwaaxltma-uc.a.run.app
  The revision can be reached directly at https://prod---hello-cloudrun-apwaaxltma-uc.a.run.app
  

Die Ausgabe enthält die Dienst-URL und eine eindeutige URL für die Überarbeitung. Ihre Werte unterscheiden sich geringfügig von den hier angegebenen Werten.

Deployment validieren

1. Rufen Sie nach Abschluss der Bereitstellung den neu bereitgestellten Dienst auf der Seite Überarbeitungen in der Cloud Console auf.

2. Sehen Sie sich in Cloud Shell die Antwort des authentifizierten Dienstes an:

   PROD_URL=$(gcloud run services describe hello-cloudrun --platform managed --region us-central1 --format=json | jq --raw-output ".status.url")
   
   echo $PROD_URL
   
   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $PROD_URL
   

Zweigbereitstellungen aktivieren

In diesem Abschnitt aktivieren Sie für Entwicklungs-Branches in Git eine eindeutige URL.

Zweig-Trigger einrichten

Jeder Zweig wird durch eine URL dargestellt, die durch den Zweignamen identifiziert wird. Commits für den Branch lösen ein Deployment aus. Die Aktualisierungen sind unter derselben URL zugänglich.

1. Richten Sie in Cloud Shell den Trigger ein:

   gcloud alpha builds triggers create github \
   --name=branchtrigger \
   --repository=$REPO_NAME \
   --branch-pattern='[^(?!.*main)].*' \
   --build-config=labs/cloudrun-progression/branch-cloudbuild.yaml \
   --region=us-central1
   

2. Rufen Sie zum Prüfen des Triggers die Cloud Build-Seite „Trigger” in der Cloud Console auf.

Änderungen für einen Branch erstellen

1. Erstellen Sie in Cloud Shell einen neuen Branch:

   git checkout -b new-feature-1
   

2. Öffnen Sie die Beispielanwendung mit Ihrem bevorzugten Editor oder mit der Cloud Shell-IDE:

   edit app.py
   

3. Ändern Sie in der Beispielanwendung Zeile 24, um v1.1 anstelle von v1.0 anzugeben:

   @app.route('/')
   
   def hello_world():
       return 'Hello World v1.1'
   
   

4. Klicken Sie auf Terminal öffnen, um zu Ihrem Terminal zurückzukehren.

Zweig-Trigger ausführen

1. Führen Sie in Cloud Shell für die Änderung einen Commit durch und übertragen Sie sie per Push an das Remote-Repository:

   git add . && git commit -m "updated" && git push origin new-feature-1
   

2. Um den laufenden Build zu prüfen, gehen Sie zum Build-Verlauf von Cloud Build.

3. Rufen Sie nach Abschluss des Builds in der Cloud Console die Cloud Run-Seite „Überarbeitungen” auf:

4. Rufen Sie in Cloud Shell die eindeutige URL für diesen Branch ab:

   BRANCH_URL=$(gcloud run services describe hello-cloudrun --platform managed --region us-central1 --format=json | jq --raw-output ".status.traffic[] | select (.tag==\"new-feature-1\")|.url")
   
   echo $BRANCH_URL
   

5. Rufen Sie die authentifizierte URL auf:

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $BRANCH_URL
   

   Die aktualisierte Antwortausgabe sieht so aus:

   Hello World v1.1
   

Canary-Tests automatisieren

Wenn Code für die Produktion freigegeben wird, ist es üblich, Code für eine kleine Teilmenge des Live-Traffics freizugeben, bevor der gesamte Traffic zur neuen Codebasis migriert wird.

In diesem Abschnitt implementieren Sie einen Trigger, der aktiviert wird, wenn Code an den Haupt-Branch übergeben wird. Der Trigger stellt den Code für eine eindeutige Canary-URL bereit und leitet 10 % des gesamten Live-Traffics an die neue Überarbeitung weiter.

1. Richten Sie in Cloud Shell den Branch-Trigger ein:

   gcloud alpha builds triggers create github \
     --name=maintrigger \
     --repository=$REPO_NAME \
     --branch-pattern=main \
     --build-config=labs/cloudrun-progression/main-cloudbuild.yaml \
     --region=us-central1
   

2. Rufen Sie in der Cloud Console die Cloud Build-Seite „Trigger” auf, um den neuen Trigger zu prüfen.

3. Führen Sie den Branch in Cloud Shell mit der Hauptzeile zusammen und übertragen Sie ihn per Push an das Remote-Repository:

   git checkout main
   git merge new-feature-1
   git push origin main
   

4. Zum Prüfen des laufenden Builds rufen Sie die Cloud Build-Seite "Builds" auf.

5. Rufen Sie nach Abschluss des Builds in der Cloud Console die Cloud Run-Seite „Überarbeitungen” auf, um die neue Überarbeitung zu prüfen. Beachten Sie, dass 90 % des Traffics an die Produktion, 10 % an Canary und 0 % an die Überarbeitungen des Branches weitergeleitet werden.

Sehen Sie sich die wichtigsten Zeilen von main-cloudbuild.yaml an, die die Logik für das Canary-Deployment implementieren.

In den Zeilen 39–45 wird die neue Überarbeitung bereitgestellt. Mit dem Tag-Flag wird der Traffic von der eindeutigen Canary-URL weitergeleitet:

gcloud run deploy ${_SERVICE_NAME} \
--platform managed \
--region ${_REGION} \
--image gcr.io/${PROJECT_ID}/${_SERVICE_NAME} \
--tag=canary \
--no-traffic

In Zeile 61 wird der Überarbeitung ein statisches Tag hinzugefügt, das das Git-Kurz-SHA des Deployments angibt:

gcloud beta run services update-traffic ${_SERVICE_NAME} --update-tags=sha-$SHORT_SHA=$${CANARY} --platform managed --region ${_REGION}

Zeile 62 aktualisiert den Traffic, um 90% an die Produktion und 10% an Canary weiterzuleiten:

gcloud run services update-traffic ${_SERVICE_NAME} --to-revisions=$${PROD}=90,$${CANARY}=10 --platform managed --region ${_REGION}

1. Rufen Sie in Cloud Shell die eindeutige URL für die Canary-Überarbeitung ab:

   CANARY_URL=$(gcloud run services describe hello-cloudrun --platform managed --region us-central1 --format=json | jq --raw-output ".status.traffic[] | select (.tag==\"canary\")|.url")
   
   echo $CANARY_URL
   

2. Prüfen Sie den Canary-Endpunkt direkt:

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $CANARY_URL
   

3. Wenn Sie prozentuale Antworten sehen möchten, stellen Sie eine Reihe von Anfragen:

   LIVE_URL=$(gcloud run services describe hello-cloudrun --platform managed --region us-central1 --format=json | jq --raw-output ".status.url")
   for i in {0..20};do
     curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $LIVE_URL; echo \n
   done
   

Freigabe für Produktion

Nachdem das Canary-Deployment mit einer kleinen Teilmenge des Traffics validiert wurde, geben Sie das Deployment für den Rest des Live-Traffics frei.

In diesem Abschnitt richten Sie einen Trigger ein, der aktiviert wird, wenn Sie ein Tag im Repository erstellen. Der Trigger migriert 100 % des Traffics anhand des Commit-SHA des Tags zur bereits bereitgestellten Überarbeitung. Mit dem Commit-SHA wird sichergestellt, dass die mit Canary-Traffic validierte Überarbeitung die für den Rest des Produktionstraffics verwendete Überarbeitung ist.

1. Richten Sie in Cloud Shell den Tag-Trigger ein:

   gcloud alpha builds triggers create github \
     --name=tagtrigger \
     --repository=$REPO_NAME \
     --tag-pattern=. \
     --build-config=labs/cloudrun-progression/tag-cloudbuild.yaml \
     --region=us-central1
   

2. Rufen Sie in der Cloud Console die Cloud Build-Seite „Trigger” auf, um den neuen Trigger zu prüfen.

3. Erstellen Sie in Cloud Shell ein neues Tag und übertragen Sie es per Push in das Remote-Repository:

   git tag 1.1
   git push origin 1.1
   

4. Zum Prüfen des laufenden Builds rufen Sie in der Cloud Console den Cloud Build-Bildschirm zum Build-Verlauf auf.

5. Rufen Sie nach Abschluss des Builds in der Cloud Console die Cloud Run-Seite „Überarbeitungen” auf, um die neue Überarbeitung zu prüfen. Die Überarbeitung wird aktualisiert, um das Produktions-Tag anzugeben. Sie stellt 100 % des Live-Traffics bereit.

6. Stellen Sie in Cloud Shell eine Reihe von Anfragen, um prozentuale Antworten zu sehen:

   LIVE_URL=$(gCloud Run services describe hello-cloudrun --platform managed --region us-central1 --format=json | jq --raw-output ".status.url")
   
   for i in {0..20};do
     curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" $LIVE_URL; echo \n
   done
   

7. Sehen Sie sich die Schlüssel-Zeilen von tag-cloudbuild.yaml an, die die Logik des Produktions-Deployments implementieren.

   Zeile 37 aktualisiert die Canary-Überarbeitung, indem das Produkt-Tag hinzugefügt wird. Die bereitgestellte Überarbeitung ist jetzt sowohl für die Produktion als auch für die Canary-Version getaggt:

   gcloud beta run services update-traffic ${_SERVICE_NAME} --update-tags=prod=$${CANARY} --platform managed --region ${_REGION}
   

   Zeile 39 aktualisiert den Traffic für die Basisdienst-URL, um 100 % des Traffics an die als "prod" getaggte Überarbeitung weiterzuleiten:

   gcloud run services update-traffic ${_SERVICE_NAME} --to-revisions=$${NEW_PROD}=100 --platform managed --region ${_REGION}