MIG へのアップデートのロールアウト

マネージド インスタンス グループ(MIG)には、インスタンス テンプレートを使用して作成された仮想マシン(VM)インスタンスが少なくとも 1 つ含まれます。MIG のインスタンスを更新するには、MIG Updater 機能を使用してグループ全体に対する更新リクエストを行います。

MIG Updater を使用すると、新しいバージョンのソフトウェアをマネージド インスタンス グループのインスタンスにデプロイでき、さらにデプロイの速度、サービス中断のレベル、更新の範囲を制御できます。Updater の主なメリットは、次の 2 つです。

  • アップデートのロールアウトは指定に従って自動的に実行される。最初のリクエスト後は、新たに指示を入力する必要がない。
  • 部分的ロールアウトを実行して、カナリアテストを行うことができる。

既存のマネージド インスタンス グループ内に新しいソフトウェアをデプロイできるようにすると、ソフトウェアの新しいバージョンがロールアウトされるたびに、インスタンス グループを再構成したり、負荷分散、自動スケーリング、自動修復を再接続したりする必要がなくなります。Updater を使用しない場合、新しいソフトウェア バージョンをデプロイするには、新しいソフトウェア バージョンで新しいマネージド インスタンス グループを作成して毎回追加の設定を行うか、ユーザーがインスタンスを 1 つ 1 つ手動で再作成しなければなりません。いずれにしても、プロセス全体を通して多くの手動作業が必要となります。

始める前に

基本的なローリング アップデートの開始

ローリング アップデートとは、すべてのインスタンスが更新されるまでインスタンス グループのすべてのインスタンスに段階的に適用されるアップデートです。更新中にオフラインにすることが可能なインスタンス数、インスタンス間での更新待機時間、更新の影響範囲(全体または一部)など、ローリング アップデートのさまざまな設定を制御できます。

ローリング アップデートを実行するときに注意する点は、次のとおりです。

  • 更新はインテント ベースです。最初の更新リクエストを行うと、API はリクエストが有効であったことを知らせるために成功のレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたかどうかを判断するには、マネージド インスタンス グループのステータスを確認する必要があります。

  • Instance Group Updater API は宣言型 API です。この API は明示的な関数呼び出しではなく、マネージド インスタンス グループの更新後に必要な構成を指定するためのリクエストを要求します。

  • Updater は、マネージド インスタンス グループで最大 2 つのインスタンス テンプレート バージョンをサポートしています。マネージド インスタンス グループに 2 つの異なるインスタンス テンプレート バージョンを指定できます。これは、カナリア更新を行う場合に便利です。

グループ内インスタンスの 100% に更新を適用する基本的なローリング アップデートの開始手順は次のとおりです。

Console

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページ上部の [ローリング アップデート] をクリックします。
  4. [テンプレート] のプルダウン リストをクリックし、更新に使用する新しいテンプレートを選択します。
  5. 全インスタンスを更新するために、ターゲット サイズには「100%」と入力します。
  6. 必要に応じて、構成オプションを切り替えられます。たとえば、更新を先行型(グループが能動的にインスタンスを置き換える)と追従型(グループはインスタンスを能動的には置き換えず、インスタンスが他の手段で置き換えられた場合に更新を適用する)のどちらにするかなどです。また、最大サージオフライン上限オプション最小待機時間も指定できます。
  7. [更新] をクリックして更新を開始します。

gcloud

gcloud コマンドライン ツールを使用して、次のように rolling-action start-update コマンドを実行します。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=instance-template-name
    [--zone zone | --region region]

上記コマンドで、以下の部分を置き換えます。

  • instance-group-name: 更新するインスタンス グループの名前。
  • instance-template-name: インスタンス グループの更新基準とする新しいインスタンス テンプレート。
  • zone: インスタンス グループがゾーン インスタンス グループの場合は、更新するインスタンス グループのゾーン
  • region: インスタンス グループがリージョン インスタンス グループの場合は、更新するインスタンス グループのリージョン。

API

API で、次のように PATCH リクエストをインスタンス グループ マネージャー リソースに送信します。

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

インスタンス グループがリージョン マネージド インスタンス グループの場合は、zones/zoneregions/region に置き換えます。

リクエストのペイロードには次が含まれます。

  • グループの更新基準とするインスタンス テンプレート。
  • リクエストの更新ポリシーと他の更新オプション

次の例は、API で更新を開始するために必要な最小限の構成を示しています。

特に指定しない場合は、maxSurgemaxUnavailable プロパティが影響を受けるゾーンの数にデフォルトで設定されます。つまり Updater は更新中に、影響を受ける各ゾーン内で 1 つのインスタンスのみを利用不可にして、ゾーンごとに 1 つの追加インスタンスのみを作成します。

次のリクエストの例は、全インスタンスを新しいインスタンス テンプレートに更新します。

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

リクエストを送った後、更新をモニタリングすると更新が完了したことを確認できます。

更新のオプションの構成

複雑な更新の場合は、特定の更新リクエストに対して追加のオプションを構成できます。これらのオプションについて、下記に説明します。

最大サージ

maxSurge プロパティを設定すると、Updater で更新中に targetSize を超える数の新しいインスタンスを一時的に作成できます。たとえば、maxSurge を 5 に設定すると、マネージド インスタンス グループでは新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスが作成されます。maxSurge の値が大きくなるほど更新速度は上がりますが、インスタンスの追加による費用がかかります。この費用は Compute Engine の料金表に従って課金されます。

maxSurge の値を設定していない場合は、デフォルト値が使用されます。ゾーン マネージド インスタンス グループの場合、maxSurge のデフォルト値は 1 です。リージョン マネージド インスタンス グループのデフォルト値は、リージョン マネージド インスタンス グループに関連付けられているゾーンの数です。

このオプションは、REPLACE 最小アクションで構成されている場合に限り認識され、RESTART アクション設定ではサポートされません。固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り上げます。

maxSurge は、追加のリソースをサポートするために十分な割り当てまたはリソースがある場合に限り機能します。

オフライン上限

