Bereitstellung prüfen

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

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

Wie funktioniert die Bereitstellungsüberprüfung?

  1. Sie konfigurieren ein oder mehrere Ziele in Ihrer Bereitstellungspipeline für die Bereitstellungsüberprüfung, indem Sie Aufgaben definieren, die ausgeführt werden sollen.

  2. Nachdem eine Anwendung bereitgestellt wurde, führt Cloud Deploy die Prüfaufgaben in der Cloud Deploy-Ausführungsumgebung aus.

    Der Erfolg oder Misserfolg der ausgeführten Tests gibt den Erfolg oder Misserfolg der Überprüfung an:

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

      0 weist auf einen Erfolg hin. Ein Exit-Code ungleich null weist auf einen Fehler hin. Damit das erwartete Bestätigungsergebnis generiert wird, muss der Container mit dem entsprechenden Exit-Code beendet werden. Wenn im Rahmen der Bestätigung mehrere Container ausgeführt werden, müssen alle erfolgreich ausgeführt werden, damit die Bestätigung 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

  3. Sie können eine fehlgeschlagene Bestätigung ignorieren 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 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“ (überprüfen).

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

Cloud Deploy für die Bereitstellungsprüfung konfigurieren

Um die Bereitstellungsüberprüfung für ein Cloud Deploy-Ziel zu aktivieren, fügen Sie einer bestimmten Ziel- oder Zielgruppe in einer Delivery-Pipeline-Progression eine verify-Stanza 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:
         tasks:
         - type: container
           image: "VERIFY_IMAGE"
           command: [COMMANDS_TO_RUN]
           args: [LIST_OF_ARGS]
           env: {VERIFY_TASK_ENV_MAP}

In diesem YAML-Code:

  • VERIFY_IMAGE

    Ist der Name des Images, das Sie für den Prüfjob ausführen möchten. Beispiel: us-central1-docker.pkg.dev/gcp-project-id-12345/my-repository/my-app:v1.2 für ein Artifact Registry-Image.

  • COMMANDS_TO_RUN

    Eine Liste der Einstiegspunkte, die in diesem Container ausgeführt werden sollen. "/bin/sh" ist ein typischer Befehl, der hier angegeben wird, um eine Shell aufzurufen.

  • LIST_OF_ARGS

    Eine Liste von Argumenten, die dem Befehl übergeben werden sollen. Dies ist eine durch Kommas getrennte Liste, wobei jedes Argument in Anführungszeichen gesetzt ist. Wenn Ihr COMMAND_TO_RUN "/bin/sh" ist, wäre eines der Argumente hier "-c" und ein anderes Argument wäre der gesamte Befehl, den Sie in der Shell ausführen möchten, die Sie aufrufen.

    Beispiel:

    command: ["/bin/sh"]
    args: ["-c", `echo "This command ran!"`]
    
  • VERIFY_TASK_ENV_MAP

    Eine Zuordnung von Umgebungsvariablen, die im Format KEY:VAL an den Container übergeben werden.

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

Überprüfung für den 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 die Überprüfung im selben Cluster ausgeführt wird, in dem Ihre Anwendung ausgeführt wird.

Damit Ihre Verifizierungscontainer im Cluster ausgeführt werden können, müssen Sie die Verifizierungscontainer im verify-Abschnitt in Ihrer skaffold.yaml konfigurieren. Für jeden definierten Container müssen Sie auch executionMode.kubernetesCluster festlegen.

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: {}

Außerdem müssen Sie die verify-Stanza in der Konfiguration Ihrer Bereitstellungspipeline auf true setzen.

Im Folgenden finden Sie ein Beispiel für die Definition einer Bereitstellungspipeline, bei der die Überprüfung für das Ziel dev aktiviert ist.

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

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

Bei parallelen Bereitstellungen wird die Bestätigung für das Multi-Ziel konfiguriert und die Bestätigungscontainer werden für jedes untergeordnete Ziel ausgeführt.

Sie können auch die Attribute jobManifestPath und overrides unter kubernetesCluster einfügen, um auf ein Manifest für Ihren Verify-Container zu verweisen und alle Werte anzugeben, die Sie überschreiben möchten. (overrides verwendet Kubernetes-Inline-JSON mit den Werten, die Sie ersetzen möchten.) Weitere Informationen

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 Überprüfungsjob fehlschlägt, können Sie die Überprüfung wiederholen. Dadurch wird ein neuer Joblauf erstellt:

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 außerdem die folgenden Umgebungsvariablen in der Ausführungsumgebung bereit und füllt sie aus. Sie können diese Umgebungsvariablen als Teil Ihres Bereitstellungshooks, Bestätigungsjobs oder benutzerdefinierten Zielrenders oder ‑bereitstellung verwenden.

  • 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 Name des bereitgestellten Cloud Run-Dienstes.

  • 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. Die URLs werden von Cloud Run generiert, nachdem Ihr Cloud Run-Dienst oder Ihre Cloud Run-Dienste erfolgreich bereitgestellt wurden. Daher ist diese Umgebungsvariable nur in Post-Deploy-Hooks und Bestätigungsjobs verfügbar.

  • 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 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. Bei benutzerdefinierten Zielvorhaben wird dieser Wert nicht festgelegt.

  • CLOUD_DEPLOY_LOCATION

    Die Region, die die Cloud Deploy-Ressourcen enthält.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Die ID der Bereitstellungspipeline.

  • CLOUD_DEPLOY_TARGET

    Die ID des Ziels.

  • CLOUD_DEPLOY_PROJECT

    Die Google Cloud Projektnummer für das Projekt, das die Cloud Deploy-Ressourcen enthält.

  • CLOUD_DEPLOY_PROJECT_ID

    Die Google Cloud Projekt-ID für das Projekt.

  • CLOUD_DEPLOY_RELEASE

    Die ID des Releases, in dem die Hooks ausgeführt werden.

  • CLOUD_DEPLOY_ROLLOUT

    Die ID des Roll-outs, der die Jobs für die Hooks enthält.

  • CLOUD_DEPLOY_JOB_RUN

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

  • CLOUD_DEPLOY_PHASE

    Die Phase im Rollout, die den Job für den Bereitstellungshook, den Überprüfungsjob oder das benutzerdefinierte Rendern oder Bereitstellen enthält.

Nächste Schritte