Automatisierungsregeln verwenden

In diesem Dokument werden Automatisierungsregeln beschrieben. Das sind Aktionen, die automatisch auf Ihre Bereitstellungspipeline angewendet werden können. Sie können Ihre Bereitstellungspipeline beispielsweise so konfigurieren, dass die Hochstufung zu einem bestimmten Ziel unter den richtigen Umständen automatisch erfolgt.

Sie können nur Automatisierungsregeln verwenden, die in Cloud Deploy integriert sind. Die verfügbaren Automatisierungsregeln sind in diesem Dokument aufgeführt.

Verfügbare Automatisierungsregeln

In Cloud Deploy sind die folgenden Automatisierungsregeln verfügbar:

Regel Beschreibung
timedPromoteReleaseRule Automatische Hochstufung von einem Ziel zum nächsten

basierend auf einem Cron-Zeitplan.
promoteReleaseRule Stuft einen Release nach erfolgreichem

Roll-out im vorherigen Ziel in der Abfolge automatisch zum angegebenen Ziel hoch.
advanceRolloutRule Setzt ein Roll-out automatisch von der angegebenen

Phase in die nächste Phase fort.
repairRolloutRule Wiederholt den fehlgeschlagenen Job oder die fehlgeschlagenen Jobs im Roll-out

eine bestimmte Anzahl von Malen und führt ein Rollback durch, wenn alle Wiederholungen fehlschlagen.

Automatisierungsregeln konfigurieren

Die Konfiguration für jede Automatisierungsregel hängt von der jeweiligen Regel ab. In diesem Abschnitt wird die Konfiguration beschrieben, die alle Regeln gemeinsam haben, sowie die Konfiguration der einzelnen verfügbaren Regeln.

Jede Automatisierungsregel wird als Teil der Konfiguration für die Automatisierungsressource konfiguriert. Dies kann in derselben Datei wie die Konfiguration für die entsprechende Bereitstellungspipeline (normalerweise clouddeploy.yaml) oder in einer beliebigen anderen Datei erfolgen. Weitere Informationen zum Konfigurieren von Automatisierungen.

In den folgenden Abschnitten wird die Konfiguration beschrieben, die für einzelne Automatisierungsregeln spezifisch ist. Informationen zur Konfiguration der Automatisierung selbst finden Sie unter Bereitstellungen automatisieren.

Automatisierungsregel timedPromoteReleaseRule konfigurieren

Mit der Regel timedPromoteReleaseRule können Sie planen, wann ein Release vom ausgewählten Ziel oder den ausgewählten Zielen zum nächsten Ziel in der Abfolge oder zu einem angegebenen Ziel hochgestuft werden soll. Wenn Sie eine timedPromoteReleaseRule-Automatisierung konfigurieren, geben Sie anhand eines Cron-Zeitplans an, wann der Release hochgestuft werden soll.

rules:
- timedPromoteReleaseRule:
    id: "[RULE_ID]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dabei gilt:

  • [RULE_ID]

    Ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name muss innerhalb der Automatisierungsressource eindeutig sein.

  • [CRON]

    Ist der Cron-Zeitplan, der angibt, wann der Release hochgestuft werden soll. Geben Sie in diesem Zeitplan das Datum und die Uhrzeit an, zu denen Sie den Release hochstufen möchten.

    Dieser Zeitplan verwendet die Standard-cron-Syntax:

    * * * * *

    In diesem Zeitplan gilt:

    • Die erste Position ist die Minute (0-59).
    • Die zweite Position ist die Stunde (0-23).
    • Die dritte Position ist der Tag des Monats (1-31).
    • Die vierte Position ist der Monat (1-12).
    • Die fünfte Position ist der Tag der Woche (0-6, Sonntag bis Samstag).

    Wenn Ihre Regel für die zeitgesteuerte Hochstufung beispielsweise den folgenden Zeitplan enthält: 0 9 * * 1, wird Ihr Release jeden Montag um 9:00 Uhr hochgestuft.

    Sie können auch Standardfunktionen für Cron-Zeitpläne verwenden, z. B.:

    • Einen Bereich (0-5)
    • Eine Liste (1,3,5)
    • Eine Schrittfunktion (z. B. aktiviert */3 im Feld für die Stunden jede dritte Stunde)

  • [TIME_ZONE]

    Ist die Zeitzone, die Sie für die Planung der Hochstufung verwenden möchten, im IANA-Format.

  • [TO_TARGET]

    Ist die targetId des Ziels, zu dem hochgestuft werden soll, oder @next, um den Release automatisch zum nächsten Ziel hochzustufen, nachdem das in der selector.targets property in dieser Automatisierungskonfiguration angegebene Ziel erreicht wurde. Dies ist optional. Der Standardwert ist @next.

  • [TO_PHASE]

    Ist der Phasenname der Phase zu der Sie hochstufen möchten, z. B. canary-25 oder stable. Diese Eigenschaft ist optional. Wenn Sie sie weglassen, wird der Release zur ersten Phase im Ziel hochgestuft.