maxUnavailable を設定すると、更新中はいつでも決まった数のインスタンスだけがオフラインになります。たとえば、maxUnavailable を 5 に設定すると、更新の際、同時にオフラインになるのは、5 つのインスタンスだけです。このパラメータを使用して、更新がサービスに与える影響の度合いと、更新をデプロイする速度を制御します。

この数値には、他の理由でオフラインになっているインスタンスの数も含まれます。たとえば、インスタンス グループでサイズ増加の処理が行われている場合、作成中のインスタンスがオフラインになる場合があり、このようなインスタンスがこの maxUnavailable の数に加算されます。固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定したためインスタンス数に端数が生じた場合は、Updater が値を切り下げます。

maxUnavailable のデフォルト値は、グループの種類によって異なります。

  • ゾーン MIG の場合、デフォルトは 1 です。
  • リージョン MIG の場合、デフォルトは MIG が分散されるゾーンの数で、通常は 3 ですが、異なる数のゾーンを選択することもできます。

最小待機時間

新しいインスタンスまたは再起動したインスタンスを更新済みとみなすまでの待機時間を指定するには、minReadySec を設定します。この機能を使用して、更新がデプロイされる速度を制御します。タイマーは、次の条件がどちらも満たされると起動します。

  • インスタンスのステータスが RUNNING である。
  • ヘルスチェックが有効の場合、ヘルスチェックのときに HEALTHY が返される。

ヘルスチェックを行うにあたり、Updater は次のように動作します。

  1. ヘルスチェックに HEALTHY が返されるまで、最大 autohealingPolicies.initialDelaySec で指定された時間待機します。
  2. 次に、minReadySec で指定された時間待機します。

ヘルスチェックが initialDelaySec 内に HEALTHY を返さなければ、Updater は VM インスタンスを異常とみなし、場合によっては更新を停止します。VM インスタンスが initialDelaySecminReadySec で指定された時間、検証を待機している間は、インスタンスの currentActionVERIFYING になります。ただし、基礎となる VM インスタンスのステータスは RUNNING のままです。

インスタンス グループでヘルスチェックが行われない場合、タイマーはインスタンスのステータスが RUNNING になると起動します。minReadySec プロパティの最大値は 3,600 秒(1 時間)です。

最小アクション

最小アクション プロパティを設定して、Updater でグループ内のインスタンスを更新するために実行する必要のある最小アクションを指定します。たとえば、最小アクションとして REPLACE を設定すると、必要かどうかに関係なく、影響を受けるすべてのインスタンスが削除され、新しいインスタンスで置き換えられます。

最小アクションを設定すると、Updater がそのアクションを必ず行うことが保証されます。ただし、指定された最小アクションでは更新を実行するのに不十分であると Updater が判断した場合、より大がかりなアクションが実行されます。たとえば、最小アクションとして RESTART を設定した場合、Updater は更新を適用するためにインスタンスの再起動を試みます。ただし、より大がかりなアクションを実行しなければ更新できない場合、Updater はその必要なアクションを実行します。たとえば、インスタンスの OS が変更される場合、インスタンスを再起動しても OS は変更できません。したがって、Updater はインスタンス グループ内のインスタンスを新しい VM インスタンスに置き換えます。

適用可能なアクションは REPLACE または RESTART です。

  • RESTART: インスタンスを再起動します(stopstart をリクエストします)。更新リクエストで、変更を反映するためにインスタンスを置き換える必要がある場合(たとえばイメージを変更するには、インスタンスを削除して置き換える必要があります)、Updater は REPLACE を実行します。

  • REPLACE: 既存のインスタンスを削除し、ターゲット テンプレートからインスタンスを作成します。Updater によって、内部 IP アドレスや外部 IP アドレスなど、インスタンス プロパティをすべて一新したインスタンスが作成されます。

次の図は、これらのオプションがインスタンスに与える影響を示しています。

Updater オプションがリクエストに与える影響

置換メソッド

デフォルトでは、MIG を更新すると、グループは VM インスタンスを削除し、新しい名前の新しいインスタンスに置き換えます。VM インスタンスの名前を保持する必要がある場合は、replacementMethod 設定を使用します。

特定のインスタンス名の使用に依存するアプリケーションやシステムがある場合は、既存のインスタンス名を保持することが役立つ場合があります。たとえば、Memcached などの一部のアプリケーションは、検出サービスがないためインスタンス名に依存しています。その結果、インスタンス名が変更されると、アプリケーションはその特定の VM への接続を失います。

インスタンス名を保持するには、置換メソッドを substitute ではなく recreate に設定します。

マネージド インスタンスの置換メソッド。

有効な Updater の replacementMethod 値は次のとおりです。

  • substitute(デフォルト)

    • 古い VM がシャットダウンされる前に新しい VM が作成されるため、VM インスタンスは更新中にすばやく置換されます。ただし、古いインスタンスでまだ名前が使用されているため、インスタンス名は保持されません。
  • recreate

    • 更新を通してインスタンス名が保持されます。Compute Engine は、古い VM がシャットダウンされるとインスタンス名を解放します。その後、Compute Engine は同じ名前を使用して新しいインスタンスを作成します。
    • このモードを使用するには、maxSurge0 に設定する必要があります。

詳細については、インスタンス名の保持をご覧ください。

追加の更新例

ここでは、一般的な設定オプションを使用したコマンドラインの例を示します。

VM インスタンスすべてのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 5 個までとする

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --max-surge 5 \
    [--zone zone | --region region]

最大 3 台のオフライン マシン、最小待機時間 3 分を指定してローリング アップデートを実行してから、新しいインスタンスをオンラインとしてマークする

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --min-ready 3m \
    --max-unavailable 3 \
    [--zone zone | --region region]

たとえば、1,000 個のインスタンスがある場合にこのコマンドを実行すると、Updater は最大 100 個のインスタンスを作成してから、前のインスタンス テンプレートを実行しているインスタンスの削除を開始します。

すべての VM インスタンスのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 10% までとする

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    --max-surge 10% \
    [--zone zone | --region region]

カナリア更新

Updater を使用すると、カナリア更新を実行できます。これにより、更新を完全に commit する前にランダムなインスタンスの組み合わせで更新をテストできます。

