Bereitstellung prüfen

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

Sie können Cloud Deploy und Skaffold so konfigurieren, dass geprüft wird, ob eine Anwendung, die Sie auf einem beliebigen Ziel bereitgestellt haben, ordnungsgemäß funktioniert. Die Überprüfung erfolgt mit Ihrem eigenen Test-Image. Sie konfigurieren Cloud Deploy und Skaffold so, dass diese Tests nach Abschluss der Bereitstellung ausgeführt werden.

Die Bereitstellungsüberprüfung wird standardmäßig 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 Bereitstellungsüberprüfung?

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

    In dieser Konfiguration wird das Container-Image (oder die Container-Images) angegeben, das zum Ausführen von Tests verwendet werden soll, sowie die spezifischen Befehle (z. B. ein Skript), die aus diesem Container-Image ausgeführt werden sollen.

    Sie können mehrere Container-Images angeben. Wenn Sie mehrere Container angeben, werden sie parallel und nicht sequenziell ausgeführt.

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

    Diese Konfiguration aktiviert die Überprüfung für Arbeitslasten, 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 Google Kubernetes Engine und GKE Enterprise können Sie den oder die Verifikationscontainer optional im selben Cluster ausführen, in dem der Anwendungscontainer ausgeführt wird.

  4. Skaffold ruft die im verify-Abschnitt Ihres skaffold.yaml angegebenen Tests auf, die für die bereitgestellte Anwendung ausgeführt werden sollen.

  5. Der Erfolg oder Misserfolg der ausgeführten Tests gibt an, ob die Überprüfung erfolgreich war oder fehlgeschlagen ist.

    • Ob die Überprüfung erfolgreich ist, hängt vom Exitcode des ausgeführten Containers ab.

      0 weist auf einen Erfolg hin. 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 mehrere Container ausgeführt werden, müssen alle erfolgreich ausgeführt werden, damit die Überprüfung erfolgreich ist.

    • Wenn die Überprüfung fehlschlägt, schlägt auch die Einführung fehl.

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

      Details zum Roll-out in der Google Cloud Console, einschließlich des Bestätigungsstatus

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

    Sie können einen laufenden Bestätigungsjob auch beenden.

Für die Überprüfung verwendete Komponenten

Die Rollout-Ressource enthält die folgenden Objekte, die die Bereitstellungsüberprüfung unterstützen:

  • Phase

    Die Sammlung von Vorgängen (Jobs) in einem Rollout, die logisch gruppiert sind, z. B. ein Deployment oder ein Deployment und eine Überprüfung.

  • Job

    Der spezifische Vorgang, der für einen Roll-out ausgeführt werden soll, z. B. „deploy“ (bereitstellen) oder „verify“ (bestätigen).

  • Jobausführung

    Der Joblauf ist ein untergeordnetes Element der Rollout-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 die folgenden Ereignisse:

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

Im Folgenden finden Sie ein Beispiel für eine Pub/Sub-Nachricht für die Erstellung eines Joblaufs, 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)

Im Folgenden finden Sie ein Beispiel für eine Pub/Sub-Nachricht für einen fehlgeschlagenen Joblauf, 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 Bereitstellungsprüfung konfigurieren

Wenn Sie die Bereitstellungsüberprüfung für ein Cloud Deploy-Ziel aktivieren möchten, müssen Sie einer bestimmten Ziel- oder Zielgruppe in einer Bereitstellungspipeline-Progression die verify: true-Property hinzufügen, 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 Bereitstellungsüberprüfung für das Ziel dev aktiviert, nicht aber für das Ziel prod. verify: false entspricht dem Weglassen des Attributs verify oder der gesamten strategy-Stanza.

Der Bestätigungsvorgang wird in einer 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 Bereitstellungsprüfung konfigurieren

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

Dieser verify-Abschnitt gibt einen oder mehrere Container an, die für die Überprüfung ausgeführt werden sollen, z. B. Integrationstests. Wenn Sie mehrere Container angeben, werden sie parallel und nicht sequenziell ausgeführt.

Das folgende Beispiel zeigt ein skaffold.yaml-Objekt 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"]

In diesem Beispiel wird ein verify-Abschnitt gezeigt, der einen zu verwendenden Container und ein in diesem Container auszuführendes Testskript angibt. #ENDPOINT_URL ist in diesem Beispiel nur ein Platzhalter für die URL Ihrer Anwendungen und keine verfügbare Cloud Deploy-Umgebungsvariable.

Überprüfungscontainer im Anwendungscluster ausführen

Die Bereitstellungsprüfung wird standardmäßig in der Cloud Deploy-Ausführungsumgebung ausgeführt. Sie können Skaffold auch so konfigurieren, dass der oder die Überprüfungscontainer im selben Cluster wie Ihre Anwendung ausgeführt werden. Wenn Sie die In-Cluster-Ü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 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 erfolgen.

Wenn Sie Ihre Bestätigungscontainer im Cluster ausführen möchten, fügen Sie in der Konfigurationsdatei skaffold.yaml im Abschnitt verify für den jeweiligen Bestätigungscontainer einen executionMode.kubernetesCluster-Abschnitt ein:

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

Das folgende Beispiel zeigt einen Verify-Abschnitt, der executionMode enthält, um den Bestätigungscontainer im Anwendungscluster aufzurufen:

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

Der executionMode-Abschnitt ist optional. Wenn Sie ihn weglassen, führt Skaffold die Überprüfungscontainer in der Cloud Deploy-Ausführungsumgebung aus.

Bestätigung wiederholen

Wenn ein Bestätigungsjob fehlschlägt, können Sie die Bestätigung noch einmal versuchen und einen neuen Joblauf 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 zu IN_PROGRESS.

Sie können die Überprüfung nur für einen Roll-out wiederholen, dessen Überprüfungsjob fehlgeschlagen ist.

Verfügbare Umgebungsvariablen

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

  • ANTHOS_MEMBERSHIP

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

  • CLOUD_RUN_LOCATION

    Für Ziele vom Typ RUN 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 Cloud Run-Dienstdetails für Ihren Dienst in derGoogle Cloud -Konsole.

  • CLOUD_RUN_REVISION

    Für Ziele des Typs RUN die spezifische Revision des Cloud Run-Dienstes.

  • GKE_CLUSTER

    Für Ziele vom Typ GKE ist das 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 der Bereitstellungspipeline, in der die Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_TARGET

    Die ID des Ziels, auf dem die Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_PROJECT

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

  • CLOUD_DEPLOY_PROJECT_ID

    Die Projekt-ID des Projekts, das die Cloud Deploy-Ressourcen enthält. Google Cloud

  • CLOUD_DEPLOY_RELEASE

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

  • CLOUD_DEPLOY_ROLLOUT

    Die ID des Rollouts, der die zu überprüfenden Jobs enthält.

  • CLOUD_DEPLOY_JOB_RUN

    Die ID des Joblaufs, der die aktuelle Ausführung des Jobs darstellt.

  • CLOUD_DEPLOY_PHASE

    Die Phase der Einführung, die den zu überprüfenden Job enthält.

Parameter als Umgebungsvariablen bereitstellen

Zusätzlich zu den in diesem Abschnitt aufgeführten Umgebungsvariablen kann Cloud Deploy alle von Ihnen festgelegten Bereitstellungsparameter an Ihre benutzerdefinierten Container übergeben.

Weitere Informationen