Automatisierungsregel promoteReleaseRule konfigurieren

Die Regel promoteReleaseRule stuft Ihren Release nach einem erfolgreichen Roll-out zu einem Ziel hoch. Wenn Sie beispielsweise drei Ziele haben, können Sie diese Regel so einrichten, dass der Release automatisch zum zweiten Ziel hochgestuft wird, wenn er erfolgreich im ersten Ziel bereitgestellt wurde.

Wenn Sie eine promoteReleaseRule-Automatisierung konfigurieren, können Sie entweder ein Ziel angeben, zu dem hochgestuft werden soll (destinationTargetId), oder @next. Wenn das Roll-out im Ziel, das in der Automation-Definition angegeben ist, erfolgreich abgeschlossen wurde, wird der Release nach einem wait-Zeitintervall zum Ziel hochgestuft, das in destinationTargetId angegeben ist.

Mit der Eigenschaft destinationPhase können Sie einen Release auch zu einer bestimmten Phase im Ziel hochstufen. Der hier gezeigte rules-Abschnitt gehört in Ihre Automatisierungsdefinition.

rules:
- promoteReleaseRule:
    id: "[RULE_ID]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dabei gilt:

  • [RULE_ID]

    Ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name muss innerhalb der Automatisierungsressource eindeutig sein.

  • [WAIT_TIME]

    Ist die Zeit in Minuten, die gewartet werden soll, nachdem der Release für die Hochstufung bereit ist, bevor er hochgestuft wird. Beispiel: 1m. Das m ist erforderlich.

    Der Standardwert ist 0 oder keine Wartezeit. Der Höchstwert ist 20160m (oder 14 Tage).

  • [TO_TARGET]

    Ist die targetId des Ziels, zu dem hochgestuft werden soll.

    Dies kann auch @next sein, wodurch der Release automatisch zum nächsten Ziel hochgestuft wird, nachdem das in der selector.targets Eigenschaft in dieser Automatisierungskonfiguration angegebene Ziel erreicht wurde. Dies ist der Standardwert, wenn Sie den Wert aus destinationTargetId weglassen.

  • [TO_PHASE]

    Ist der Phasenname der Phase, zu der Sie hochstufen möchten, z. B. canary-25 oder stable. Diese Eigenschaft ist optional. Wenn Sie sie weglassen, wird der Release zur ersten Phase im Ziel hochgestuft.

Automatisierungsregel advanceRolloutRule konfigurieren

Die Regel advanceRolloutRule setzt Ihr Roll-out nach erfolgreichem Abschluss einer Phase automatisch in der nächsten Phase fort. Diese Automatisierungsregel ist für Canary-Bereitstellungen nützlich. Wenn Sie beispielsweise eine Canary-Bereitstellungsstrategie für ein Ziel mit den Phasen 25%, 50% und stable konfiguriert haben, können Sie eine Automatisierungsregel konfigurieren, die die Phase nach Abschluss der 50%-Phase automatisch auf stable setzt.

Wenn Sie eine advanceRolloutRule-Automatisierung konfigurieren, geben Sie die Phase an, aus der fortgefahren werden soll (die sourcePhase). Der hier gezeigte rules-Abschnitt gehört in Ihre Automatisierungsdefinition.

rules:
- advanceRolloutRule:
    id: "[RULE_ID]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Dabei gilt:

  • [RULE_ID]

    Ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name muss innerhalb der Automatisierungsressource eindeutig sein.

  • [WAIT_TIME]

    Ist die Zeit in Minuten, die gewartet werden soll, bevor das Roll-out fortgesetzt wird, nachdem es bereit ist. Beispiel: 1m. Das m ist erforderlich.

    Der Standardwert ist 0 oder keine Wartezeit. Der Höchstwert ist 20160m (oder 14 Tage).

  • ["[START_PHASE]", "[START_PHASE]"...]

    Ist die Phase oder sind die Phasen, aus denen das Roll-out automatisch fortgesetzt wird. Wenn eine der aufgeführten Phasen erfolgreich abgeschlossen wurde, wird das Roll-out automatisch von dieser Phase zur nächsten Phase fortgesetzt.

    Bei Phasenamen wird zwischen Groß- und Kleinschreibung unterschieden. Außerdem sind diese Phasenamen optional. Wenn Sie sourcePhases weglassen, werden alle Phasen im Roll-out automatisch fortgesetzt.

Automatisierungsregel repairRolloutRule konfigurieren