カナリア更新とは、インスタンス グループ内の一部のインスタンスに適用される更新です。カナリア更新を使用すると、大がかりになる可能性のある更新を全インスタンスにロールアウトするのではなく、ランダムなインスタンスの組み合わせで新しい機能または更新をテストできます。更新がうまくいかない場合、少数のインスタンスをロールバックするだけで済み、ユーザーに対する影響を最小限に抑えることができます。サーバーの観点では、カナリア更新は標準のローリング アップデートと同じですが、更新の必要のあるインスタンス数がインスタンス グループの合計サイズより小さい点が異なります。標準のローリング アップデートと同様に、カナリア更新は対象となるインスタンスに対して大きな影響を与えます。つまり、更新の際に、対象となるインスタンスは削除されて、新しい VM インスタンスに置き換えられます。

カナリア更新の開始

カナリア更新を開始するには:

  • 最大 2 つのインスタンス テンプレート バージョンを指定します。通常、カナリアに対しては新しいインスタンス テンプレートを、残りのインスタンスに対しては現在のインスタンス テンプレートを指定します。たとえば、new-instance-template に基づいてインスタンスの 20% が作成され、残りのインスタンスは引き続き old-instance-template で実行されるように指定できます。同時に指定できるインスタンス テンプレートは 2 つまでです。

  • カナリア バージョンにはターゲット サイズ(targetSize)を常に指定する必要があります。カナリア バージョンのターゲット サイズを省略すると、カナリア更新を開始できません。たとえば、カナリア処理にインスタンスの 10% を使用するように指定した場合、残り 90% のインスタンスはそのままで、現在のインスタンス テンプレートが使用されます。

Console

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページ上部の [ローリング アップデート] をクリックします。
  4. [テンプレート] をクリックして、カナリア更新する新しいインスタンス テンプレートを選択します。
  5. [ターゲット サイズ] で、新しいインスタンス テンプレートのカナリア更新に使用するインスタンスの数、または割合を入力します。
  6. 必要に応じて、構成オプションを切り替えることができます。たとえば、更新を先行型(グループが能動的にインスタンスの削除や置換を行う)と追従型(グループはインスタンスを能動的に置換せず、他の理由でインスタンスが作成された場合に更新を適用する)のどちらにするかなどです。また、最大サージオフライン上限オプション最小待機時間も指定できます。
  7. [更新] をクリックして更新を開始します。

gcloud

gcloud コマンドライン ツールで、現在のテンプレートと新しいテンプレートを両方指定し、各テンプレートを使用するインスタンス数を明示的に指定します。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=current-template \
    --canary-version template=new-template,target-size=size \
    [--zone zone | --region region]

上記コマンドで、以下の部分を置き換えます。

  • instance-group-name: インスタンスのグループ名。
  • current-template: インスタンス グループが実行されているインスタンス テンプレート。
  • new-template: カナリアに追加する新しいテンプレート。
  • size: この更新を適用するインスタンスの数または割合。target-size プロパティは、--canary-version テンプレートに適用する必要があります。インスタンス グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。
  • zone: このインスタンス グループのゾーン。インスタンス グループがゾーン インスタンス グループの場合は、ゾーンを指定します。
  • region: このインスタンス グループのリージョン。インスタンス グループがリージョンの場合は、リージョンを指定します。

たとえば、次のコマンドでは、インスタンス グループ内の 10% のインスタンスに my-template-b がロールアウトされるカナリア更新が実行されます。

gcloud compute instance-groups managed rolling-action start-update my-ig1 \
    --version template=my-template-A \
    --canary-version template=my-template-B,target-size=10%

API

API で、次のように PATCH リクエストをインスタンス グループ マネージャー リソースに送信します。

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

リクエスト ペイロードには、現在のインスタンス テンプレートと、カナリア更新に使用する新しいインスタンス テンプレートの両方を含めます。次に例を示します。

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/new-template",
   "targetSize": {
    "[percent|fixed]": number|percentage # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/current-template"
  }
 ]
}

上記コマンドで、以下の部分を置き換えます。

  • new-template: カナリアに追加する新しいテンプレートの名前。
  • number|percentage: この更新を行うカナリアのインスタンスの数または割合。インスタンス グループに 10 個以上のインスタンスが含まれている場合は、割合による設定のみ可能です。それ以外の場合は、インスタンスの数を指定します。
  • current-template: インスタンス グループが実行されている現在のインスタンス テンプレートの名前。

カナリア更新のロール フォワード

カナリア更新の実行後、インスタンス グループ全体に対する更新を commit するかロールバックするかを決定できます。

Console

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページ上部の [ローリング アップデート] をクリックします。
  4. [テンプレート] で、カナリア テンプレートのターゲット サイズを 100% に更新して、テンプレートをすべてのインスタンスにロール フォワードするようにします。あるいは、プライマリ テンプレートをカナリア テンプレートに置き換えて、ターゲット サイズを 100% に設定するという方法もあります。その後、2 番目のテンプレートのフィールドを完全に削除できます。
  5. [更新] をクリックして更新を開始します。

gcloud

カナリア更新に commit する場合は、同じ更新リクエストを送りますが、version のみを設定し、--canary-version を省略して、更新をロール フォワードします。gcloud コマンドライン ツールは次のように使用します。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    [--zone zone | --region region]

API

API で、次のように PATCH リクエストをインスタンス グループ マネージャー リソースに送信します。

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

リクエストの本文で、新しいインスタンス テンプレートを version として指定し、古いインスタンス テンプレートは、リクエスト本文に入れないようにします。すべてのインスタンスに更新をロールアウトするために、ターゲット サイズの指定は省略します。たとえば、リクエストの本文は次のようになります。new-template は、ロール フォワードする新しいインスタンス テンプレートの名前に置き換えます。

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/new-template" # New instance template
   }
 ]
}

追従型更新または先行型更新の開始

デフォルトでは、gcloud コマンドライン ツールで行う更新は先行型になり、API で開始される更新は追従型になります。

先行型更新の場合、Compute Engine は積極的にアクションをスケジュールし、必要に応じてリクエストされた更新をインスタンスに適用します。これは多くの場合、インスタンスを先に削除して再作成することを意味します。

