Einführungen verwalten

Eine Cloud Deploy-Einführung umfasst Phasen. Eine Phase ist eine geordnete, logische Gruppierung von Aufgaben, die bei einem Rollout ausgeführt werden müssen.

Jede Phase umfasst Jobs, die die in jeder Phase auszuführenden Aktionen sind (z. B. deploy oder verify). Jeder Job kann null oder mehr Jobläufe haben. Eine Jobausführung ist eine Instanz eines Jobs. Wenn der Job nicht ausgeführt wurde, gibt es keine Jobläufe.

In diesem Dokument werden Phasen, Jobs und Jobausführungen beschrieben und es wird erläutert, wie Sie sie verwalten.

Struktur eines Roll-outs

Ein Roll-out ist eine Cloud Deploy-Ressource, die ein Release mit einem Ziel verknüpft.

Phasen

Ein Roll-out besteht aus einer oder mehreren Phasen.

Bei einer Standardbereitstellungsstrategie gibt es nur eine Phase: stable.

Bei einer Canary-Bereitstellungsstrategie gibt es für jeden konfigurierten Prozentsatz eine separate Phase. Wenn Sie beispielsweise ein Canary-Deployment mit 25%, 50 % und 100 % konfigurieren, gibt es drei Phasen:

• canary-25
• canary-50
• stable

Diese Phasennamen sind Standard: canary-[PERCENTAGE] für Canary-Phasen und stable für die 100‑%-Phase. Wenn Sie jedoch eine benutzerdefinierte automatisierte Canary- oder benutzerdefinierte Canary-Bereitstellung konfigurieren, können Sie die Phasennamen steuern.

Jobs und Jobausführungen

Jede Rollout-Phase umfasst einen oder mehrere Jobs.

Bei einem Roll-out mit einer Standardbereitstellungsstrategie ohne aktivierte Bereitstellungsüberprüfung gibt es eine Phase (stable).

Bei einem Canary-Roll-out gibt es eine Phase für jeden Teil des Canary (z. B. canary-25, canary-50, stable) und für jede Phase einen deploy-Job. Wenn die Überprüfung aktiviert ist, gibt es für jede Phase auch einen verify-Job.

Eine Jobausführung ist eine Instanz eines Jobs. Ein Joblauf für einen deploy-Job wird beispielsweise ausgeführt. Wenn er erfolgreich ist, gibt es keinen weiteren Joblauf für diesen Job. Wenn der Vorgang fehlschlägt, kann er als anderer Joblauf wiederholt werden.

Phasen beim ersten Mal überspringen

Bei einigen Bereitstellungsstrategien (z. B. Canary) wird der Traffic zwischen der alten und der neuen Version aufgeteilt. Wenn Sie die Bereitstellung zum ersten Mal auf einem Ziel vornehmen, gibt es keine alte Version. Daher können wir den Traffic nicht aufteilen.

Wenn Sie ein Canary-Deployment zum ersten Mal bereitstellen, werden die Canary-Phase(n) übersprungen und die stable-Phase wird ausgeführt. Danach wird die Anwendung bereitgestellt und zukünftige Canary-Bereitstellungen umfassen die Canary-Phasen.

In der Praxis führen Sie in der Regel ein Canary-Deployment aus, bei dem Ihre Anwendung bereits ausgeführt wird. Das Überspringen dieser Phase ist daher selten.

Status während der Einführung

Rollouts, Phasen, Jobs und Jobausführungen haben alle einen Status. In diesem Abschnitt werden die einzelnen Status beschrieben.

Roll-out-Status

Ein Roll-out kann einen der folgenden Status haben:

• APPROVAL_REJECTED

  Für den Roll-out war eine Genehmigung erforderlich, die jedoch abgelehnt wurde.

• CANCELLED

  Der Endstatus für Rollouts, die von einem Nutzer abgebrochen wurden.

• CANCELLING

  Ein Nutzer hat den Roll-out abgebrochen, die Verarbeitung des Abbruchs ist aber noch nicht abgeschlossen.

• HALTED

  Bei einer parallelen Bereitstellung wird das Controller-Roll-out BEENDET, wenn mindestens ein untergeordnetes Roll-out fehlschlägt, aber mindestens ein untergeordnetes Roll-out erfolgreich ist und es nach der aktuellen Phase weitere Phasen gibt.

  Sie haben folgende Möglichkeiten, ein angehaltenes Controller-Rollout fortzusetzen:

  • Roll‑out des Controllers abbrechen

  • Fehlgeschlagene Jobs bei untergeordneten Roll-outs wiederholen oder ignorieren

• IN_PROGRESS

  Ein Joblauf wird verarbeitet.

• FAILED

  Ein Job ist fehlgeschlagen und der Nutzer hat nicht Fehler ignorieren ausgewählt.

