自動化ルールの使用

このドキュメントでは、自動化ルールについて説明します。自動化ルールとは、デリバリー パイプラインに対して自動的に実行できるアクションです。たとえば、適切な状況下で特定のターゲットへのプロモーションが自動的に行われるように、デリバリー パイプラインを構成できます。

使用できるのは、Cloud Deploy に組み込まれている自動化ルールのみです。利用可能な自動化ルールについては、このドキュメントをご覧ください。

利用可能な自動化ルール

Cloud Deploy では、次の自動化ルールを使用できます。

ルール 説明
promoteReleaseRule 進行中の前のターゲットのロールアウトの成功後に、

指定されたターゲットにリリースを自動的にプロモートさせます。
timedPromoteReleaseRule あるターゲットから次のターゲットに自動的にプロモートする

に基づいて実行されます。
advanceRolloutRule 指定された

フェーズから次のフェーズへと、自動的にロールアウトを進行させます。
repairRolloutRule ロールアウトで失敗したジョブを自動的に再試行します。

指定された回数再試行し、すべての再試行が失敗した場合はロールバックします。

自動化ルールを構成する

自動化ルールの構成は、ルールごとに異なります。このセクションでは、すべてのルールに共通する構成と、使用可能な各ルールの構成方法について説明します。

各自動化ルールは、自動化リソースの構成の一部として構成されます。これは、関連するデリバリー パイプラインの構成（通常は clouddeploy.yaml と呼ばれます）と同じファイル内、または任意のファイル内に配置できます。詳しくは、自動化の構成をご覧ください。

以降のセクションでは、個々の自動化ルールに固有の構成について説明します。自動化自体の構成については、デプロイを自動化するをご覧ください。

promoteReleaseRule 自動化ルールを構成する

promoteReleaseRule ルールは、ターゲットへのロールアウトに成功した後にリリースをプロモートさせます。たとえば、3 つのターゲットがある場合、リリースが最初のターゲットに正常にデプロイされると、自動的に 2 番目のターゲットにプロモートするようにこのルールを設定できます。

promoteReleaseRule 自動化を構成する際は、プロモートさせるターゲットを（destinationTargetId）または @next で指定できます。Automation 定義で指定されたターゲットでロールアウトが正常に終了すると、wait の時間間隔に従って、リリースが destinationTargetId で指定されたターゲットにプロモートされます。

destinationPhase プロパティを使用して、目的のターゲットの特定のフェーズにリリースをプロモートすることもできます。ここで示す rules スタンザは、自動化定義内に配置します。

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

ここで

  • [RULE_NAME]

    このルールに付ける名前です。この名前は、自動化リソース内で一意である必要があります。

  • [WAIT_TIME]

    リリースの準備が整った後、プロモートされるまで待機する時間（分単位）です。たとえば 1m です。必ず m を付ける必要があります。

    デフォルト値は 0 で、待機時間はありません。最大値は 20160m（14 日）です。

  • [TO_TARGET]

    プロモート先のターゲットの targetId です。

    @next にすることもできます。この場合、この自動化構成の selector.targets プロパティで指定されたターゲットの後に、リリースが次のターゲットに自動的にプロモートされます。これは、destinationTargetId の値を指定しない場合のデフォルトです。

  • [TO_PHASE]

    プロモート先のフェーズのフェーズ名（canary-25、stable など）です。このプロパティは省略可能です。指定しない場合、リリースはターゲットの最初のフェーズにプロモートされます。

timedPromoteReleaseRule 自動化ルールを構成する

timedPromoteReleaseRule ルールを使用すると、選択したターゲットから進行中の次のターゲットまたは指定されたターゲットにリリースをプロモートするタイミングをスケジュールできます。timedPromoteReleaseRule 自動化を構成する際は、cron スケジュールに基づいてリリースを昇格するタイミングを指定します。

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

ここで

  • [RULE_NAME]

    このルールに付ける名前です。この名前は、デリバリー パイプライン内で一意である必要があります。

  • [CRON]

    リリースを昇格するタイミングを指定する cron スケジュールです。このスケジュールを使用して、リリースを公開する日時を指定します。

    このスケジュールでは、標準の cron 構文を使用します。

    * * * * *

    このスケジュールでは、

    • 最初の位置は分（0～59）です。
    • 2 番目の位置は時間（0～23）です。
    • 3 番目の位置は日付（1～31）です。
    • 4 番目の位置は月（1～12）です。
    • 5 番目の位置は曜日（0～6、日曜日～土曜日）です。

    たとえば、時間指定プロモーション ルールに次のスケジュールが含まれている場合、0 9 * * 1、リリースは毎週月曜日の午前 9 時にプロモートされます。

    次のような標準の cron スケジュール機能も使用できます。

    • 範囲（0～5）
    • リスト（1、3、5）
    • ステップ関数（hours フィールドの */3 は 3 時間ごとにアクティブになります）

  • [TIME_ZONE]

    プロモーションのスケジュール設定に使用するタイムゾーン（IANA 形式）。

  • [TO_TARGET]

    昇格先のターゲットの targetId です。この自動化構成の selector.targets property で指定されたターゲットの後に、リリースを次のターゲットに自動的に昇格させるには @next にします。これは省略可能です。デフォルトは @next です。

  • [TO_PHASE]

    プロモート先のフェーズのフェーズ名（canary-25、stable など）です。このプロパティは省略可能です。指定しない場合、リリースはターゲットの最初のフェーズにプロモートされます。