または、先行型更新が大がかりになりすぎる可能性がある場合は、追従型更新を実施できます。追従型更新が適用されるのは、選択したインスタンスの更新を手動で開始した場合、またはマネージド インスタンス グループによって新しいインスタンスが作成された場合に限ります。マネージド インスタンス グループは、そのサイズが別のサービス(オートスケーラーなど)により、またはユーザーによって手動で変更されると、新しいインスタンスを作成します。更新を適用するためのリクエストが Compute Engine から積極的に開始されることはありません。

システムが不安定になることは可能な限り避けたい場合など、状況によっては、追従型更新が有用です。たとえば、緊急性がなく必要に応じて適用できる、リスクが限定された更新があり、アクティブにオート スケーリングされているマネージド インスタンス グループがある場合は、追従型更新を実施して、Compute Engine が更新を適用するために既存のインスタンスを削除しないようにします。サイズを縮小する場合、オートスケーラーは古いテンプレートによるインスタンスと、まだ RUNNING されていないインスタンスを優先的に終了させます。

追従型更新か先行型更新かを選択するには、gcloud コマンドライン ツールまたは API のいずれかを使用して、タイプ プロパティを OPPORTUNISTICPROACTIVE に設定します。

Console

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページ上部の [ローリング アップデート] をクリックします。
  4. [テンプレート] で、インスタンス グループの更新に使用するテンプレートを選択し、テンプレートのターゲット サイズを選択します。
  5. [更新モード] で、追従型更新または先行型更新のいずれかを選択します。
  6. [更新] をクリックして更新を開始します。

gcloud

gcloud コマンドライン ツールは次のように使用します。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=instance-template \
    --type opportunistic|proactive \
    [--zone zone | --region region]

API

更新を開始するリクエスト ペイロードで、type プロパティを updatePolicy に含めます。new-template は、カナリアに使用する新しいテンプレート名で置き換えます。追従型更新を設定したい場合は、PROACTIVEOPPORTUNISTIC に置き換えます。

{
  "updatePolicy": {
    "type": "PROACTIVE" # Performs a proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/new-template",
    }]
}

選択したインスタンスの更新

追従型更新を開始した場合は、更新の機会が生じて Compute Engine が更新をロールアウトするまで待機する必要があります。ただし、ロールアウトを細かく管理したい場合は、手動でマネージド インスタンス グループ内の特定のインスタンスの更新を即時開始できます。

更新を手動で開始すると、次のことが可能になります。

  • 更新するインスタンスを選択できます。
  • 更新を完了させるために必要な中断を最小限に抑えて更新を適用できます。たとえば、メタデータだけを更新する場合、更新を完了するためにインスタンスを再起動する必要はありません。手動で更新を開始すると、必要最小限のアクションが自動的に実行されます。
  • 更新を適用するために必要でないとしても、インスタンスを強制的に再起動または再作成させることができます。たとえば、VM のメタデータのみを更新する場合でも、ゲスト ソフトウェアが VM 起動時に新しいメタデータを適用できるよう、VM を再起動できます。
  • 許容可能なレベルを超える中断が必要な場合は、更新を阻止できます。
  • maxSurgemaxUnavailable の制約によるロールアウトを制限せずに、選択したすべてのインスタンスを直ちに更新できます。

最小アクションと許容される最も大がかりなアクション

更新の特性によっては、インスタンスの状態が損なわれる可能性があります。たとえば、インスタンスのブートディスクを変更するには、インスタンスを削除して置き換える必要があります。

minimal-action フラグと most-disruptive-allowed-action フラグを使用すると、中断レベルを制御できます。

  • minimal-action は、必要以上に大がかりなアクションを強制できます。
  • 許容可能なレベルを超える中断が必要な場合は、most-disruptive-allowed-action を使用して更新を事前に止めることが可能です。

選択したインスタンスを更新するときは、どちらのフラグも次のアクションを受け入れます。

アクション説明更新可能なインスタンス プロパティ
NONEインスタンスを一切中断しません。なし
REFRESHインスタンスを停止しません。追加のディスク、インスタンス メタデータ、ラベル
RESTARTインスタンスを停止して再起動します。追加のディスク、インスタンス メタデータ、ラベル、マシンタイプ
REPLACEインスタンスを削除して再作成します。インスタンス テンプレートまたはインスタンスごとの構成ファイルに保存されているすべてのインスタンス プロパティ

デフォルトの minimal-actionNONE です。このフラグで設定したアクションよりも大がかりなアクションを実行しなければ更新できない場合、Compute Engine は更新に必要なアクションを実行します。

デフォルトでは、most-disruptive-allowed-actionREPLACE です。このフラグで設定したアクションよりも大がかりなアクションを実行しなければ更新できない場合、更新リクエストは失敗します。たとえば、許容される最も大がかりなアクションとして RESTART を設定した場合、ブートディスク イメージを更新しようとしても失敗します。ブートディスク イメージの更新にはインスタンスの再作成が必要になり、これは再起動よりも大がかりなアクションになるためです。

選択したインスタンスを更新するには、gcloud ツールまたは API を使用できます。

gcloud

追従型更新を開始した後、update-instances サブコマンドを使用して特定のインスタンスに更新を適用します。

gcloud compute instance-groups managed update-instances instance-group-name \
    --instances instance-names \
    --most-disruptive-allowed-action disruption-level \
    --minimal-action disruption-level

ここで

  • instance-group-name は、更新が保留中のインスタンス グループの名前です。
  • instance-names は、直ちに更新するインスタンスのリストです。
  • disruption-level は、最小または最大の中断レベルです。取り得る値は、nonerefreshrestartreplace です。
    • デフォルトの minimal-actionnone です。
    • デフォルトの most-disruptive-allowed-actionreplace です。

指定したすべてのインスタンスが更新されるまで待機する必要がある場合は、グループのステータスを確認し、グループが安定するまで待ちます。

API

追従型更新を開始した後、regionInstanceGroupManagers.applyUpdatesToInstances メソッドに対する POST リクエストを作成します。ゾーン マネージド インスタンス グループの場合は、ゾーンの instanceGroupManagers.applyUpdatesToInstances メソッドを使用します。

