自動化ルールの使用

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

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

利用可能な自動化ルール

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

ルール 説明
timedPromoteReleaseRule cron スケジュールに基づいて、あるターゲットから次のターゲットに自動的にプロモートします。

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

指定されたターゲットにリリースを自動的にプロモートさせます。
advanceRolloutRule 指定された

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

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

自動化ルールを構成する

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

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

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

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

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

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

ここで

  • [RULE_ID]

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

  • [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）
    • ステップ関数（たとえば、時間のフィールドに */3 を指定すると、3 時間ごとに有効になります）

  • [TIME_ZONE]

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

  • [TO_TARGET]

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

  • [TO_PHASE]

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

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

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

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

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

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

ここで

  • [RULE_ID]

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

  • [WAIT_TIME]

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

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

  • [TO_TARGET]

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

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

  • [TO_PHASE]

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

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

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

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

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

ここで

  • [RULE_ID]

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

  • [WAIT_TIME]

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

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

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

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

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

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

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

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

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

ここに示す rules スタンザは、 自動化定義の内側に配置されます。

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]

ここで

  • [RULE_ID]

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

  • [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 が 1 分で、backoffMode が EXPONENTIAL に設定されている場合、失敗から最初の再試行までの時間は 1 分、最初の再試行から 2 回目の再試行までの時間は 2 分、2 回目の再試行から 3 回目の再試行までの時間は 4 分です。

  • rollback

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

  • [PHASE_NAME]

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

  • disableRollbackIfRolloutPending:

    true に設定すると、ターゲットで保留中のロールアウトがある場合、ロールバック オペレーションは中止されます。

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:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

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

次のステップ