advanceRolloutRule 自動化ルールを構成する

advanceRolloutRule は、1 つのフェーズが正常に完了すると、ロールアウトを自動的に次のフェーズに進めます。この自動化ルールは、カナリア デプロイに役立ちます。たとえば、ターゲットにカナリア デプロイ戦略（25%、50%、stable のフェーズ）を用いている場合に、フェーズを進行する自動化ルールを構成して、50% フェーズが終了すると自動的に stable に進行させるといったことができます。

advanceRolloutRule 自動化を構成する際は、どのフェーズから進行させるか（sourcePhase ）を特定します。ここに示す rules スタンザは、自動化定義内に配置します。

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

ここで

  • [RULE_NAME]

    このルールに付ける名前です。この名前は、デリバリー パイプライン内で一意である必要があります。

  • [WAIT_TIME]

    ロールアウトの準備が整った後、ロールアウトを進めるのを待機する時間（分単位）です。たとえば 1m です。必ず m を付ける必要があります。

    デフォルト値は 0 で、待機時間はありません。最大値は 20160m（14 日）です。

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

    ロールアウトを自動的に進行させる起点となるフェーズです。 つまり、指定されたいずれかのフェーズが正常に終了すると、そのフェーズから次のフェーズに自動的にロールアウトが進行します。

    フェーズ名では大文字と小文字が区別されます。また、これらのフェーズ名はオプションです。sourcePhases を省略すると、ロールアウトのすべてのフェーズが自動的に進行します。

repairRolloutRule 自動化ルールを構成する

repairRolloutRule ルールは、失敗したロールアウトを指定した回数だけ再試行します。再試行回数が上限に達すると、このルールによって、ターゲットが最後に正常にリリースされた状態に自動的にロールバックされます。

repairRolloutRule 自動化を構成するときに、ロールアウトの再試行回数と再試行間の待ち時間を指定できます。特定のフェーズまたはジョブ、またはその両方を再試行するように構成することもできます。各再試行が失敗すると、ロールアウトは失敗します。再試行が成功すると、自動化は停止し、ロールアウトは成功します。

必要に応じて、ターゲットで最後に正常にリリースされたリリースにロールバックするように自動化を構成できます。再試行も省略可能ですが、一定回数の再試行またはロールバック、またはその両方が必要です。

ここで示す rules スタンザは、自動化定義内に配置します。

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]

ここで

  • [RULE_NAME]

    このルールに付ける名前です。この名前は、デリバリー パイプライン内で一意である必要があります。

  • [PHASES_TO_REPAIR]

    再試行するロールアウト フェーズです。これは省略可能です。デフォルトはロールアウトのすべてのフェーズです。

  • [JOBS_TO_REPAIR]

    再試行するジョブです。これは省略可能です。デフォルトはすべてのジョブです。

  • [NUMBER_OF_ATTEMPTS]

    これは省略可能です。ロールアウトを失敗と見なす前に再試行する回数です。

  • [WAIT_TIME]

    再試行の間に待機する最大時間です。 たとえば、1 分間隔の場合は 1m です。時間単位（この場合は m）は必須です。

    mode が linear の場合、この間隔は再試行ごとに同じです。mode が exponential の場合、間隔は毎回増加します。（詳細については、mode をご覧ください）。

  • backoffMode

    LINEAR または EXPONENTIAL の場合、リタイア間の時間を長くするかどうかを示します。LINEAR の場合、再試行の間隔は一定で WAIT_TIME です。EXPONENTIAL の場合、再試行の間隔は連続する再試行ごとに 2 倍になります。デフォルトは LINEAR です。

    たとえば、WAIT_TIME が 1m で、backoffMode が EXPONENTIAL に設定されている場合、失敗から最初の再試行までの時間は 1 分、最初の再試行から 2 回目の再試行までの時間は 2 分、2 回目の再試行から 3 回目の再試行までの時間は 4 分です。

  • rollback

    省略可能です。すべての再試行が試行された後に、失敗したロールアウトをロールバックするかどうか設定します。

  • [PHASE_NAME]

    ロールバックする特定のフェーズの名前です。toPhase を省略すると、ロールバックはデフォルトで stable フェーズになります。

repairRolloutRule 自動化の実行を中止する

ロールアウトで次のいずれかのコマンドを実行すると、repairRolloutRule の自動化が中止されます。

例

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"

この自動化では、特定されたターゲットでロールアウトが失敗した場合、そのロールアウトは最大 3 回再試行され、再試行の間隔は 1 分です。すべての再試行が失敗した場合、新しいロールアウトを作成してターゲットの最新の正常なリリースをそのターゲットにデプロイすることで、ロールバックが開始されます。

次のステップ