Deployment prüfen

In diesem Dokument wird beschrieben, wie Sie eine Cloud Deploy-Bereitstellung prüfen.

Sie können Cloud Deploy und Skaffold konfigurieren, um zu prüfen, ob eine Anwendung, die Sie für ein beliebiges Ziel bereitgestellt haben, ordnungsgemäß funktioniert. Die Prüfung erfolgt mit Ihrem eigenen Test-Image und Sie konfigurieren Cloud Deploy und Skaffold, um diese Tests nach Abschluss der Bereitstellung auszuführen.

Standardmäßig wird die Bereitstellungsprüfung in der Ausführungsumgebung von Cloud Deploy ausgeführt. Sie können sie aber auch so konfigurieren, dass sie im selben Cluster ausgeführt wird, in dem die Anwendung ausgeführt wird.

Wie funktioniert die Überprüfung der Bereitstellung?

  1. Sie configure Skaffold für die Überprüfung.

    Diese Konfiguration identifiziert das Container-Image bzw. die Container-Images, die zum Ausführen von Tests verwendet werden sollen, sowie die spezifischen Befehle (z. B. ein Skript), die von diesem Container-Image ausgeführt werden sollen.

  2. Sie configure ein oder mehrere Ziele in Ihrer Bereitstellungspipeline für die Überprüfung der Bereitstellung.

    Diese Konfiguration ermöglicht die Überprüfung von Arbeitslasten, die an diesem Ziel bereitgestellt werden.

  3. Nachdem ein Roll-out bereitgestellt wurde (skaffold apply), führt Cloud Deploy den Befehl skaffold verify in der Cloud Deploy-Ausführungsumgebung aus.

    Bei Bereitstellungen in Google Kubernetes Engine und GKE Enterprise können Sie den Verifizierungscontainer optional in demselben Cluster ausführen, in dem der Anwendungscontainer ausgeführt wird.

  4. Skaffold ruft den Test oder die Tests auf, die in der verify-Stanza Ihrer skaffold.yaml angegeben sind, um für die bereitgestellte Anwendung auszuführen.

  5. Erfolg oder Misserfolg der ausgeführten Tests weist auf Erfolg oder Misserfolg der Überprüfung hin.

    • Der Erfolg der Bestätigung wird durch den Exit-Code des ausgeführten Containers bestimmt.

      0 zeigt eine erfolgreiche Ausführung an. Ein Exit-Code ungleich null weist auf einen Fehler hin. Damit das gewünschte Bestätigungsergebnis generiert wird, muss der Container mit dem entsprechenden Exit-Code beendet werden. Wenn im Rahmen der Überprüfung mehr als ein Container ausgeführt wird, müssen alle erfolgreich sein, damit die Überprüfung erfolgen kann.

    • Wenn die Bestätigung fehlschlägt, schlägt auch die Einführung fehl.

    • Wenn eine Bereitstellung während der Überprüfung fehlschlägt, können Sie dies durch Prüfen des Roll-outs sehen:

      Details in der Google Cloud Console für die Einführung, einschließlich Bestätigungsstatus

  6. Sie können eine fehlgeschlagene Überprüfung ignore oder wiederholen.

    Sie können auch einen laufenden Überprüfungsjob beenden.

Für die Überprüfung verwendete Komponenten

Die rollout-Ressource enthält die folgenden Objekte, die eine Überprüfung der Bereitstellung unterstützen:

  • Phase

    Die Sammlung von Vorgängen (Jobs) in einem Roll-out, die logisch gruppiert sind, z. B. eine Bereitstellung oder eine Bereitstellung und Überprüfung.

  • Job

    Der spezifische Vorgang, der bei einem Roll-out ausgeführt werden soll, z. B. „Bereitstellen“ oder „Verifizieren“.

  • Jobausführung

    Der Job ist der Roll-out-Ressource untergeordnet und eine Instanz eines Jobs, z. B. ein Bereitstellungsversuch.

Weitere Informationen zu Cloud Deploy-Ressourcen finden Sie unter Cloud Deploy-Dienstarchitektur.

Durch die Bereitstellungsüberprüfung generierte Benachrichtigungen

Cloud Deploy generiert Pub/Sub-Nachrichten und veröffentlicht sie für die folgenden Ereignisse:

  • Jobausführung erstellen, aktualisieren und löschen

    Diese Benachrichtigungen werden im Thema clouddeploy-resources veröffentlicht und enthalten die folgenden Attribute:

    • Resource
    • ResourceType (JobRun)
    • Action (Create, Update, Delete)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId

Das folgende Beispiel zeigt eine Pub/Sub-Nachricht für eine Jobausführung, die im Thema clouddeploy-resources veröffentlicht wird:

{
    "ackId": "UAYWLF1GSFE3GQhoUQ5PXiM_NSAoRRAGAE8CKF15MFcrQVh9Dz4NGXJ9YXRiWRIJBkUHeF9cEQ1iXE5EB0nq0KDVV1dKXxYGAExQeVhbHQVoWVh0Bnn7h5nK-8HjYwk9OqKarPdtO4PY2fNHZiI9XhJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FU0Q",
    "message": {
      "attributes": {
        "Action": "Create",
        "DeliveryPipelineId": "dv-pipeline",
        "JobRunId": "634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "Location": "us-central1",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-100",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-100/rollouts/test-release-100-to-dev-0001/jobRuns/634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-100-to-dev-0001"
      },
      "messageId": "5572937706805411",
      "publishTime": "2022-09-07T14:00:46.040Z"
    }
  },

  • Jobausführung starten, erfolgreich und fehlgeschlagen

    Diese Benachrichtigungen werden im Thema clouddeploy-operations veröffentlicht und enthalten die folgenden Attribute:

    • Resource
    • ResourceType (JobRun)
    • Action (Start, Succeed, Failure)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId
    • PhaseId
    • JobId
    • JobType (Deploy oder Verify)

Das folgende Beispiel zeigt eine Pub/Sub-Nachricht für eine fehlgeschlagene Jobausführung, die im Thema clouddeploy-operations veröffentlicht wurde:

{
    "ackId": "RFAGFixdRkhRNxkIaFEOT14jPzUgKEUUBAgUBXx9cEFPdVhec2hRDRlyfWB9aVsbCAUXU3cJURsHaE5tdR-6xcvaS0NVb18UAgRFWndfXhMEblhfcy-fkK3HwvT9U0AvOemNgdZpe6jHiulvZiM9XxJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FUw",
    "message": {
      "attributes": {
        "Action": "Failure",
        "DeliveryPipelineId": "dv-pipeline",
        "JobId": "verify",
        "JobRunId": "b389224a-c259-4a00-ab75-c22e48bc3136",
        "JobType": "Verify",
        "Location": "us-central1",
        "PhaseId": "stable",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-101",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-101/rollouts/test-release-101-to-dev-0001/jobRuns/b389224a-c259-4a00-ab75-c22e48bc3136",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-101-to-dev-0001",
        "TargetId": "dev"
      },
      "messageId": "5573609905896436",
      "publishTime": "2022-09-07T15:35:37.906Z"
    }
  },

Cloud Deploy für die Überprüfung der Bereitstellung konfigurieren

Wenn Sie die Bereitstellungsprüfung für ein Cloud Deploy-Ziel aktivieren, wird einem oder mehreren bestimmten Zielen in der Abfolge der Bereitstellungspipeline ein Attribut verify: true hinzugefügt, wie in diesem Beispiel gezeigt:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify: true
 - targetId: prod
   profiles: []
   strategy:
     standard:
       verify: false

In dieser Konfiguration ist die Überprüfung der Bereitstellung für das Ziel dev aktiviert, aber nicht für das Ziel prod. verify: false entspricht dem Weglassen der Property verify oder der gesamten strategy-Stanza.

Der Überprüfungsvorgang wird in seiner eigenen Ausführungsumgebung ausgeführt. Diese Ausführungsumgebung kann für VERIFY genauso konfiguriert werden wie für RENDER und DEPLOY.

Skaffold für die Deployment-Überprüfung konfigurieren

Zum Aktivieren der Bereitstellungsprüfung für ein Ziel ist eine verify-Stanza in der Konfigurationsdatei skaffold.yaml für Ihre Bereitstellung erforderlich. Diese Konfiguration kann für ein bestimmtes Skaffold-Profil gelten, wenn Sie separate Profile pro Ziel verwenden.

Diese verify-Stanza identifiziert einen Container, der für die Überprüfung ausgeführt werden soll, z. B. einen Integrationstest.

Das folgende Beispiel zeigt eine skaffold.yaml-Datei mit einer verify-Stanza:

apiVersion: skaffold/v4beta7
kind: Config
build:
  artifacts:
    - image: integration-test
      context: integration-test
manifests:
  rawYaml:
  - kubernetes.yaml
deploy:
  kubectl: {}
verify:
- name: verify-integration-test
  container:
    name: integration-test
    image: integration-test
    command: ["./test-systems.sh"]
- name: verify-endpoint-test
  container:
    name: alpine
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "wget #ENDPOINT_URL"]

Dieses einfache Beispiel zeigt eine verify-Stanza, die einen zu verwendenden Container identifiziert, und ein Testskript, das in diesem Container ausgeführt wird. #ENDPOINT_URL in diesem Beispiel ist nur ein Platzhalter für Ihre Anwendungs-URL und keine verfügbare Cloud Deploy-Umgebungsvariable.

Überprüfungscontainer im Anwendungscluster ausführen