• PENDING

  Die Verarbeitung des Roll-outs hat noch nicht begonnen. Dieser Status wechselt zu IN_PROGRESS oder CANCELED.

• PENDING_APPROVAL

  Für den Roll-out ist eine Genehmigung erforderlich, die noch nicht erteilt wurde.

• PENDING_RELEASE

  Der Roll-out wartet darauf, dass die Version gerendert wird.

• SUCCEEDED

  Der Roll-out wurde ohne Fehler abgeschlossen.

Phasenstatus

Eine Phase kann einen der folgenden Status haben:

• PENDING

  Die Phase wartet darauf, dass eine andere Phase der Einführung abgeschlossen wird.

• IN_PROGRESS

  Die Phase hat begonnen.

• SUCCEEDED

  Die Phase wurde erfolgreich abgeschlossen.

• FAILED

  Ein Job in der Phase ist fehlgeschlagen und der Nutzer hat nicht Fehler ignorieren ausgewählt.

• ABORTED

  Eine vorherige Phase ist fehlgeschlagen.

• SKIPPED

  Wenn Sie eine Bereitstellungsstrategie wie Canary ausführen, springt Cloud Deploy zur Phase stable, wenn noch keine laufende Version der Anwendung vorhanden ist, mit der der Traffic aufgeteilt werden kann. In diesem Fall wird der Status auf SKIPPED festgelegt.

Jobstatus

Ein Job kann einen der folgenden Status haben:

• ABORTED

  Wenn eine Phase fehlschlägt, werden die nachfolgenden Phasen abgebrochen.

  Wenn ein Job fehlschlägt und dieser Fehler nicht ignoriert wird, werden nachfolgende Jobs abgebrochen. Wenn eine Phase beispielsweise einen Bereitstellungsjob und einen Bestätigungsjob enthält und der Bereitstellungsjob fehlschlägt, wird der Bestätigungsjob abgebrochen.

• DISABLED

  Einige Jobs in einer Phase sind möglicherweise deaktiviert. Phasen enthalten beispielsweise immer Überprüfungsjobs, unabhängig davon, ob verification aktiviert ist. Wenn die Bestätigung nicht aktiviert ist, wird der Überprüfungsjob auf DISABLED festgelegt.

• FAILED

  Ein Joblauf für diesen Job ist fehlgeschlagen und der Nutzer hat nicht Fehler ignorieren ausgewählt.

  Der Nutzer hat sich entschieden, die Ausführung des Jobs zu beenden.

• IGNORED

  Eine Jobausführung für diesen Job ist fehlgeschlagen und der Nutzer hat sich entschieden, den Fehler zu ignorieren.

• IN_PROGRESS

  Für diesen Job wird derzeit ein Joblauf ausgeführt.

• PENDING

  Die Jobausführung für diesen Job wartet auf den Beginn, da eine andere Phase oder ein anderer Job noch nicht abgeschlossen ist.

• SKIPPED

  Wenn Sie eine Bereitstellungsstrategie wie Canary ausführen, springt Cloud Deploy zur Phase stable, wenn noch keine laufende Version der Anwendung vorhanden ist, mit der der Traffic aufgeteilt werden kann. In diesem Fall wird der Status für Jobs in der übersprungenen Phase oder den übersprungenen Phasen auf SKIPPED gesetzt.

• SUCCEEDED

  Der Joblauf wurde erfolgreich abgeschlossen und der nächste Job in der Phase wurde gestartet oder die nächste Phase wurde gestartet oder kann gestartet werden (möglicherweise ist eine Nutzereingabe erforderlich) oder der Roll-out wurde abgeschlossen.

Status von Jobausführungen

• FAILED

  Die Ausführung des Joblaufs ist fehlgeschlagen.

• IN_PROGRESS

  Der Joblauf hat begonnen, ist aber noch nicht abgeschlossen.

• TERMINATED

  Der Nutzer hat die Ausführung des Jobs beendet.

• TERMINATING

  Der Nutzer hat den Joblauf beendet, aber der Vorgang ist noch nicht abgeschlossen.

• SUCCEEDED

  Wenn die Ausführung eines Jobs erfolgreich abgeschlossen wird, ohne dass ein Fehler auftritt oder sie von einem Nutzer beendet wird, wird der Job in den Status SUCCEEDED versetzt.

Einführung verwalten

Mit der Google Cloud -Konsole oder dem Google Cloud SDK können Sie mit einem Cloud Deploy-Rollout Folgendes tun:

• Roll-out fortsetzen

• Roll-out abbrechen

• Ausführung eines Jobs beenden

• Job ignorieren

• Fehlgeschlagenen Job wiederholen

Wenn Sie die parallele Bereitstellung mit einer Canary-Bereitstellungsstrategie verwenden, finden Sie hier Informationen zum Verwalten paralleler Canary-Rollouts.

