Deployment 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 Sie prüfen können, ob eine Anwendung, die Sie auf ein beliebiges 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.

Standardmäßig wird die Bereitstellungsüberprüfung in der Cloud Deploy-Ausführungsumgebung ausgeführt. Sie können sie aber auch so konfigurieren, dass sie in demselben 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 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 dieses 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. Der Erfolg oder Misserfolg der ausgeführten Tests gibt Aufschluss über den Erfolg oder Misserfolg der Überprüfung.

    • Ob die Überprüfung erfolgreich war, wird durch den Exit-Code des ausgeführten Containers bestimmt.

      0 steht für Erfolg. Ein Exit-Code ungleich null weist auf einen Fehler hin. Damit das gewünschte Ergebnis der Überprüfung 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 sein, damit die Überprüfung erfolgreich ist.

    • Wenn die Überprüfung fehlschlägt, schlägt auch das Roll-out fehl.

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

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

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

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

Für die Überprüfung verwendete Komponenten

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

  • Phase

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

  • Job

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

  • Jobausführung

    Die Jobausführung ist eine Instanz eines Jobs und ist der Roll-out-Ressource untergeordnet. Sie kann beispielsweise ein Bereitstellungsversuch sein.

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:

  • Jobausführungen 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"
    }
  },

  • Start, Erfolg und Fehler bei der Jobausführung

    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 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 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 Bereitstellungsüberprüfung 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 Vorgang „verify“ 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 Bereitstellungsüberprü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.

In diesem verify-Abschnitt wird ein Container angegeben, 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-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 in diesem Beispiel ist 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 Bereitstellungsüberprüfung in der Cloud Deploy-Ausführungsumgebung ausgeführt. 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 In-Cluster-Bestätigung in skaffold.yaml konfigurieren und die Bestätigung für ein Ziel aktivieren, wird die Bestätigung 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.

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

Wenn Sie den Bestätigungscontainer im Cluster ausführen möchten, fügen Sie in der Konfigurationsdatei skaffold.yaml in der Strophe verify für den jeweiligen Bestätigungscontainer eine Strophe vom Typ executionMode.kubernetesCluster ein:

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

Im folgenden Beispiel wird ein Verify-Abschnitt mit executionMode verwendet, um den Bestätigungscontainer im Anwendungscluster aufzurufen:

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 Bestätigungscontainer in der Cloud Deploy-Ausführungsumgebung aus.

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 eine Überprüfung nur für ein Roll-out noch einmal versuchen, bei dem der Überprüfungsjob fehlgeschlagen ist.

Verfügbare Umgebungsvariablen

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

  • ANTHOS_MEMBERSHIP

    Bei Zielen vom Typ ANTHOS ist dies 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

    Bei Zielen vom Typ RUN das Projekt, in dem der Cloud Run-Dienst erstellt wurde.

  • CLOUD_RUN_SERVICE

    Bei Zielen 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 sie in derGoogle Cloud -Konsole in den Cloud Run-Dienstdetails für Ihren Dienst.

  • 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. Entweder GKE, ANTHOS oder RUN.

  • CLOUD_DEPLOY_LOCATION

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

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Die ID-Auslieferungspipeline, die in der 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 Projekts, Google Cloud in dem die Ausführungsumgebung ausgeführt wird.

  • CLOUD_DEPLOY_PROJECT_ID

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

  • 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 Jobs für die Überprüfung enthält.

  • CLOUD_DEPLOY_JOB_RUN

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

  • 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 kann Cloud Deploy alle von Ihnen festgelegten Bereitstellungsparameter an Ihre benutzerdefinierten Container übergeben.

Weitere Informationen