Die Bereitstellungsprüfung wird standardmäßig in der Ausführungsumgebung von Cloud Deploy ausgeführt. Sie können Skaffold auch so konfigurieren, dass der Überprüfungscontainer in demselben Cluster ausgeführt wird, in dem Ihre Anwendung ausgeführt wird. Wenn Sie die clusterinterne Überprüfung in skaffold.yaml konfigurieren und die Überprüfung für ein Ziel aktivieren, wird die Überprüfung automatisch im Cluster dieses Ziels ausgeführt.

Diese Funktion ist nur für Deployments in GKE und GKE Enterprise verfügbar, nicht für Cloud Run. Bei Bereitstellungen in Cloud Run kann die Überprüfung nur in der Cloud Deploy-Ausführungsumgebung ausgeführt werden.

Für die Überprüfung im Cluster ist Skaffold-Version 2.3 oder höher erforderlich.

Zum Ausführen des Überprüfungscontainers im Cluster fügen Sie in die Konfigurationsdatei skaffold.yaml in der verify-Stanza für den jeweiligen Bestätigungscontainer eine executionMode.kubernetesCluster-Stanza ein:

verify:
- name: 
  container:
    name: 
    image: 
    command: 
    args: 
  executionMode:
    kubernetesCluster:

Das folgende Beispiel zeigt eine Überprüfungs-Stanza, die executionMode enthält, um den Verifizierungscontainer im Anwendungscluster aufzurufen:

verify:
- name: integration-test-container
  container:
    name: integration-test-container
    image: integration-test-container
  executionMode:
    kubernetesCluster: {}

Die Stanza executionMode ist optional. Wenn Sie sie weglassen, führt Skaffold den Verifizierungscontainer in der Cloud Deploy-Ausführungsumgebung aus.

Bestätigung wiederholen

Wenn ein Überprüfungsjob fehlschlägt, können Sie die Überprüfung wiederholen und eine neue Jobausführung erstellen:

gcloud deploy rollouts retry-job ROLLOUT_NAME \
             --job-id=JOB_ID \
             --phase-id=PHASE_ID \
             --delivery-pipeline=PIPELINE_NAME \
             --release=RELEASE_NAME \
             --region=REGION

Wenn Sie die Bestätigung wiederholen, wird der Status des Roll-outs von FAILED in IN_PROGRESS geändert.

Sie können die Bestätigung nur für ein Roll-out wiederholen, dessen Prüfjob fehlgeschlagen ist.

Verfügbare Umgebungsvariablen

Cloud Deploy stellt die folgenden Umgebungsvariablen in der Ausführungsumgebung VERIFY bereit, die Sie für Ihre Tests verwenden können, und fügt sie automatisch ein:

  • ANTHOS_MEMBERSHIP

    Für Ziele vom Typ ANTHOS der vollständig angegebene Ressourcenname der Anthos-Mitgliedschaft.

  • CLOUD_RUN_LOCATION

    Bei Zielen vom Typ RUN ist die Region, in der der Cloud Run-Dienst bereitgestellt wird.

  • CLOUD_RUN_PROJECT

    Für Ziele vom Typ RUN das Projekt, in dem der Cloud Run-Dienst erstellt wurde.

  • CLOUD_RUN_SERVICE

    Für Ziele vom Typ RUN der vollständig angegebene Ressourcenname des bereitgestellten Cloud Run-Dienstes, z. B. projects/p/locations/us-central1/services/dev.

  • CLOUD_RUN_SERVICE_URLS

    Für Ziele vom Typ RUN die URL oder URLs (durch Kommas getrennte Liste), über die Endnutzer auf Ihren Dienst zugreifen. Sie finden diese in den Details zum Cloud Run-Dienst für Ihren Dienst in der Google Cloud Console.

  • CLOUD_RUN_REVISION

    Für Ziele vom Typ RUN die spezifische Version des Cloud Run-Dienstes.

  • GKE_CLUSTER

    Für Ziele vom Typ GKE der vollständig angegebene Ressourcenname des Google Kubernetes Engine-Clusters, z. B. projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Der spezifische Laufzeittyp des Ziels. GKE, ANTHOS oder RUN.

  • CLOUD_DEPLOY_LOCATION

    Die Region, in der die Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Die ID-Bereitstellungspipeline, die in der Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_TARGET

    Die ID des Ziels, das von der Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_PROJECT

    Die Projektnummer des Google Cloud-Projekts, in dem die Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_RELEASE

    Die ID des Release, in dem die Überprüfung ausgeführt wird.

  • CLOUD_DEPLOY_ROLLOUT

    Die ID des Roll-outs, das die zu überprüfenden Jobs enthält.

  • CLOUD_DEPLOY_JOB_RUN

    Die ID der Jobausführung, die der aktuellen Ausführung des Jobs entspricht.

  • CLOUD_DEPLOY_PHASE

    Die Phase im Roll-out, die den zu überprüfenden Job enthält.