POST https://compute.googleapis.com/compute/v1/projects/project/regions/region/instanceGroupManagers/instance-group-name/applyUpdatesToInstances
{
  "instances": "zones/zone/instances/instance-name","zones/zone/instances/instance-name"
  "minimalAction": disruption-level,
  "mostDisruptiveAllowedAction": disruption-level
}

ここで

  • instance-group-name は、更新が保留中のインスタンス グループの名前です。
  • zone は、直ちに更新するインスタンスのゾーンです。
  • instance-name は、直ちに更新するインスタンスの名前です。
  • disruption-level は、最小または最大の中断レベルです。取り得る値は、NONEREFRESHRESTARTREPLACE です。
    • デフォルトの minimalActionNONE です。
    • デフォルトの mostDisruptiveAllowedActionREPLACE です。

他のマネージド インスタンス グループのメソッドと同様に、applyUpdatesToInstances はインテント ベースのメソッドです。つまり、このメソッドはオペレーション レスポンスを返します。オペレーションが DONE になった後、listManagedInstances には、currentAction フィールドが REFRESHINGRESTARTING、または RECREATING に変更されたインスタンスのリストが格納されます。たとえば、グループに対する同時変更が原因でオペレーションが失敗した場合は、lastAttempt.errors フィールドにそのエラーが示されます。

指定したすべてのインスタンスの更新が完了するまで待機する必要がある場合は、グループのステータスを確認し、グループが安定するまで待ちます。

ローリング置換または再起動の実行

restart または replace コマンドを使用すると、マネージド インスタンス グループの VM インスタンスにローリング再起動またはローリング置換を実行できます。start-update コマンドと同様に、再起動または置換用のあらゆる構成オプションを指定できます。ローリング再起動およびローリング置換では、インスタンス テンプレートなどインスタンス グループの内容は変更されません。選択したメソッドを使用して、グループのインスタンスが更新されるだけです。

ローリング置換またはローリング再起動を実行する理由はさまざまです。たとえば、次の操作を行うために VM インスタンスの更新を随時実行します。

  • メモリリークを解消する。
  • 新しいマシンから実行できるようにアプリケーションを再起動する。
  • ベスト プラクティスとして定期的に強制的な置換を実施し、VM をテストする。
  • VM のオペレーティング システム イメージの更新や、起動スクリプトを再実行してソフトウェアの更新を行う。

Google Cloud Console、gcloud コマンドライン ツール、API を使用して、すべてのインスタンスを削除し、新しいインスタンスに置き換える置換を実行できます。

Console

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページ上部の、[ローリング再起動 / 置換] をクリックします。
  4. インスタンスを再起動するか置換するかを選択します。再起動ではインスタンスに対して stop メソッドと start メソッドが実行されます。置換では、インスタンスが実際に削除されて再作成されます。
  5. 必要に応じて、最大サージオフライン上限オプション最小待機時間などの構成オプションを切り替えることができます。
  6. [再起動] または [置換] ボタンをクリックして更新を開始します。

gcloud

gcloud compute instance-groups managed rolling-action replace instance-group-name

このコマンドを実行すると、マネージド インスタンス グループ内の全インスタンスが置換されます。置換は 1 回に 1 つずつ行われます。完全な置換による中断が多すぎる場合は、ローリング再起動を指定できます。この場合、インスタンスは削除されず、インスタンスごとに再起動のみが実行されます。

gcloud compute instance-groups managed rolling-action restart instance-group-name

更新に使用できるものと同じオプションmaxSurgemaxUnavailablemin-readyなど)を指定して、コマンドをカスタマイズできます。

API

API で、グループの PATCH リクエストを実行し、先行型の updatePolicy を設定します。minimalAction は、各インスタンスが削除され新しいインスタンスに置換されるローリング置換または各インスタンスが停止して再起動されるローリング再起動を実行するかどうかに応じて RESTART または REPLACE になります。RESTARTREPLACE のどちらの場合も、常に versions.instanceTemplateversions.name プロパティ(v2 など)を指定してアクションを実行する必要があります。

ローリング置換は次のようになります。

PATCH https://compute.googleapis.com/compute/v1/projects/my-project/zones/zone/instanceGroupManagers/instance-group-name

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

ローリング再起動は次のようになります。

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

追加の置換 / 再起動の例

すべての VM のローリング再起動を一度に 2 つずつ実行する

このコマンドは、インスタンス グループ内のすべての VM を 一度に 2 つずつ再起動します。新しいインスタンス テンプレートは指定されていません。

gcloud compute instance-groups managed rolling-action restart instance-group-name \
    --max-unavailable 2 \
    [--zone zone | --region region]

すべての VM のローリング再起動を可能な限り速く実行する

gcloud compute instance-groups managed rolling-action restart instance-group-name \
    --max-unavailable 100% \
    [--zone zone | --region region]

すべての VM のローリング置換を可能な限り速く実行する

gcloud compute instance-groups managed rolling-action replace instance-group-name  \
    --max-unavailable 100% \
    [--zone zone | --region region]

インスタンス名の保持

更新後も VM インスタンスの名前を保持する必要がある場合は、replacementMethodrecreate に設定します。また、maxUnavailable0 より大きく、maxSurge0 に設定する必要があります。maxSurge0 に設定すると、更新が完了するまでの時間が長くなりますが、replacementMethod:recreate を使用すると、更新されたインスタンスの名前が保持されます。

置換メソッドを指定しない場合、MIG の現在の updatePolicy.replacementMethod 値が使用されます。設定されていない場合、デフォルト値(substitute)が使用され、ランダムに生成された名前を持つ新しいインスタンスで VM インスタンスが置き換えられます。

gcloud コマンドライン ツールまたは API を使用して、置換メソッドを指定します。

gcloud

rolling-action コマンドを発行する場合は、--replacement-method=recreate を含めます。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --replacement-method=recreate \
    --version template=new-template \
    --max-unavailable 5 \
    [--zone zone | --region region]

指定したすべてのインスタンスが更新されるまで待機する必要がある場合は、グループのステータスを確認し、グループが安定するまで待ちます。

API

マネージド インスタンス グループの patch メソッドへのリクエストを作成し、updatePolicy.replacementMethod フィールドを含めます。リージョン MIG の場合は、リージョン patch メソッドを使用します。