Die Regel repairRolloutRule wiederholt ein fehlgeschlagenes Roll-out eine bestimmte Anzahl von Malen. Wenn diese Anzahl von Wiederholungen erreicht ist, kann diese Regel das Ziel automatisch auf den letzten erfolgreichen Release zurücksetzen.

Wenn Sie eine repairRolloutRule-Automatisierung konfigurieren, können Sie angeben, wie oft das Roll-out wiederholt werden soll und wie lange zwischen den Wiederholungen gewartet werden soll. Sie können auch bestimmte Phasen oder Jobs oder beides für die Wiederholung konfigurieren. Wenn jeder Wiederholungsversuch fehlschlägt, schlägt das Roll-out fehl. Wenn eine Wiederholung erfolgreich ist, wird die Automatisierung beendet und das Roll-out ist erfolgreich.

Optional können Sie die Automatisierung so konfigurieren, dass ein Rollback zum letzten erfolgreichen Release im Ziel durchgeführt wird. Wiederholungen sind ebenfalls optional, aber Sie müssen entweder eine bestimmte Anzahl von Wiederholungen oder ein Rollback oder beides haben.

Der hier gezeigte rules Abschnitt gehört in Ihre Automatisierungsdefinition.

rules:
- repairRolloutRule:
    id: "[RULE_ID]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]
        disableRollbackIfRolloutPending: [true | false]

Dabei gilt:

  • [RULE_ID]

    Ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name muss innerhalb der Automatisierungsressource eindeutig sein.

  • [PHASES_TO_REPAIR]

    Ist die Roll-out-Phase oder sind die Roll-out-Phasen, die wiederholt werden sollen. Dies ist optional. Standardmäßig werden alle Phasen im Roll-out wiederholt.

  • [JOBS_TO_REPAIR]

    Ist der Job oder sind die Jobs, die wiederholt werden sollen. Dies ist optional. Standardmäßig werden alle Jobs wiederholt.

  • [NUMBER_OF_ATTEMPTS]

    Optional: Die Anzahl der Wiederholungen des Roll-outs, bevor es als fehlgeschlagen betrachtet wird.

  • [WAIT_TIME]

    Ist die Zeit, die zwischen den Wiederholungsversuchen gewartet werden soll. Beispiel: 1m für ein Intervall von einer Minute. Die Zeiteinheit (in diesem Fall m) ist erforderlich.

    Wenn mode auf linear gesetzt ist, ist dieses Intervall für jede Wiederholung gleich. Wenn mode auf exponential gesetzt ist, erhöht sich das Intervall bei jeder Wiederholung. Weitere Informationen finden Sie unter mode.

  • backoffMode

    LINEAR oder EXPONENTIAL. Gibt an, ob die Zeit zwischen den Wiederholungen erhöht werden soll. Wenn LINEAR festgelegt ist, ist die Zeit zwischen den Wiederholungen konstant und entspricht WAIT_TIME. Wenn EXPONENTIAL festgelegt ist, verdoppelt sich die Zeit zwischen den Wiederholungen bei jeder nachfolgenden Wiederholung. Der Standardwert ist LINEAR.

    Wenn WAIT_TIME beispielsweise auf 1 Minute und backoffMode auf EXPONENTIAL gesetzt ist, beträgt die Zeit zwischen dem Fehler und der ersten Wiederholung 1 Minute, die Zeit zwischen der ersten und zweiten Wiederholung 2 Minuten und die Zeit zwischen der zweiten und dritten Wiederholung 4 Minuten.

  • rollback

    Optional: Gibt an, ob das fehlgeschlagene Roll-out zurückgesetzt werden soll, nachdem alle Wiederholungsversuche ausgeschöpft wurden.

  • [PHASE_NAME]

    Ist der Name einer bestimmten Phase, zu der ein Rollback durchgeführt werden soll. Wenn Sie toPhase weglassen, wird standardmäßig ein Rollback zur Phase stable durchgeführt.

  • disableRollbackIfRolloutPending:

    Wenn auf true gesetzt, wird der Rollback-Vorgang abgebrochen, wenn für das Ziel ein Roll-out aussteht.

Ausführung einer repairRolloutRule-Automatisierung abbrechen

Wenn Sie einen der folgenden Befehle für Ihr Roll-out ausführen, wird die repairRolloutRule-Automatisierung abgebrochen:

Beispiel

Das folgende Beispiel zeigt eine Automatisierungskonfiguration mit einer repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Wenn ein Roll-out im angegebenen Ziel fehlschlägt, wird es in dieser Automatisierung bis zu dreimal wiederholt, wobei zwischen den Wiederholungsversuchen eine Minute gewartet wird. Wenn alle Wiederholungsversuche fehlschlagen, wird ein Rollback gestartet, indem ein neues Roll-out erstellt wird, um den letzten erfolgreichen Release des Ziels in diesem Ziel bereitzustellen.

Nächste Schritte