マネージドインスタンスグループへの更新のロールアウト

マネージドインスタンスグループには、インスタンステンプレートを使用して制御される 1 つ以上の仮想マシンインスタンスが含まれます。マネージドインスタンスグループのインスタンスを更新するには、Managed Instance Group Updater 機能を使用してグループ全体に対する更新リクエストを実行します。

インスタンスグループの詳細については、インスタンスグループの概要をご覧ください。

Managed Instance Group Updater を使用すると、新しいバージョンのソフトウェアをマネージドインスタンスグループにデプロイでき、さらにデプロイの速度、サービス中断のレベル、更新のスコープを制御できます。Updater には主に 2 つの利点があります。

更新のロールアウトは指定に従って自動的に実行されます。初期リクエストの後に追加のユーザー入力を行う必要はありません。
部分的ロールアウトを実行して、カナリアテストを行うことができます。

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

始める前に

このガイドのコマンドラインの例を使用する場合、以下を行います。
1. gcloud コマンドラインツールの最新バージョンをインストールするか、最新バージョンに更新します。
2. デフォルトのリージョンとゾーンを設定します。
1 つのマネージドインスタンスグループを使用します。
インスタンスグループの更新基準とするインスタンステンプレートを使用します。

基本的なローリング更新の開始

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

ローリング更新の実行時に注意すべき点は以下のとおりです。

更新はインテントベースです。 最初の更新リクエストを行うと、API はリクエストが有効であったことを示すために成功のレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたかどうかを判断するには、マネージドインスタンスグループのステータスを確認する必要があります。
Instance Group Updater API は宣言型 API です。この API は明示的な関数呼び出しではなく、マネージドインスタンスグループの更新後に必要な構成を指定するためのリクエストを要求します。
Updater 機能は、マネージドインスタンスグループで最大 2 つのインスタンステンプレートバージョンをサポートしています。マネージドインスタンスグループに 2 つの異なるインスタンステンプレートバージョンを指定できます。これは、カナリア更新を行う場合に便利です。

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

Console

GCP Console の [インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
更新するインスタンスグループを選択します。
ページの上部で [ローリング更新] をクリックします。
[テンプレート] で、プルダウンメニューから更新に使用する新しいテンプレートを選択します。
すべてのインスタンスを更新するには、ターゲットサイズとして「100%」を入力します。
必要に応じて、構成オプションを切り替えられます。たとえば、更新をプロアクティブ（グループが能動的にインスタンスを置き換える）と日和見（グループはインスタンスを能動的には置き換えず、インスタンスが他の手段で置き換えられた場合に更新を適用する）のどちらにするかなどです。また、最大サージ、オフライン上限オプション、最小待機時間も指定できます。
[更新] をクリックして更新を開始します。

gcloud

gcloud ツールで rolling-action start-update コマンドを実行します。

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP] \
    --version template=[INSTANCE_TEMPLATE] [--zone [ZONE] | --region [REGION]]

ここで:

[INSTANCE_GROUP] は、更新するインスタンスグループの名前です。
[INSTANCE_TEMPLATE] は、インスタンスグループの更新基準とする新しいインスタンステンプレートです。
[ZONE] と [REGION] は、インスタンスグループに応じてどちらかを指定します。インスタンスグループがゾーンインスタンスグループの場合はゾーンを、リージョンインスタンスグループの場合はリージョンを指定します。

API

API で、次の URL に PATCH リクエストを行います。

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

インスタンスグループがリージョンマネージドインスタンスグループの場合は、zones/[ZONE] を regions/[REGION] に置き換えます。

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

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

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

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

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

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

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

更新のオプションの設定

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

最大サージ

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

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

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

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

オフライン上限

更新中の任意の時点に特定の数のインスタンスのみオフラインになるよう maxUnavailable を設定します。たとえば、maxUnavailable を 5 に設定すると、更新時に一度に 5 つのインスタンスのみオフラインになります。このパラメータを使用して、更新がサービスにとってどの程度大がかりなものであるか、および、更新がデプロイされるレートを制御します。

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

ゾーンマネージドインスタンスグループでの maxUnavailable のデフォルト値は 1 です。リージョンマネージドインスタンスグループでのデフォルト値は [NUMBER_OF_ZONES] です。これは、そのリージョンマネージドインスタンスグループに選択されているゾーンの数（デフォルトでは 3）です。

最小待機時間

新規作成または再起動したインスタンスを更新済みとみなすまでの待機時間を指定するには、minReadySeconds を設定します。この機能を使用して、更新がデプロイされるレートを制御します。タイマーは、次の条件が両方とも満たされると起動します。

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