PATCH /compute/v1/projects/project/zones/zone/instanceGroupManagers/instance-group-name
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/new-template"
    } ]
}

リージョン マネージド インスタンス グループの更新

リージョン マネージド インスタンス グループには、リージョン内の複数のゾーンにまたがる VM インスタンスが含まれています。これに対して、ゾーン マネージド インスタンス グループには 1 つのゾーンのインスタンスしか含まれていません。リージョン マネージド インスタンス グループを使用すると、インスタンスを複数のゾーンに分散して、アプリの可用性を向上させることができます。また、1 つのゾーンで障害が発生する、インスタンスのグループ全体が応答しなくなるなどの極端なケースにも対応できます。

Updater によるリージョン マネージド インスタンス グループの更新は、ゾーン マネージド インスタンス グループでの更新と同じですが、下に説明するような例外があります。リージョン インスタンス グループの更新を開始すると、Updater はインスタンスの更新を各ゾーンに比例的かつ均等に実行します。どのゾーンのどのインスタンスを最初に実行するかを指定したり、1 つのゾーンのインスタンスだけを更新したりすることはできません。

リージョン マネージド インスタンス グループとゾーン マネージド インスタンス グループの更新の違い

リージョン マネージド インスタンス グループの更新を開始する前に、ゾーン マネージド インスタンス グループとはさまざまな点で動作が異なることを理解してください。

  • リージョン マネージド インスタンス グループのデフォルトの更新パラメータは maxUnavailable=number-of-zonesmaxSurge=number-of-zones です。number-of-zones はリージョン マネージド インスタンス グループ用に選択されているゾーンの数(デフォルトは 3)です。

  • 更新を指定するときに固定数を使用する場合、その値は 0 か、リージョン マネージド インスタンス グループに関連付けられたゾーン数以上の数にする必要があります。たとえばインスタンス グループが 3 つのゾーンに分散されている場合、maxSurge12 に設定できません。これは、Updater が 3 つのゾーンそれぞれに追加のインスタンスを作成する必要があるためです。

更新リクエストで固定数または割合を使用する

更新リクエストで固定数を指定する場合、指定する数値はリージョン マネージド インスタンス グループのゾーンの数で除算され、均等に分散されます。たとえば、maxSurge=10 を指定すると、Updater はリージョン内のゾーンの数で 10 を除算し、その値に基づいて新しいインスタンスを作成します。インスタンスの数がゾーン間で均等にならない場合、Updater は任意のゾーンにインスタンスを追加します。そのため、3 つのゾーンに 10 のインスタンスがある場合、2 つのゾーンでインスタンスが 3 つずつ作成され、1 つのゾーンでインスタンスが 4 つ作成されます。カナリア更新の maxUnavailable パラメータと targetSize パラメータに対しても同じロジックが適用されます。

割合を指定できるのは、マネージド インスタンス グループの VM インスタンスが 10 以上ある場合に限ります。割合の扱い方は、場合によってやや異なります。

  • カナリア更新する VM インスタンスの割合を指定する場合、Updater はインスタンスをゾーン間で均等に分散しようとします。余りは各ゾーンで切り上げまたは切り捨てされますが、全体での差はグループあたり VM インスタンス 1 つを超えることはありません。たとえばマネージド インスタンス グループに 10 個のインスタンスがあり、ターゲット サイズの割合が 25% の場合、更新は 2~3 個の VM インスンタンスにロールアウトされます。

  • maxSurgemaxUnavailable などの更新オプションで割合を指定すると、その割合はゾーンごとに独立して四捨五入され丸められます。ゾーン マネージド インスタンス グループの更新と同じルールがここでも適用されます。

更新のモニタリング

ローリング アップデートを開始した後、更新が完了するまで時間がかかる場合があります。更新の進捗状況をモニタリングするには、マネージド インスタンス グループの status を調べるか、マネージド インスタンス グループ内の各インスタンスでの currentAction を確認します。

グループのステータス

グループレベルでは、Compute Engine により、versionTarget.isReached フラグと isStable フラグを含む status という読み取り専用フィールドに値が設定されます。このフラグには、gcloud ツールAPI を使用してアクセスできます。Console を使用して、現在更新中のインスタンス数とターゲット数を確認することもできます。

Console

特定のインスタンス グループの詳細ページに移動すると、グループのローリング アップデートをモニタリングできます。

  1. Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. モニタリング対象のインスタンス グループを選択します。インスタンス グループの概要ページに、各インスタンスが使用するテンプレートが表示されます。
  3. 詳細を表示するには、[詳細] タブをクリックします。

[詳細] ページには、更新するインスタンスの現在の数とターゲット数がインスタンス テンプレートごとに表示されます。

gcloud

インスタンス グループの更新でロールアウトが完了したことを確認するには、describe コマンドを使用して status.versionTarget.isReached==true をチェックします。グループ内のすべてのインスタンスが実行中で正常である(つまり、各マネージド インスタンスの currentActionNONE となっている)ことを確認するには、status.isStable==true をチェックします。

マネージド インスタンス グループの安定性は、Updater 以外のグループ構成にも依存します。たとえば、グループが自動スケーリングされる場合、現在スケールアウト中であれば、オートスケーラーのオペレーションにより isStable==false となります。

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region zone]

gcloud ツールが返すインスタンス グループの詳細情報には、status.versionTarget.isReachedstatus.isStable フィールドが含まれます。

gcloud compute instance-groups managed wait-until コマンドに --version-target-reached フラグを付けて使用すると、グループの status.versionTarget.isReachedtrue になるまで待機することもできます。

gcloud compute instance-groups managed wait-until instance-group-name \
    --version-target-reached \
    [--zone zone | --region region]

API

インスタンス グループの更新でロールアウトが完了したことを確認するには、インスタンス グループ マネージャーの get メソッドを使用して status.versionTarget.isReached==true をチェックします。グループ内のすべてのインスタンスが実行中で正常である(つまり、各マネージド インスタンスの currentActionNONE となっている)ことを確認するには、status.isStable==true をチェックします。

マネージド インスタンス グループの安定性は、Updater 以外のグループ構成にも依存します。たとえば、グループが自動スケーリングされる場合、現在スケールアウト中であれば、オートスケーラーのオペレーションにより isStable==false となります。

