Automatisierungsregeln verwenden

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

In Cloud Deploy sind die folgenden Automatisierungsregeln verfügbar:

Regel Beschreibung
promoteReleaseRule Nach erfolgreichem

im vorherigen Ziel in der Abfolge abgeschlossen ist.
timedPromoteReleaseRule Automatische Hochstufung von einem Ziel zum nächsten

nach einem Cron-Zeitplan.
advanceRolloutRule Setzt ein 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 rückgängig gemacht, 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. Sie können sie in derselben Datei wie die Konfiguration für die entsprechende Bereitstellungspipeline (normalerweise clouddeploy.yaml) oder in einer beliebigen anderen Datei platzieren. Weitere Informationen zum Konfigurieren von Automatisierungen

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

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 nach der erfolgreichen Bereitstellung im ersten Ziel automatisch auf das zweite Ziel hochgestuft wird.

Wenn Sie eine promoteReleaseRule-Automatisierung konfigurieren, können Sie entweder ein Ziel für die Bewerbung (destinationTargetId) oder @next angeben. Wenn das Roll-out im in der Definition von Automation angegebenen Ziel erfolgreich abgeschlossen wurde, 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 gewünschten Ziel hochstufen. Die hier gezeigte rules-Strophe wird in die Automatisierungsdefinition eingefügt.

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

Wobei:

  • [RULE_NAME]

    Geben Sie einen Namen für diese Regel ein. Dieser Name darf innerhalb der Automatisierungsressource nur einmal vorkommen.

  • [WAIT_TIME]

    Gibt an, wie lange (in Minuten) nach der Veröffentlichung gewartet werden soll, bevor die Werbung gestartet wird. Beispiel: 1m. m ist erforderlich.

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

  • [TO_TARGET]

    Ist die targetId des Ziels, auf das die Umstellung erfolgen soll.

    Das kann auch @next sein, wodurch der Release automatisch nach dem in der selector.targets-Eigenschaft dieser Automatisierungskonfiguration angegebenen Ziel zum nächsten Ziel hochgestuft wird. Dies ist der Standardwert, wenn Sie den Wert für destinationTargetId weglassen.

  • [TO_PHASE]

    Der Name der Phase, in die Sie wechseln 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.

timedPromoteReleaseRule-Automatisierungsregel konfigurieren

Mit der Regel timedPromoteReleaseRule können Sie festlegen, wann ein Release vom ausgewählten Ziel oder den ausgewählten Zielen zum nächsten Ziel in der Abfolge oder zu einem bestimmten Ziel hochgestuft werden soll. Wenn Sie eine timedPromoteReleaseRule-Automatisierung konfigurieren, geben Sie an, wann die Version basierend auf einem Cron-Zeitplan freigegeben werden soll.

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

