Automatisierungsregeln verwenden

In diesem Dokument werden Automatisierungsregeln beschrieben. Das sind Aktionen, die automatisch in Ihrer Bereitstellungspipeline ausgeführt werden können. Sie können Ihre Bereitstellungspipeline beispielsweise so konfigurieren, dass die Hochstufung in ein bestimmtes 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

Die folgenden Automatisierungsregeln sind in Cloud Deploy verfügbar:

Regel Beschreibung
timedPromoteReleaseRule Automatisch vom einen zum nächsten Ziel hochstufen

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

Roll-out im vorherigen Ziel in der Abfolge.
advanceRolloutRule Roll-out automatisch von der angegebenen

Phase zur nächsten Phase.
repairRolloutRule Fehlgeschlagene Jobs im Roll-out automatisch wiederholen

angegebene Anzahl von Malen wiederholt und zurückgesetzt, 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 allen Regeln gemeinsam ist, 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 (in der Regel clouddeploy.yaml) oder in einer beliebigen anderen Datei erfolgen. Weitere Informationen zum Konfigurieren von Automatisierungen

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

timedPromoteReleaseRule-Automatisierungsregel 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 die Release-Version hochgestuft werden soll.

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Wobei:

  • [RULE_NAME]

    ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [CRON]

    Der Cron-Zeitplan, der angibt, wann der Release hochgestuft werden soll. Mit diesem Zeitplan können Sie das Datum und die Uhrzeit angeben, zu denen Sie die Veröffentlichung bewerben möchten.

    Dieser Zeitplan verwendet die Standard-cron-Syntax:

    * * * * *

    In diesem Zeitplan…

    • 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 Wochentag (0–6, Sonntag bis Samstag).

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

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

    • Ein Bereich (0–5)
    • Eine Liste (1,3,5)
    • Eine Stufenfunktion (z. B. */3 im Feld „Stunden“ aktiviert jede dritte Stunde)

  • [TIME_ZONE]

    Die Zeitzone, die Sie für die Planung des Angebots verwenden möchten, im IANA-Format.

  • [TO_TARGET]

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

  • [TO_PHASE]

    Ist der Phasenname der phase, die Sie hochstufen möchten, z. B. canary-25 oder stable. Dieses Attribut ist optional. Wenn Sie es weglassen, wird der Release in die erste Phase des Ziels hochgestuft.

promoteReleaseRule-Automatisierungsregel konfigurieren

Mit der Regel promoteReleaseRule wird Ihr Release nach einem erfolgreichen Roll-out in ein Ziel hochgestuft. Wenn Sie beispielsweise drei Ziele haben, können Sie diese Regel so einrichten, dass der Release automatisch auf das zweite Ziel hochgestuft wird, wenn er erfolgreich auf dem ersten Ziel bereitgestellt wurde.

Wenn Sie eine promoteReleaseRule-Automatisierung konfigurieren, können Sie entweder ein Ziel für die Promotion (destinationTargetId) oder @next angeben. Wenn das Roll-out im Ziel, das in der Automation-Definition angegeben ist, erfolgreich abgeschlossen ist, wird der Release nach einem Zeitintervall von wait auf das in destinationTargetId angegebene Ziel hochgestuft.

Mit der Property destinationPhase können Sie einen Release auch auf eine bestimmte Phase im vorgesehenen Ziel hochstufen. Der hier gezeigte rules-Abschnitt gehört in Ihre Automatisierungsdefinition.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Wobei:

  • [RULE_NAME]

    ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name darf innerhalb der Automatisierungsressource nur einmal vorkommen.

  • [WAIT_TIME]

    Die Anzahl der Minuten, die gewartet werden soll, nachdem das Release für die Werbung bereit ist, bevor es beworben wird. Beispiel: 1m. m ist erforderlich.

    Der Standardwert ist 0, d. h. keine Wartezeit. Das Maximum beträgt 20160m (oder 14 Tage).

  • [TO_TARGET]

    Ist die targetId des Ziels, auf das hochgestuft werden soll.

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

  • [TO_PHASE]

    Ist der Phasenname der Phase, die Sie hochstufen möchten, z. B. canary-25 oder stable. Diese Property ist optional. Wenn Sie sie weglassen, wird der Release in die erste Phase des Ziels hochgestuft.

advanceRolloutRule-Automatisierungsregel konfigurieren

