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

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

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

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

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

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

始める前に

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

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

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

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

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

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

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

Console

  1. GCP 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] \
    --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 が次のように動作することに注意してください。

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

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

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

最小アクション

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

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

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

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

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

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

さまざまな Updater オプションによるリクエストへの影響を説明する図

追加の更新例

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

すべての仮想マシン インスタンスのローリング更新を実行するが、ターゲット サイズを超える新しいインスタンスは一度に 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

  1. GCP 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]]

ここで:

  • [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

  1. GCP 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 で、次の 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

選択したインスタンスを更新するには、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] は、最小または最大の中断レベルです(NONEREFRESHRESTARTREPLACE)。
    • デフォルトの minimal-actionNONE です。
    • デフォルトの most-disruptive-allowed-actionREPLACE です。

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

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] は、最小または最大の中断レベルです(NONEREFRESHRESTARTREPLACE)。
    • デフォルトの minimalActionNONE です。
    • デフォルトの mostDisruptiveAllowedActionREPLACE です。

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

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

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

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

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

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

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

Console

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

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

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

gcloud

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

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

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

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

API

API で、グループの PATCH リクエストを実行し、プロアクティブな updatePolicy を設定します。minimalAction は、各インスタンスが削除され新しいインスタンスに置換されるローリング置換または各インスタンスが停止して再起動されるローリング再起動を実行するかどうかに応じて RESTART または REPLACE になります。RESTARTREPLACE のどちらの場合も、常に versions.instanceTemplateversions.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 つのゾーンに分散されている場合、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 はグループごとに、status という名前の読み取り専用フィールドに値を取り込みます。このフィールドには、versionTarget.isReached フラグと isStable フラグが含まれています。これらのフラグにアクセスするには、gcloud ツールまたは API を使用できます。

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

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

Console

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

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

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

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

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

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

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

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

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

status.isStable

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

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

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

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

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

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

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

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

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 は、グループの各インスタンスの 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: インスタンスは再試行なしの条件で作成されています。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 サービスはこれを通常の更新リクエストとして処理するため、このドキュメントで説明しているすべての更新オプションをリクエストで指定できます。

更新速度の管理

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

  1. 完全な更新ではなく、カナリア更新を開始します。
  2. minReadySeconds に大きい値を設定します。この値を設定すると、サービスはここで指定した秒数待機してから、インスタンスが正常に更新されたものとみなして次のインスタンスに進みます。
  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   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 つのインスタンスがすでに更新されています。

  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() メソッドに指定されたインスタンス テンプレートでオーバーライドされます。

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

Compute Engine ドキュメント