GET https://compute.googleapis.com/compute/v1/projects/project-d/zones/zone/instanceGroupManagers/instance-group-name/get

インスタンス グループがリージョン マネージド インスタンス グループの場合は、zones/zoneregions/region に置き換えます。

API は、インスタンス グループに関する詳細情報を返します。返される情報に、status.versionTarget.isReached フィールドと status.isStable フィールドが含まれます。

更新の公開が完了したかどうかの確認

グループ内のすべての VM インスタンスが、ターゲット バージョンで作成されたか作成中になった時点で、更新のロールアウトは完了したとみなされます。完全なロールアウトの場合、すべてのインスタンスは新しいインスタンス テンプレートを使用するように構成されます。部分的なロールアウトの場合は、インスタンス テンプレートごとに分けて、指定されたターゲットに応じて構成されます。

instanceGroupManagers(または regionInstanceGroupManagers)リソースの status.versionTarget.isReached フィールドの値を調べることで、更新のロールアウトが完了したかどうかを確認できます。

  • すべての VM インスタンスがターゲット バージョン(versions[])を使用して作成されたか作成中の場合、status.versionTarget.isReachedtrue に設定されます。
  • ターゲット バージョン(versions[])を使用していない VM がまだ 1 つでもある場合、status.versionTarget.isReachedfalse に設定されます。カナリア更新の場合は、ターゲット バージョン(versions[].instanceTemplates)を使用している VM の数がターゲット サイズ(versions[].targetSize)と一致しないと、status.versionTarget.isReachedfalse に設定されます。

マネージド インスタンス グループが安定しているかどうかの確認

マネージド インスタンス グループが正常に稼働していることを確認するには、status.isStable フィールドの値を調べます。

status.isStablefalse の場合、これは変更がアクティブか、保留中か、またはマネージド インスタンス グループ自体が変更中であることを意味します。

status.isStabletrue の場合は、次のことを意味します。

  • なんらかの変更が行われているインスタンスがマネージド インスタンス グループ内に 1 つもなく、すべてのインスタンスの currentActionNONE となっている。
  • 変更が保留中になっているインスタンスがマネージド インスタンス グループ内に 1 つもない。
  • マネージド インスタンス グループ自体も変更されていない。

マネージド インスタンス グループの変更はさまざまな原因で発生します。次に例を示します。

  • 新しいインスタンス テンプレートのロールアウトをリクエストした。
  • グループ内のインスタンスの作成、削除、サイズ変更、または更新をリクエストした。
  • オートスケーラーからグループのサイズ変更がリクエストされた。
  • 自動修復ツールリソースが、マネージド インスタンス グループ内の正常な状態でないインスタンスを少なくとも 1 つ置き換えた。
  • リージョン マネージド インスタンス グループ内の一部のインスタンスが再配布された。

すべてのアクションが終了すると、そのマネージド インスタンス グループの status.isStabletrue に再び設定されます。

インスタンスでの現在のアクション

実行されている currentAction とマネージド インスタンス グループの各インスタンスの status を確認するには、gcloud コマンドライン ツールまたは API を使用します。

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud は、インスタンス グループ内のインスタンスのリスト、インスタンスのステータス、現在のアクションを返します。次に例を示します。

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

API で、regionInstanceGroupManagers.listManagedInstances メソッドに GET リクエストを送信します。ゾーン マネージド インスタンス グループの場合は、instanceGroupManagers.listManagedInstances メソッドを使用します。

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

API は、グループの各インスタンスの instanceStatuscurrentAction を含めたリストを返します。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  }
 ]
}

マネージド インスタンス グループに含まれる各インスタンスのステータスは、それぞれのインスタンスの instanceStatus フィールドで記述されます。有効な instanceStatus フィールドのリストを確認するには、インスタンスのステータスの確認をご覧ください。

インスタンスでなんらかの変更が行われている場合、currentAction フィールドに次のいずれかのアクションが入力されます。これは変更の進捗状況を追跡するのに役立ちます。それ以外の場合、currentAction フィールドは NONE になります。

有効な currentAction の値は次のとおりです。

  • ABANDONING。インスタンスはマネージド インスタンス グループから削除中です。
  • CREATING。インスタンスは作成中です。
  • CREATING_WITHOUT_RETRIES。再試行なしでインスタンスを作成しています。インスタンスが最初の試行で作成できなかった場合、マネージド インスタンス グループはインスタンスの置換を行いません。
  • DELETING。インスタンスは削除中です。
  • RECREATING。インスタンスは置換中です。
  • REFRESHING。インスタンスは現在のターゲット プールから削除中で、現在のターゲット プールのリスト(このリストは既存のターゲット プールと同じ場合も異なる場合もあります)に再度追加中です。
  • RESTARTING。インスタンスは stop メソッドと start メソッドを使用して再起動中です。
  • VERIFYING。インスタンスは作成済みで、検証中です。
  • NONE。インスタンスに対して実行されているアクションはありません。

更新のロールバック

更新を前のバージョンにロールバックする明示的なコマンドはありませんが、更新をロールバックする場合(完全な commit 更新またはカナリア更新)は、新しい更新リクエストを行い、ロールバック基準とするインスタンス テンプレートを渡すことで実現できます。

たとえば、次の gcloud コマンドを実行すると、可能な限り迅速に更新がロールバックされます。old-instance-template は、ロールバックするインスタンス テンプレートの名前で置き換えます。

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=old-instance-template-name --max-unavailable 100% [--zone zone | --region region]

old-instance-template-name は、ロールバックするインスタンス テンプレートの名前で置き換えます。

API で、次のように PATCH リクエストをインスタンス グループ マネージャー リソースに送信します。

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

インスタンス グループがリージョン マネージド インスタンス グループの場合は、zones/zoneregions/region に置き換えます。

リクエストの本文で、以前のインスタンス テンプレートを version として指定します。

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/old-template" # Old instance template
    }
   ]
}

インスタンス数が 10 個に達しないリージョン マネージド インスタンス グループの場合、maxUnavailable には固定値を使用する必要があります。固定値として使用する値は、グループに含まれるインスタンスの数です。

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": number-of-instances-in-group
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/old-template" # Old instance template
    }
   ]
}

