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 für die Ausführung im selben Cluster konfigurieren wo die Anwendung ausgeführt wird.

Wie funktioniert die Überprüfung der Bereitstellung?

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

    Diese Konfiguration identifiziert das Container-Image oder die Container-Images, die zum Ausführen verwendet werden sollen Tests und den spezifischen Befehlen (z. B. Skript), die von dieser Container-Image.

  2. Sie konfigurieren ein oder mehrere Ziele für die Auslieferung zur Überprüfung der Bereitstellung.

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

  3. Nachdem ein Roll-out bereitgestellt wurde (skaffold apply), wird Cloud Deploy ausgeführt Das skaffold verify in der Cloud Deploy-Ausführungsumgebung verwenden.

    Bei Bereitstellungen in Google Kubernetes Engine und GKE Enterprise können Sie optional Überprüfungscontainer im selben Cluster ausführen, in dem sich die Anwendung befindet Container ausgeführt wird.

  4. Skaffold ruft den Test oder die Tests auf, die in der verify-Stanza Ihrer skaffold.yaml, 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. Zum Generieren gewünschtes Bestätigungsergebnis erhalten, achten Sie darauf, dass der Container entsprechenden Exit-Code. 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 sehen, indem Sie die Einführung:

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

  6. Sie können ignorieren. oder wiederholen Sie eine fehlgeschlagene Bestätigung.

    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 „Verifizieren“.

  • Jobausführung

    Der Job ist der Roll-out-Ressource untergeordnet. Die Jobausführung ist eine Jobinstanz, für einen 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 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 Überprüfung der Bereitstellung konfigurieren

Das Aktivieren der Bereitstellungsprüfung für ein Cloud Deploy-Ziel besteht aus beim Hinzufügen einer verify: true-Property an ein oder mehrere Ziele in der Entwicklung der Bereitstellungspipeline gesendet werden, wie in dieses Beispiel:

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

Zum Aktivieren der Deployment-Überprüfung für ein Ziel ist eine verify-Stanza in Die Konfigurationsdatei skaffold.yaml für Ihre Bereitstellung. 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. ein 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. Sie identifizieren einen zu verwendenden Container und ein Testskript, das in diesem Container ausgeführt werden soll. #ENDPOINT_URL ist in diesem Beispiel nur ein Platzhalter für Ihre Anwendungen. URL und ist keine verfügbare Cloud Deploy-Umgebungsvariable.

Überprüfungscontainer im Anwendungscluster ausführen

Standardmäßig wird die Deployment-Überprüfung in Cloud Deploy ausgeführt Ausführungsumgebung aus. Sie können auch Skaffold so konfigurieren, dass der Überprüfungscontainer auf 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 für Deployments in GKE und Nur GKE Enterprise, nicht für Cloud Run. Bereitstellungen in Cloud Run kann die Überprüfung nur in der Cloud Deploy-Ausführungsumgebung

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

Durch Wiederholen der Bestätigung ändert sich der Status des Roll-outs von FAILED zu 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 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

    Bei Zielen vom Typ RUN die URL oder URLs (durch Kommas getrennte Liste), die enden die Nutzer verwenden, um auf Ihren Dienst zuzugreifen. 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 .

  • GKE_CLUSTER

    Bei Zielen vom Typ GKE ist der vollständig angegebene Ressourcenname der Google Kubernetes Engine-Cluster, 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 der Job.

  • CLOUD_DEPLOY_PHASE

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