Mit advanceRolloutRule wird Ihr Roll-out nach erfolgreichem Abschluss einer Phase automatisch in die nächste Phase überführt. 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, mit der die Phase nach Abschluss der Phase 50% automatisch auf stable umgestellt wird.

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

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Wobei:

  • [RULE_NAME]

    ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [WAIT_TIME]

    Die Anzahl der Minuten, die gewartet werden soll, bevor das Rollout fortgesetzt wird, nachdem es bereit ist. Beispiel: 1m. m ist erforderlich.

    Der Standardwert ist 0, d. h. keine Wartezeit. Das Maximum beträgt 20160m (oder 14 Tage).

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

    Die Phase oder Phasen, aus denen das Roll-out automatisch fortgesetzt wird. Wenn eine der aufgeführten Phasen erfolgreich abgeschlossen ist, wird das Roll-out automatisch von dieser Phase in die nächste Phase verschoben.

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

repairRolloutRule-Automatisierungsregel konfigurieren

Mit der Regel repairRolloutRule wird ein fehlgeschlagener Roll-out eine bestimmte Anzahl von Malen wiederholt. Wenn diese Anzahl von Wiederholungsversuchen erreicht ist, kann mit dieser Regel das Ziel automatisch auf das letzte erfolgreiche Release zurückgesetzt werden.

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

Optional können Sie die Automatisierung so konfigurieren, dass ein Rollback auf den letzten erfolgreichen Release für das Ziel erfolgt. Wiederholungen sind ebenfalls optional, aber Sie benötigen entweder eine bestimmte Anzahl von Wiederholungen oder ein Rollback oder beides.

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

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

Wobei:

  • [RULE_NAME]

    ist ein beliebiger Name, den Sie dieser Regel geben möchten. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [PHASES_TO_REPAIR]

    Die Roll-out-Phase oder ‑Phasen, die wiederholt werden sollen. Dies ist optional. Standardmäßig sind alle Phasen des Rollouts enthalten.

  • [JOBS_TO_REPAIR]

    Gibt an, welcher Job oder welche Jobs wiederholt werden sollen. Dies ist optional. Standardmäßig werden alle Jobs berücksichtigt.

  • [NUMBER_OF_ATTEMPTS]

    Optional: Die Anzahl der Wiederholungsversuche für den Roll-out, bevor er als fehlgeschlagen betrachtet wird.

  • [WAIT_TIME]

    Gibt die Wartezeit zwischen Wiederholungsversuchen an. Beispiel: 1m für ein Intervall von einer Minute. Die Zeiteinheit (in diesem Fall m) ist erforderlich.

    Wenn mode gleich linear ist, ist dieses Intervall für jeden Wiederholungsversuch gleich. Wenn mode gleich exponential ist, wird das Intervall jedes Mal erhöht. Weitere Informationen finden Sie unter mode.

  • backoffMode

    LINEAR oder EXPONENTIAL, um anzugeben, ob die Zeit zwischen Wiederholungsversuchen verlängert werden soll. Wenn LINEAR, ist die Zeit zwischen den Wiederholungsversuchen konstant und beträgt WAIT_TIME. Wenn EXPONENTIAL, verdoppelt sich die Zeit zwischen den Wiederholungen mit jeder aufeinanderfolgenden Wiederholung. Standardwert ist LINEAR.

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

  • rollback

    Optional: Gibt an, ob das fehlgeschlagene Rollout nach allen Wiederholungsversuchen rückgängig gemacht werden soll.

  • [PHASE_NAME]

    Ist der Name einer bestimmten Phase, zu der Sie ein Rollback durchführen möchten. Wenn Sie toPhase weglassen, wird standardmäßig die Phase stable für das Rollback verwendet.

repairRolloutRule-Automatisierungsausführung abbrechen

Wenn Sie einen der folgenden Befehle für Ihren 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:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

Wenn ein Rollout bei dieser Automatisierung für das angegebene Ziel fehlschlägt, wird er bis zu dreimal wiederholt. Zwischen den Wiederholungsversuchen wird jeweils eine Minute gewartet. Wenn alle Wiederholungsversuche fehlschlagen, wird ein Rollback gestartet, indem ein neuer Rollout erstellt wird, um den letzten erfolgreichen Release des Ziels für dieses Ziel bereitzustellen.

Nächste Schritte