Roll-out fortsetzen

Bei Zielen, die für eine andere Bereitstellungsstrategie als „Standard“ konfiguriert sind, müssen Sie den Roll-out von Phase zu Phase vorantreiben.

Wenn Sie beispielsweise ein Ziel konfiguriert haben, um eine einfache Canary-Bereitstellung mit nur 50 %- und stable-Phasen (100%) durchzuführen, müssen Sie den Rollout einmal von der canary-50-Phase in die stable-Phase (100%) verschieben.

gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

Rollout abbrechen

Sie können jedes Roll-out abbrechen, das noch nicht abgeschlossen ist. Sie können auch einen fehlgeschlagenen Roll-out abbrechen, um weitere Aktionen (z. B. „Ignorieren“ oder „Wiederholen“) zu verhindern. Der Roll-out muss einen der folgenden Status haben:

• FAILED
• HALTED
• IN_PROGRESS
• PENDING
• PENDING_APPROVAL
• PENDING_RELEASE

Nachdem Sie eine Einführung abgebrochen haben, befindet sich diese Einführung im Status CANCELLING, bis alle ausstehenden Jobläufe abgeschlossen sind. Sie können ausstehende Jobläufe beenden, auf die Sie nicht warten möchten. Sobald der Roll-out CANCELLED ist, kann er nicht mehr vorangetrieben oder geändert werden.

So brechen Sie ein Rollout ab:

gcloud deploy rollouts cancel ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

Ausführung eines Jobs beenden

Sie können eine laufende Jobausführung beenden. Das kann beispielsweise sinnvoll sein, wenn ein Joblauf zu lange dauert oder nicht wie erwartet funktioniert. Der Joblauf muss IN_PROGRESS sein, damit Sie ihn beenden können.

gcloud deploy job-runs terminate JOB_RUN_ID \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --rollout=ROLLOUT_NAME \
                               --region=REGION

Nachdem Sie einen Joblauf beendet haben, gilt der Job als fehlgeschlagen. Sie haben dann folgende Möglichkeiten:

• So lassen und das fehlgeschlagene Roll-out ignorieren
• Job wiederholen
• Job ignorieren und mit dem nächsten Job oder der nächsten Phase im Roll-out fortfahren

Job ignorieren

Sie können einen fehlgeschlagenen Job ignorieren und sofort mit dem nächsten Job in der Phase fortfahren. Der Job ist möglicherweise aus einem beliebigen Grund fehlgeschlagen, z. B. weil Sie oder eine andere Person eine Jobausführung für diesen Job beendet haben.

Ein fehlgeschlagener Job bedeutet eine fehlgeschlagene Phase und einen fehlgeschlagenen Roll-out. Wenn Sie den Fehler jedoch ignorieren, können sowohl die Phase als auch das Roll-out fortgesetzt werden und letztendlich den Status SUCCEEDED haben.

gcloud deploy rollouts ignore-job ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --job-id=JOB_ID \
                               --phase-id=PHASE_ID \
                               --region=REGION

Fehlgeschlagenen Job wiederholen

Sie können eine fehlgeschlagene Jobausführung wiederholen. Der Job kann aus einem der folgenden Gründe fehlschlagen:

• Eine Jobausführung konnte nicht abgeschlossen werden.

  Möglicherweise ist ein Berechtigungsfehler aufgetreten.

• Ein Nutzer hat einen Joblauf für diesen Job beendet.

  Wenn Sie eine Jobausführung beenden, schlägt der Job fehl. Sie können ihn dann wiederholen.

• Ein Überprüfungstest ist fehlgeschlagen.

  Bei einem Bestätigungsjob ist ein Bestätigungstest fehlgeschlagen. Obwohl der Bestätigungsjob korrekt abgeschlossen wurde, ist einer Ihrer Bestätigungstests fehlgeschlagen. Wir übertragen diesen Fehler zurück an den Bestätigungsjob. In diesem Fall würden Sie den Job im Rahmen des Debuggens des fehlgeschlagenen Tests für Ihre Anwendung noch einmal ausführen.

So wiederholen Sie einen fehlgeschlagenen Job:

gcloud deploy rollouts retry-job JOB_NAME \
                       --release=RELEASE_NAME \
                       --delivery-pipeline=PIPELINE_NAME \
                       --rollout=ROLLOUT_NAME \
                       --phase=PHASE_ID \
                       --region=REGION

Nächste Schritte

• Weitere Informationen zu Bereitstellungsstrategien in Cloud Deploy

• Weitere Informationen dazu, wie Rollouts, Phasen, Jobs und Jobläufe in den Rest von Cloud Deploy passen, finden Sie in der Dokumentation zur Cloud Deploy-Dienstarchitektur.