ヘルスチェックで healthy が返されるようにするには、Updater が次のように動作することに注意してください。

ヘルスチェックで HEALTHY が返されるまで、autohealingPolicies.initialDelaySec で指定された時間まで待機します。
次に、minReadySeconds で指定された時間だけ待機します。

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

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

最小アクション

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

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

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

RESTART: インスタンスを再起動します（stop と start をリクエストします）。更新リクエストで、変更を反映するためにインスタンスを置き換える必要がある場合（たとえばイメージを変更するには、インスタンスを削除して置き換える必要があります）、強制的に REPLACE が実行されます。
REPLACE: 既存のインスタンスを削除し、ターゲットテンプレートから新しいインスタンスを作成します。Updater によって、内部 IP アドレスや外部 IP アドレスなど、インスタンスプロパティをすべて一新した新たなインスタンスが作成されます。

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

追加の更新例

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

すべての仮想マシンインスタンスのローリング更新を実行するが、ターゲットサイズを超える新しいインスタンスは一度に 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 個の新しいインスタンスを作成してから、前のインスタンステンプレートを実行しているインスタンスの削除を開始します。

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

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --max-surge 10% [--zone [ZONE] | --region [REGION]]

カナリア更新の開始

Instance Group Updater 機能を使用すると、カナリア更新を実行できます。この更新を行うと、更新を完全に commit する前に、インスタンスのサブセットをランダムに作成し、更新をテストすることができます。

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

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

最大 2 つのインスタンステンプレートバージョンを指定します。通常、カナリアに対しては新しいインスタンステンプレートを、残りのインスタンスに対しては現在のインスタンステンプレートを指定します。たとえば、new-instance-template に基づいてインスタンスの 20% が作成され、残りのインスタンスは引き続き old-instance-template で実行されるように指定できます。同時に指定できるインスタンステンプレートは 2 つまでです。
カナリアバージョンにはターゲットサイズ（targetSize）を常に指定する必要があります。カナリアバージョンのターゲットサイズを省略すると、カナリア更新を開始できません。たとえばカナリア処理にインスタンスの 10% を使用するように指定した場合、残り 90% のインスタンスはそのままで、現在のインスタンステンプレートが使用されます。

Console

GCP Console の [インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
更新するインスタンスグループを選択します。
ページの上部で [ローリング更新] をクリックします。
[テンプレート] をクリックして、カナリア更新する新しいインスタンステンプレートを選択します。
[ターゲットサイズ] で、新しいインスタンステンプレートのカナリア更新に使用するインスタンスの割合または固定数を入力します。
必要に応じて、構成オプションを切り替えることができます。たとえば、更新をプロアクティブ（グループがインスタンスの置換を能動的に実行する）と日和見（グループはインスタンスの置換を能動的には実行せず、インスタンスが他の手段で作成された場合に更新を適用する）のどちらにするかなどです。また、最大サージ、オフライン上限オプション、最小待機時間も指定できます。
[更新] をクリックして更新を開始します。

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]]

ここで:

[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 で、次の URI に PATCH リクエストを送ります。

https://www.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] は、インスタンスグループが実行されている現在のテンプレートの名前です。

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

カナリア更新の実行後、インスタンスグループの 100% に対する更新を commit するか、ロールバックするかを決めることができます。

Console

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

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 で、次の URI に PATCH リクエストを送ります。

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

リクエストの本文で、新しいインスタンステンプレートを version として指定し、リクエストの本文から古いインスタンステンプレートを省略します。インスタンスの 100% の更新をロールアウトするには、ターゲットサイズの指定を省略します。たとえば、リクエストの本文は次のようになります。

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

[NEW_TEMPLATE] は、ロールフォワードする新しいインスタンステンプレートの名前で置き換えます。

日和見更新またはプロアクティブ更新の開始

デフォルトでは、gcloud コマンドラインツールで行う更新はプロアクティブになり、API で開始する更新は日和見になります。

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

または、プロアクティブ更新があまりに大がかりになる可能性がある場合は、日和見更新を実施できます。日和見更新が適用されるのは、選択したインスタンスの更新を手動で開始した場合、またはマネージドインスタンスグループによって新しいインスタンスが作成された場合のみです。マネージドインスタンスグループは、そのサイズが別のサービス（オートスケーラーなど）により、またはユーザーによって手動で変更されると、新しいインスタンスを作成します。Compute Engine が更新を適用するためのリクエストを積極的に開始することはありません。

システムの不安定さはできる限り避けたいものであるため、日和見更新は特定のシナリオにおいて有用です。たとえば、緊急性がなく必要に応じて適用できる、重要でない更新があり、アクティブにオートスケーリングされているマネージドインスタンスグループがある場合は、日和見更新を実施して、Compute Engine が更新を適用するために既存のインスタンスを削除しないようにします。

更新が日和見かプロアクティブかを選択するには、gcloud コマンドラインツールまたは API を使用して、タイププロパティを OPPORTUNISTIC または PROACTIVE に設定します。

Console

GCP Console の [インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
更新するインスタンスグループを選択します。
ページの上部で [ローリング更新] をクリックします。
[テンプレート] で、インスタンスグループの更新に使用するテンプレートを選択し、テンプレートのターゲットサイズを選択します。
[更新モード] で、日和見更新とプロアクティブ更新のいずれかを選択します。
[更新] をクリックして更新を開始します。

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 に含めます。

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

[NEW_TEMPLATE] は、カナリア更新に使用する新しいテンプレートの名前です。日和見更新が必要な場合は、PROACTIVE を OPPORTUNISTIC に置き換えます。

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

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

手動で更新を開始する場合、以下のことが可能です。

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

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

更新の特性によっては、インスタンスの状態が損なわれる可能性があります。たとえば、インスタンスのマシンタイプを変更するには VM の再起動が必要になる一方、VM のブートイメージを変更するにはインスタンスを削除して置き換える必要があります。

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

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

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

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

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

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

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

gcloud

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

gcloud beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

ここで

[INSTANCE_GROUP] は、更新が保留中のインスタンスグループの名前です。
[INSTANCE_NAMES] は、直ちに更新するインスタンスのリストです。
[DISRUPTION_LEVEL] は、最小または最大の中断レベルです（NONE、REFRESH、RESTART、REPLACE）。
- デフォルトの minimal-action は NONE です。
- デフォルトの most-disruptive-allowed-action は REPLACE です。

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

API

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

POST https://www.googleapis.com/compute/beta/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] は、最小または最大の中断レベルです（NONE、REFRESH、RESTART、REPLACE）。
- デフォルトの minimalAction は NONE です。
- デフォルトの mostDisruptiveAllowedAction は REPLACE です。

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

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

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

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

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

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

すべてのインスタンスが削除され、新しいインスタンスに置き換えられる置換を実行するには次の手順に従います。

Console

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

gcloud

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

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

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

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

API

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

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

PATCH https://www.googleapis.com/compute/v1/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

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

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

PATCH https://www.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"
  }
 ]
}

追加の置換 / 再起動の例

すべての仮想マシンのローリング再起動を一度に 2 個ずつ実行する

このコマンドは、インスタンスグループ内のすべての仮想マシンを一度に 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]]

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

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

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

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

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

リージョンマネージドインスタンスグループのデフォルトの更新パラメータは maxUnavailable=[NUMBER_OF_ZONES] と maxSurge=[NUMBER_OF_ZONES] です。[NUMBER_OF_ZONES] はリージョンマネージドインスタンスグループ用に選択されているゾーンの数（デフォルトは 3）です。
更新を指定するときに固定数を使用する場合、固定数は 0 か、リージョンマネージドインスタンスグループに関連付けられたゾーン数以上の数にする必要があります。たとえばインスタンスグループが 3 つのゾーンに分散されている場合、maxSurge は 1 や 2 に設定できません。これは、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 インスンタンスにロールアウトされます。
maxSurge や maxUnavailable などの更新オプションで割合を指定すると、その割合はゾーンごとに独立して四捨五入され丸められます。ゾーンマネージドインスタンスグループの更新と同じルールがここでも適用されます。

更新のモニタリング

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

グループのステータス

Compute Engine はグループごとに、status という名前の読み取り専用フィールドに値を取り込みます。このフィールドには、versionTarget.isReached フラグと isStable フラグが含まれています。これらのフラグにアクセスするには、gcloud ツールまたは API を使用できます。

インスタンスグループの更新でロールアウトが完了したこと確認するには、status.versionTarget.isReached==true となっていることを確認します。グループ内のすべてのインスタンスが正常に稼働していること（つまり、各マネージドインスタンスの currentAction が NONE となっていること）を確認するには、status.isStable==true となっていることを確認します。マネージドインスタンスグループの安定性は、Updater の管理が及ばない、グループの構成に依存します。たとえば、グループが自動スケーリングされる場合、現在スケールアップ中であれば、オートスケーラーのオペレーションにより isStable==false となります。

