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, die Sie für ein beliebiges Ziel bereitgestellt haben, funktionieren wie vorgesehen. Die Überprüfung erfolgt mit Ihrem eigenen Test-Image und Sie konfigurieren Cloud Deploy und Skaffold zum Ausführen dieser Tests nach der Bereitstellung beendet.

Standardmäßig wird die Deployment-Überprüfung in Cloud Deploy ausgeführt Ausführungsumgebung, Sie können aber auch konfigurieren Sie es so, dass es im selben Cluster ausgeführt wird. wo die Anwendung ausgeführt wird.

Wie funktioniert die Bereitstellungsüberprüfung?

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

    In dieser Konfiguration werden das oder die Container-Images für die Ausführung von Tests und die spezifischen Befehle (z. B. ein Script) angegeben, die über dieses Container-Image ausgeführt werden sollen.

  2. Sie konfigurieren ein oder mehrere Ziele in Ihrer Bereitstellungspipeline für die Bereitstellungsüberprüfung.

    Mit dieser Konfiguration wird die Überprüfung für Arbeitslasten aktiviert, die auf 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 der Google Kubernetes Engine und GKE Enterprise können Sie den Bestätigungscontainer optional in demselben Cluster ausführen, in dem der Anwendungscontainer ausgeführt wird.

  4. Skaffold ruft die im verify-Abschnitt Ihrer skaffold.yaml angegebenen Tests auf, um sie für die bereitgestellte Anwendung auszuführen.

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

    • Ob die Überprüfung erfolgreich war, 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 Überprüfungsergebnis 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 der Roll-out fehl.

    • Wenn eine Bereitstellung während der Überprüfung fehlschlägt, können Sie dies sehen, indem Sie die Einführung:

      Details zum Roll-out in der Google Cloud Console, einschließlich Überprüfungsstatus

  6. Sie können eine fehlgeschlagene Bestätigung ignorieren oder noch einmal versuchen.

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

Für die Überprüfung verwendete Komponenten

Die rollout-Ressource enthält die folgenden Objekten, die die Deployment-Überprüfung unterstützen:

  • Phase

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

  • Job

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

  • Jobausführung

    Die Jobausführung ist eine untergeordnete Ressource der Roll-out-Ressource und eine Instanz eines Jobs, z. B. ein Bereitstellungsversuch.

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

Von der Bereitstellungsüberprüfung generierte Benachrichtigungen

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

  • Jobausführung erstellen, aktualisieren und löschen

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

    • 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 erstellen, veröffentlicht im Thema clouddeploy-resources:

{
    "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 die folgenden Attribute enthalten:

    • 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 einen fehlgeschlagenen Job ausgeführt, im Thema clouddeploy-operations veröffentlicht:

{
    "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 Bereitstellungsüberprüfung konfigurieren

Wenn Sie die Bereitstellungsüberprüfung für ein Cloud Deploy-Ziel aktivieren möchten, fügen Sie einem bestimmten Ziel oder mehreren Zielen in einer Bereitstellungspipeline eine verify: true-Property hinzu, 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 auf das Ziel prod. verify: false entspricht dem Weglassen von verify-Property oder die gesamte strategy-Stanza.

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

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

Wenn Sie die Bereitstellungsüberprüfung für ein Ziel aktivieren möchten, ist in der skaffold.yaml-Konfigurationsdatei für die Bereitstellung ein verify-Abschnitt erforderlich. Diese Konfiguration kann für ein bestimmtes Skaffold-Profil gelten, wenn Sie separate Profile pro Ziel.

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-Strophe:

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-Strophe, in der ein zu verwendender Container und ein Testscript angegeben werden, das in diesem Container ausgeführt werden soll. #ENDPOINT_URL ist in diesem Beispiel nur ein Platzhalter für die URL Ihrer Anwendung und keine verfügbare Cloud Deploy-Umgebungsvariable.

Bestätigungscontainer im Anwendungscluster ausführen

Standardmäßig wird die Deployment-Überprüfung in Cloud Deploy ausgeführt Ausführungsumgebung aus. Sie können Skaffold auch so konfigurieren, dass der Bestätigungscontainer in demselben Cluster ausgeführt wird, in dem Ihre Anwendung ausgeführt wird. Wenn Sie die clusterinterne Überprüfung in skaffold.yaml und aktivieren Sie die Überprüfung für ein Ziel, wird sie automatisch im Cluster dieses Ziels ausgeführt.

Diese Funktion ist nur für Bereitstellungen 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.

Clusterinterne Überprüfung erfordert Skaffold-Version 2.3 oder höher.

Fügen Sie zum Ausführen des Überprüfungscontainers im Cluster Folgendes ein: executionMode.kubernetesCluster Stanza in Ihrer skaffold.yaml-Konfiguration -Datei in der verify-Stanza für den jeweiligen Bestätigungscontainer an:

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

Im Folgenden finden Sie ein Beispiel für eine Stanza, die executionMode enthält, um Rufen Sie den Verifizierungscontainer im Anwendungscluster auf:

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

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

Bestätigung wiederholen

Wenn ein Überprüfungsjob fehlschlägt, können Sie die Überprüfung noch einmal ausführen, indem Sie einen neuen Job 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 Überprüfung noch einmal versuchen, ändert sich der Status des Roll-outs von FAILED in IN_PROGRESS.

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 folgende Umgebung bereit und fügt sie ein Variablen in der Ausführungsumgebung von VERIFY die Sie für Ihre Tests verwenden können:

  • ANTHOS_MEMBERSHIP

    Bei Zielen vom Typ ANTHOS ist dies der vollständig angegebene Ressourcenname der Anthos-Mitgliedschaft.

  • CLOUD_RUN_LOCATION

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

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Für Ziele vom Typ RUN ist der vollständig angegebene Ressourcenname der bereitgestellten Cloud Run-Dienst, 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. Diese finden Sie in der Details zum Cloud Run-Dienst für Ihren Dienst im Google Cloud Console

  • CLOUD_RUN_REVISION

    Für Ziele vom Typ RUN die spezifische Version von Cloud Run Service.

  • GKE_CLUSTER

    Bei Zielen vom Typ GKE ist dies 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. Entweder 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 der Version, in der 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 der Job.

  • CLOUD_DEPLOY_PHASE

    Die Phase im Roll-out, die den Job zur Überprüfung enthält.

Parameter als Umgebungsvariablen bereitstellen

Zusätzlich zu den in diesem Abschnitt aufgeführten Umgebungsvariablen Cloud Deploy kann beliebige Werte an Ihre benutzerdefinierten Container übergeben Parameter bereitstellen, die Sie festgelegt haben.

Weitere Informationen