Wobei:

  • [RULE_NAME]

    Geben Sie einen Namen für diese Regel ein. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [CRON]

    Gibt an, wann der Release beworben werden soll. Hier kannst du Datum und Uhrzeit angeben, zu denen du die Veröffentlichung bewerben möchtest.

    In diesem Zeitplan wird die Standardsyntax von cron verwendet:

    * * * * *

    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 zeitlich begrenzte Werbung beispielsweise den folgenden Zeitplan enthält: 0 9 * * 1, wird Ihre Version jeden Montag um 9:00 Uhr beworben.

    Sie können auch standardmäßige Cron-Zeitplanfunktionen verwenden, z. B.:

    • Einen Bereich (0–5)
    • Liste (1,3,5)
    • Eine Stufenfunktion (z. B. */3 im Feld „Stunden“, um alle drei Stunden zu aktivieren)

  • [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, zu dem der Release hochgestuft werden soll, oder @next, um den Release automatisch nach dem in der selector.targets property in dieser Automatisierungskonfiguration angegebenen Ziel zum nächsten Ziel hochzustufen. Dies ist optional. Der Standardwert ist @next.

  • [TO_PHASE]

    Der Name der Phase, in die Sie einsteigen möchten, z. B. canary-25 oder stable. Diese Eigenschaft ist optional. Wenn Sie sie weglassen, wird der Release in die erste Phase im Ziel hochgestuft.

advanceRolloutRule-Automatisierungsregel konfigurieren

Mit der advanceRolloutRule wird das Roll-out nach Abschluss einer Phase automatisch in die nächste Phase fortgesetzt. 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 automatisch auf stable umstellt, nachdem die Phase 50% abgeschlossen ist.

Wenn Sie eine advanceRolloutRule-Automatisierung konfigurieren, geben Sie die Phase an, von der aus fortgeschritten werden soll (sourcePhase). Der hier gezeigte rules-Abschnitt wird in die Automatisierungsdefinition eingefügt.

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

Wobei:

  • [RULE_NAME]

    Geben Sie einen Namen für diese Regel ein. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [WAIT_TIME]

    Gibt an, wie lange (in Minuten) gewartet werden muss, bis das Roll-out fortgesetzt wird, nachdem es bereit ist. Beispiel: 1m. m ist erforderlich.

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

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

    Die Phase oder Phasen, aus denen das Roll-out automatisch fortgesetzt wird. Das bedeutet, dass das Roll-out automatisch von einer Phase zur nächsten fortgesetzt wird, sobald eine der aufgeführten Phasen abgeschlossen ist.

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

repairRolloutRule-Automatisierungsregel konfigurieren

Mit der Regel repairRolloutRule wird ein fehlgeschlagenes Roll-out eine bestimmte Anzahl von Malen wiederholt. Wenn diese Anzahl der Wiederholungen aufgebraucht ist, kann diese Regel das Ziel automatisch auf die letzte erfolgreiche Version zurücksetzen.

Wenn Sie eine repairRolloutRule-Automatisierung konfigurieren, können Sie angeben, wie oft das Roll-out wiederholt werden soll und wie lange gewartet werden soll, bevor ein neuer Versuch gestartet wird. Sie können auch bestimmte Phasen oder Jobs oder beides so konfigurieren, dass sie wiederholt werden. Wenn alle Wiederholungsversuche fehlschlagen, schlägt das Roll-out fehl. Wenn ein Wiederholungsversuch erfolgreich ist, wird die Automatisierung beendet und das Roll-out ist erfolgreich.

Optional können Sie die Automatisierung so konfigurieren, dass ein Rollback auf den letzten erfolgreichen Release auf dem Ziel ausgeführt wird. Wiederholungen sind ebenfalls optional, aber Sie müssen entweder eine bestimmte Anzahl von Wiederholungen oder ein Rollback oder beides angeben.

Die hier gezeigte rules-Strophe wird in die Automatisierungsdefinition eingefügt.

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]

    Geben Sie einen Namen für diese Regel ein. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen.

  • [PHASES_TO_REPAIR]

    Die Phasen des Roll-outs, die noch einmal versucht werden sollen. Dies ist optional. Die Standardeinstellung ist „Alle Phasen des Roll-outs“.

  • [JOBS_TO_REPAIR]

    Der oder die Jobs, die wiederholt werden sollen. Dies ist optional. Standardmäßig sind alle Jobs ausgewählt.

  • [NUMBER_OF_ATTEMPTS]

    Optional: Die Anzahl der Wiederholungsversuche für das Roll-out, bevor es 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 = linear ist, ist dieses Intervall für jeden Wiederholungsversuch gleich. Wenn mode = exponential ist, erhöht sich das Intervall jedes Mal. Weitere Informationen finden Sie unter mode.

  • backoffMode

    LINEAR oder EXPONENTIAL, um anzugeben, ob der Zeitraum zwischen den Deaktivierungsvorgängen verlängert werden soll oder nicht. Bei LINEAR ist die Zeit zwischen den Wiederholungen konstant und beträgt WAIT_TIME. Bei EXPONENTIAL verdoppelt sich die Zeit zwischen den Wiederholungen bei jedem weiteren Wiederholungsversuch. 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 dem zweiten Wiederholungsversuch 2 Minuten und die Zeit zwischen dem zweiten und dem dritten Wiederholungsversuch 4 Minuten.

  • rollback

    Optional: Ob das fehlgeschlagene Roll-out rückgängig gemacht werden soll, nachdem alle Wiederholungsversuche ausgeschöpft sind.

  • [PHASE_NAME]

    Der Name einer bestimmten Phase, auf die Sie zurücksetzen möchten. Wenn Sie toPhase weglassen, wird der Rollback standardmäßig auf die Phase stable angewendet.

Ausführung einer repairRolloutRule-Automatisierung abbrechen

Wenn Sie einen der folgenden Befehle für Ihr Roll-out ausführen, wird dierepairRolloutRule 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 bei dieser Automatisierung ein Roll-out für das angegebene Ziel fehlschlägt, wird es bis zu dreimal wiederholt, wobei zwischen den Wiederholungsversuchen eine Minute gewartet wird. Wenn alle Wiederholungsversuche fehlschlagen, wird ein Rollback gestartet. Dazu wird ein neues Roll-out erstellt, um den letzten erfolgreichen Release des Ziels auf diesem Ziel bereitzustellen.

Nächste Schritte