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

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

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

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

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

始める前に

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

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

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

ローリング更新を実行するときに注意する点は、次のとおりです。

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

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

Console

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

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/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 です。リージョンマネージドインスタンスグループのデフォルト値は、リージョンマネージドインスタンスグループに関連付けられているゾーンの数です。

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

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

オフライン上限

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

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

ゾーンマネージドインスタンスグループでの maxUnavailable のデフォルト値は 1 です。リージョンマネージドインスタンスグループでの number-of-zones のデフォルト値は 3 で、選択されているゾーンの数にあたります。

最小待機時間

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

インスタンスのステータスが RUNNING である。
ヘルスチェックが有効の場合、ヘルスチェックのときに 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 アドレスなど、インスタンスプロパティをすべて一新したインスタンスが作成されます。

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

追加の更新例

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

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

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

gcloud

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

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

上記コマンドで、次の部分は置き換えます。

current-instance-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-instance-template"
  }
 ]
}

上記コマンドで、次の部分は置き換えます。

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

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

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

Console

Cloud 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 で、次のように PATCH リクエストをインスタンスグループマネージャーリソースに送信します。

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

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

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

new-template は、ロールフォワードする新しいインスタンステンプレートの名前に置き換えます。

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

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

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

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

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

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

Console

Cloud 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 に含めます。new-template は、カナリアに使用する新しいテンプレート名で置き換えます。追従型更新を設定したい場合は、PROACTIVE を OPPORTUNISTIC に置き換えます。

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

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

追従型更新を開始した場合は、更新の機会が生じて 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-name \
    --instances instance-names \
    --most-disruptive-allowed-action disruption-level \
    --minimal-action disruption-level

ここで

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

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

API

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

POST https://compute.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

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

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

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

API

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

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

PATCH https://compute.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://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 インスタンスが含まれています。これに対して、ゾーンマネージドインスタンスグループには 1 つのゾーンのインスタンスしか含まれていません。リージョンマネージドインスタンスグループを使用すると、インスタンスを複数のゾーンに分散して、アプリの可用性を向上させることができます。また、1 つのゾーンで障害が発生したり、インスタンスのグループ全体が応答しなくなるような極端なケースにも対応できます。

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

Console

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

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

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

gcloud

describe コマンドを次のように使用します。

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

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

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

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

API

次のようにインスタンスグループマネージャーの get メソッドを使用します。

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

インスタンスグループがリージョンマネージドインスタンスグループの場合は、zones/<var>zone</var></code> with リージョン/regionを置き換えます。

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

更新の公開が完了したかどうかの確認（ベータ版）

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

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 に設定されます。

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

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

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

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

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

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

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

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

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

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

このタスクに必要な権限

このタスクを実行するには、次の権限が必要です。

インスタンスグループの compute.instanceGroupManagers.get
インスタンスグループの compute.instanceGroupManagers.list

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 は、グループの各インスタンスの instanceStatus と currentAction を含めたリストを返します。

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

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 フィールドのみの使用に切り替えることをおすすめします。最上位の 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() メソッドに指定されたインスタンステンプレートでオーバーライドされます。

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

次のステップ

インスタンスグループの詳細を確認する。
インスタンステンプレートの詳細を確認する。

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

始める前に

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

Console

gcloud

API

更新のオプションの設定

最大サージ

オフライン上限

最小待機時間

最小アクション

追加の更新例

カナリア更新の開始

Console

gcloud

API

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

Console

gcloud

API

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

Console

gcloud

API

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

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

gcloud

API

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

Console

gcloud

API

追加の置換 / 再起動の例

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

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

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

更新のモニタリング

グループのステータス

Console

gcloud

API

更新の公開が完了したかどうかの確認（ベータ版）

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

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

このタスクに必要な権限

gcloud

API

更新のロールバック

更新速度の管理

更新の停止

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

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

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

次のステップ

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

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

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

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

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

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

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

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