Console を使用して、現在更新中のインスタンス数とターゲット数を確認することもできます。

Console

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

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

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

gcloud

gcloud compute instance-groups managed describe [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

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

API

API では、次の URI に POST リクエストを送ります。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/get

インスタンスグループがリージョンマネージドインスタンスグループの場合は、zones/[ZONE] を regions/[REGION] に置き換えます。

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

status.versionTarget.isReached

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

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

すべての VM インスタンスがターゲットバージョン（versions[]）を使用して作成されたか作成中である場合、status.versionTarget.isReached は true に設定されます。

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

また、--version-target-reached フラグを指定した gcloud beta compute instance-groups managed wait-until コマンドを使用して、グループに対して status.versionTarget.isReached が true に設定されるまで待機することもできます。

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone [ZONE] | --region [REGION]]

status.isStable

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

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

status.isStable が true に設定されている場合は、次のことを意味します。

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

マネージドインスタンスグループは、さまざまな方法で変更できます。次に例を示します。

新しいインスタンステンプレートのロールアウトをリクエストする。
グループ内のインスタンスの作成、削除、サイズ変更、または更新をリクエストする。
オートスケーラーによってグループのサイズ変更をリクエストする。
オートヒーラーリソースで、マネージドインスタンスグループ内の 1 つ以上の正常な状態でないインスタンスを置き換える。
リージョンマネージドインスタンスグループ内の一部のインスタンスを再配布する。

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

また、--stable フラグを指定した gcloud beta compute instance-groups managed wait-until コマンドを使用して、グループに対して status.isStable が true に設定されるまで待機することもできます。

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

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

グループ内の各インスタンスに対して現在実行されている 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           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 では、次の URI に POST リクエストを送ります。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

インスタンスグループがリージョンマネージドインスタンスグループの場合は、zones/[ZONE] を regions/[REGION] に置き換えます。

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

{
 "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: インスタンスは再試行なしの条件で作成されています。1 回目でインスタンスを作成できなかった場合、マネージドインスタンスグループはインスタンスの置換を再度行いません。
DELETING: インスタンスは削除中です。
RECREATING: インスタンスは削除済みで、置換中です。
REFRESHING: インスタンスは現在のターゲットプールから削除中で、現在のターゲットプールのリスト（このリストは既存のターゲットプールと同じ場合も異なる場合もあります）に再度追加中です。
RESTARTING: インスタンスは stop メソッドと start メソッドを使用して再起動中です。
VERIFYING: インスタンスは作成済みで、検証中です。
NONE: インスタンスに対して実行されているアクションはありません。

インスタンスが正常に更新されると、instanceStatus フィールドにインスタンスの現在の状態が反映されます。

更新のロールバック

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

たとえば、次のコマンドを実行すると、可能な限り迅速に更新がロールバックされます。

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[OLD_INSTANCE_TEMPLATE] --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

[OLD_INSTANCE_TEMPLATE] は、ロールバックする古いインスタンステンプレートの名前で置き換えます。

API で、次の URI に PATCH リクエストを送ります。

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

インスタンスグループがリージョンマネージドインスタンスグループの場合は、zones/[ZONE] を regions/[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
    }
   ]
}

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

更新速度の管理

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

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

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

更新の停止

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

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

gcloud compute instance-groups managed rolling-action stop-proactive-update [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

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

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

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

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

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

この例では、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 フィールドのみの使用に切り替えることをおすすめします。両方のフィールドを同時に使用すると、曖昧さや混乱の原因となります。

update() メソッドや patch() メソッドを呼び出す際に instanceTemplate フィールドと versions フィールドの両方を指定した場合、次の 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() メソッドに指定されたインスタンステンプレートでオーバーライドされます。

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

次のステップ

インスタンスグループの詳細
インスタンステンプレートの詳細

マネージド インスタンス グループへの更新のロールアウト

始める前に

基本的なローリング更新の開始

Console

gcloud

API

更新のオプションの設定

最大サージ

オフライン上限

最小待機時間

最小アクション

追加の更新例

カナリア更新の開始

Console

gcloud

API

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

Console

gcloud

API

日和見更新またはプロアクティブ更新の開始

Console

gcloud

API

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

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

gcloud

API

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

Console

gcloud

API

追加の置換 / 再起動の例

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

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

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

更新のモニタリング

グループのステータス

Console

gcloud

API

status.versionTarget.isReached

status.isStable

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

gcloud

API

更新のロールバック

更新速度の管理

更新の停止

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

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

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

次のステップ

フィードバックを送信...

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

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

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

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

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

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