Updater はこれを通常の更新リクエストとして処理するため、このドキュメントで説明しているすべての更新オプションをリクエストで指定できます。

更新速度の管理

デフォルトでは、更新リクエストを送ると、サービスはできる限り迅速に更新を実行します。更新を完全に適用するか、暫定的に変更をテストするか判断できない場合は、次の方法で更新速度を制御できます。

  1. 完全な更新ではなく、カナリア更新を開始します。
  2. minReadySec に大きい値を設定します。この値を設定すると、サービスはここで指定した秒数待機してから、インスタンスが正常に更新されたものとみなして次のインスタンスに進みます。
  3. ヘルスチェックを有効化します。これにより、サービスはアプリが起動して正常のシグナルを報告するまで待機してから、インスタンスが正常に更新されたものとみなして次のインスタンスに進みます。
  4. maxUnavailablemaxSurge に小さい値を設定します。これにより、最小数のインスタンスのみが一度に更新されます。
  5. 手動で特定のインスタンスに対して更新を開始し、インスタンスを直ちに更新します。

これらのパラメータの組み合わせを使用して、更新のレートを制御することもできます。

更新の停止

更新を停止する明示的な方法やコマンドはありません。更新はプロアクティブから日和見に変更できます。マネージド インスタンス グループがオートスケーラーなどの他のサービスでサイズ変更されていない場合、日和見へ変更することで、更新を実質的に停止できます。

更新をプロアクティブから日和見に変更するには、次のコマンドを実行します。

gcloud compute instance-groups managed rolling-action stop-proactive-update instance-group-name \
    [--zone zone | --region region]

更新をプロアクティブから日和見へ変換した後、更新を完全に停止する場合は、次の手順で停止できます。

  1. 更新されたインスタンスの数を確認するリクエストを送ります。

    gcloud compute instance-groups managed list-instances instance-group-name \
        [--zone zone | --region region]

    gcloud ツールは、インスタンス グループ内のインスタンスの一覧とその現在のステータスを含むレスポンスを返します。

    >
    NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      my-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      my-old-template
    vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  my-new-template
    

    この例では、2 つのインスタンスがすでに更新されています。

  2. 次に、新しい更新を実行するリクエストを作成しますが、すでに更新されているインスタンスの数をターゲット サイズとして渡します。

    gcloud compute instance-groups managed rolling-action start-update instance-group-name \
        --version template=my-old-template \
        --canary-version template=my-new-template,target-size=2 \
        [--zone zone | --region region]

    Updater では、この更新は完了として示されるため、他のインスタンスは更新されず、更新は実質的に停止されます。

マネージド インスタンス グループのバージョンと instanceTemplate プロパティの関係

Google では、versions フィールドを使用してマネージド インスタンス グループのインスタンス テンプレートを構成することをおすすめしています。

レガシーの instanceTemplate フィールドは、機能的に versions と重複しています。どちらのフィールドも、マネージド インスタンス グループでインスタンスを作成するために使用するインスタンス テンプレートを指定できます。ただし、高度な 2 つのテンプレート(カナリア)構成を指定できるのは、versions フィールドのみです。

下位互換性を維持するために、マネージド インスタンス グループでは引き続き最上位の instanceTemplate フィールドの設定がサポートされますが、versions フィールドのみの使用に切り替えることをおすすめします。最上位の instanceTemplate フィールドと versions フィールドを同時に使用すると、曖昧さや混乱の原因となります。

update() メソッドや patch() メソッドを呼び出す際に instanceTemplateversions の両方のフィールドを指定した場合、次の 3 つの可能性が考えられます。

  • 両方のフィールドを同じ値に設定する。

    これは有効なリクエストです。この場合、曖昧さがなくなり、新しいインスタンス テンプレートがマネージド インスタンス グループに適用されます。

    たとえば、次のリクエストでは、最上位の instanceTemplate フィールドと versions フィールドに同じインスタンス テンプレートを指定していて、そのテンプレートは現在のテンプレートとは異なります。そのため、マネージド インスタンス グループは新しいインスタンス テンプレートに更新されます。

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 両方のフィールドの設定値は一致しないが、一方の値だけがマネージド インスタンス グループの現在のインスタンス テンプレートと異なる。

    これは有効なリクエストです。現在の設定と異なるフィールドが、目的の値として取得されます。たとえば、get() メソッドを呼び出し、2 つのフィールドのいずれかを変更してから、その変更した 1 つのフィールドだけを使用して update() を呼び出します。

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 両方のフィールドの設定値は一致せず、両方ともマネージド インスタンス グループの現在のインスタンス テンプレートと異なる。

    この設定は無効で、意図が明確でないためエラーが返されます。

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

versions フィールド、instanceTemplate フィールド、get() メソッド

最上位の instanceTemplate フィールドと versions フィールドの一方または両方を使用して、インスタンス テンプレートを 1 つだけ指定した場合、get() メソッドはそのレスポンスに両方のフィールドを返します。これにより、新しい versions フィールドで下位互換性が維持されます。このいずれかのフィールドに単一のインスタンス テンプレートを指定している限り、get()instanceTemplate フィールドに同じ内容を返します。

versions フィールドに 2 つのインスタンス テンプレートが指定されている場合、get() メソッドは最上位の instanceTemplate フィールドを空の状態で返します。カナリア更新中に最上位の instanceTemplate フィールドが使用されないように、そのフィールドにカナリアの 2 つのインスタンス テンプレート構成を明確に表現する方法はありません。

versions フィールドと setInstanceTemplate() メソッド

下位互換性を確保するために、setInstanceTemplate() メソッドはこれまでと同じように動作し、マネージド インスタンス グループがインスタンスの作成に使用するテンプレートを変更できます。このメソッドを呼び出すと、versions フィールドは setInstanceTemplate() メソッドに指定されたインスタンス テンプレートでオーバーライドされます。

また、setInstanceTemplate() メソッドは updatePolicyOPPORTUNISTIC に設定します。これにより、マネージド インスタンス グループが versions フィールドで明示的に指定されていないインスタンス テンプレートを積極的にデプロイしなくなります。

次のステップ