MIG のインスタンスに更新を自動的にロールアウトする

このドキュメントでは、マネージド インスタンス グループ(MIG)内の仮想マシン(VM)インスタンスのすべてまたはランダムなサブセットに新しいインスタン ステンプレートを自動的に適用する方法について説明します。

自動更新を構成すると、MIG はインスタンス テンプレートの新しいバージョンを自動的にロールアウトします。デプロイの速度、サービス中断のレベル、MIG を更新するインスタンスの数を制御できます。更新を開始後、追加の入力を指定する必要はありません。更新は自動で完了します。

新しいテンプレートを MIG の新しいインスタンスまたは特定のインスタンスのみに適用する場合や、ステートフル MIG を使用していて、ステートフルなインスタンスごとの構成を提要する場合は、MIG でインスタンスを選択して更新するをご覧ください。方法を判断する場合は、自動選択か部分的更新かを選択するをご覧ください。

始める前に

制限事項

  • MIG にステートフル構成がある場合、自動ローリング アップデートは使用できません。代わりに、特定のインスタンスを更新することで、更新を制御し、中断を制限できます。
  • カスタム インスタンス名を使用して、ステートフル ディスクやメタデータを構成しない場合は、自動更新を使用できます。ただし、インスタンス名を保持するには、置換メソッドRECREATE に設定する必要があります。

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

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

ローリング アップデートの実行時に注意すべき点は以下のとおりです。

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

  • Instance Group Updater API は宣言型 API です。この API は、明示的な関数呼び出しではなく、MIG の更新後に必要な構成を指定するためのリクエストを必要とします。

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

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

Console

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

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

  2. 更新する MIG を選択します。

  3. ページ上部の [ローリング更新] をクリックします。

  4. [テンプレート] のプルダウン リストをクリックし、更新に使用する新しいテンプレートを選択します。

  5. 全インスタンスを更新するために、ターゲット サイズには「100%」と入力します。

  6. [更新モード] で [先行型] を選択します。

  7. [更新] をクリックして更新を開始します。

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: MIG の名前
  • INSTANCE_TEMPLATE_NAME: 新しいインスタンス テンプレート
  • ZONE: ゾーン MIG には、ゾーンを指定します
  • REGION: リージョン MIG には、リージョンを指定します

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

たとえば、リージョン MIG の場合、次のリクエストは、すべてのインスタンスを新しいインスタンス テンプレートに自動的に更新するために必要な最小構成を示しています。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

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

詳細な構成を行う場合は、その他の更新オプションを含めます。特に指定しない場合、maxSurge オプションと maxUnavailable オプションはデフォルトで 1 に影響を受けるゾーンの数を掛けたものになります。つまり、影響を受ける各ゾーン内では 1 つのインスタンスだけがオフラインになり、MIG は更新中にゾーンごとに 1 つの追加インスタンスのみを作成します。

更新のオプションの構成

より複雑な更新の場合は、追加オプションを構成できます。これらのオプションについては、次のセクションで説明します。

モード

自動ローリング更新の場合は、モードをプロアクティブに設定する必要があります。

また、自動更新が大がかりになる可能性がある場合は、日和見更新の実行を選択できます。MIG は、選択したインスタンスの更新を手動で開始した場合、または新しいインスタンスが作成された場合にのみ、日和見更新を適用します。ご自身や別のサービス(オートスケーラーなど)で MIG をサイズ変更すると、新しいインスタンスが作成されます。既存のインスタンスで、日和見更新を適用するためのリクエストが Compute Engine から積極的に開始されることはありません。

自動更新と部分的更新の詳細については、自動選択か部分的更新かを選択するをご覧ください。

最大サージ

maxSurge オプションを使用すると、自動更新中に MIG が targetSize を超えて作成できる新しいインスタンスの数を構成できます。たとえば、maxSurge を 5 に設定すると、MIG は新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスを作成します。maxSurge の値が大きくなるほど更新速度は上がりますが、インスタンスの追加による費用がかかります。この費用は Compute Engine の料金表に従って課金されます。

固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り上げます。

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

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

このオプションは、REPLACE 最小アクションで構成されている場合に限り認識され、RESTART アクション設定ではサポートされていません。

オフライン上限

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

この数値には、他の理由でオフラインになっているインスタンスの数も含まれます。たとえば、グループがサイズ変更の処理中である場合、作成中のインスタンスがオフラインになることがあります。このようなインスタンスの数は、maxUnavailable にカウントされます。

固定数を指定するか、グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り下げます。

更新中に使用できないマシンをなくしたい場合は、maxUnavailable 値を 0 に設定し、maxSurge の値を 0 より大きい値に設定します。この設定を行うと、Compute Engine は、古いマシンの代替マシンを新規に作成して実行した後にのみ、古いマシンを削除します。

maxUnavailable の値を設定していない場合は、デフォルト値が使用されます。ゾーン MIG の場合、デフォルトは 1 です。リージョン MIG の場合、デフォルトはグループに関連付けられたゾーンの数です。デフォルトでは 3 です。

最小待機時間

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

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

ヘルスチェックを行うにあたり、Updater は次の条件が満たされるのを待ちます。

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

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

グループのヘルスチェックが行われない場合、タイマーはインスタンスのステータスが RUNNING のときに起動します。

minReadySec フィールドの最大値は 3,600 秒(1 時間)です。

最小アクション

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

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

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

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

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

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

ポリシー更新のオプションがリクエストに与える影響

置換メソッド

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

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

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

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

指定できる replacementMethod 値は次のとおりです。

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

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

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

追加の更新例

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

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

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

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

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

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

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

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

カナリア更新

カナリア更新とは、グループ内のインスタンスのサブセットに適用される更新です。カナリア更新を使用すると、大がかりになる可能性のある更新をすべてのインスタンスにロールアウトするのではなく、ランダムなインスタンスのサブセットで新しい機能または更新をテストできます。更新がうまくいかない場合、単にインスタンスのサブセットをロールバックするだけで済み、ユーザーに対する影響を最小限に抑えることができます。

カナリア更新は、更新が必要なインスタンス数がインスタンス グループの合計サイズより小さい点を除いては、標準のローリング アップデートと同じです。標準のローリング アップデートと同様に、追加のオプションを構成してサービス中断のレベルを制御できます。

カナリア更新の開始

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

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

Console

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

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

  2. 更新するマネージド インスタンス グループを選択します。
  3. ページ上部の [ローリング更新] をクリックします。
  4. [テンプレート] をクリックして、カナリア更新する新しいインスタンス テンプレートを選択します。
  5. [ターゲット サイズ] で、新しいインスタンス テンプレートのカナリア更新に使用するインスタンスの数、または割合を入力します。
  6. 必要に応じて、他の更新オプションを構成できます。
  7. [更新] をクリックして更新を開始します。

gcloud

rolling-action start-update コマンドを使用します。現在のテンプレートと新しいテンプレートを両方指定し、各テンプレートを使用するインスタンス数を明示的に指定します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

以下を置き換えます。

  • INSTANCE_GROUP_NAME: インスタンス グループ名。
  • CURRENT_INSTANCE_TEMPLATE_NAME: インスタンス グループが実行されているインスタンス テンプレート。
  • NEW_TEMPLATE: カナリア更新に使用する新しいテンプレート。
  • SIZE: この更新を適用するインスタンスの数または割合。target-size プロパティは、--canary-version テンプレートに適用する必要があります。グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。
  • ZONE: ゾーン MIG には、ゾーンを指定します。
  • REGION: リージョン MIG には、リージョンを指定します。

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

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

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文には、現在のインスタンス テンプレートと、カナリアに追加する新しいインスタンス テンプレートの両方を含めます。次に例を示します。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/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_NAME"
  }
 ]
}

以下を置き換えます。

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

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

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

カナリア更新の実行後、すべての MIG への更新を commit するかロールバックするかを決定できます。

Console

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

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

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

gcloud

カナリア更新に commit する場合は、別の rolling-action start-update コマンドを発行して更新をロール フォワードしますが、version フラグのみを設定し、--canary-version フラグを省略します。

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

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文で、新しいインスタンス テンプレートを version として指定し、古いインスタンス テンプレートは、リクエスト本文に入れないようにします。すべてのインスタンスに更新をロールアウトするために、ターゲット サイズの指定は省略します。次に例を示します。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

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

更新のモニタリング

更新を開始した後に、影響を受けるすべてのインスタンスへのロールアウトを完了する更新に時間がかかることがあります。グループのステータスを調べるか、インスタンスでの現在のアクションを確認して、更新の進捗状況をモニタリングできます。

グループのステータス

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

Console

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

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

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

  2. モニタリングするマネージド インスタンス グループを選択します。グループの概要ページに、各インスタンスが使用するテンプレートが表示されます。
  3. 詳細を表示するには、[詳細] タブをクリックします。
  4. [インスタンス テンプレート] で、各インスタンス テンプレートの現在のインスタンス数、インスタンスのターゲット数、更新パラメータを確認できます。

gcloud

describe コマンドを使用します。

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

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

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

API

リージョンまたはゾーンの MIG リソースに対して get メソッドを呼び出します。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

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

MIG の status.versionTarget.isReached フィールドの値を確認して、更新のロールアウトが完了したかどうかを確認します。

status.versionTarget.isReachedtrue である場合、すべての VM インスタンスがターゲット バージョンを使用して作成済みまたは作成中であることを示します。

status.versionTarget.isReachedfalse である場合、少なくとも 1 つの VM が、まだターゲット バージョンを使用していないことを示します。カナリア更新の場合、false は、ターゲット バージョンを使用する VM の数がターゲット サイズと一致しないことを示します。

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

グループの status.isStable フィールドの値をチェックして、マネージド インスタンス グループ内のすべてのインスタンスが実行中で正常な状態であることを確認します。

status.isStablefalse である場合は、変更がアクティブか、保留中か、MIG 自体が変更されていることを示します。

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

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

MIG はさまざまな方法で変更可能なため、MIG の安定性はさまざまな要因で変化します。例:

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

すべてのアクションが終了すると、その MIG の status.isStabletrue に再び設定されます。

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

gcloud コマンドライン ツールまたは Compute Engine API を使用して、マネージド インスタンス グループ内のインスタンスに関する詳細を表示します。詳細には、インスタンスのステータスと、グループがインスタンスで実行中の現在のアクションが含まれます。

gcloud

すべてのマネージド インスタンス

グループ内のすべてのインスタンスのステータスと現在のアクションを確認するには、list-instances コマンドを使用します。

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

このコマンドは、ステータス、現在のアクション、その他の詳細情報を含むグループ内のインスタンスの一覧を返します。

NAME               ZONE           STATUS   HEALTH_STATE  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

ヘルスチェックを設定しない限り、HEALTH_STATE 列は空欄になります。

特定のマネージド インスタンス

グループ内の特定のインスタンスのステータスと現在のアクションを確認するには、describe-instance コマンドを使用します。

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

このコマンドは、インスタンスの詳細情報(現在のステータス、現在のアクション、ステートフル MIG の保持状態など)を返します。

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

API

リージョンまたはゾーンの MIG リソースに対して listManagedInstances メソッドを呼び出します。たとえば、ゾーン MIG リソース内のインスタンスの詳細を表示するには、次のリクエストを行います。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

この呼び出しでは、各インスタンスの instanceStatuscurrentAction を含む MIG のインスタンスのリストが返されます。

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

有効な instanceStatus フィールド値の一覧については、VM インスタンスのライフサイクルをご覧ください。

インスタンスがなんらかの種類の変更を実行している場合、マネージド インスタンス グループは、インスタンスの currentAction フィールドを次のいずれかのアクションに設定して、変更の進捗状況を追跡できるようにします。それ以外の場合、currentAction フィールドは NONE に設定されます。

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

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

更新のロールバック

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

gcloud

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

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

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

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

インスタンス数が 10 個未満のリージョン MIG の場合、maxUnavailable には固定値を使用する必要があります。この値をグループ内のインスタンス数に設定します。

Updater は、通常の更新リクエストと同じようにロールバック リクエストを処理するため、追加の更新オプションを指定できます。

更新の停止

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

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

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

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

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

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

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

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

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

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

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
        --version template=OLD_INSTANCE_TEMPLATE_NAME \
        --canary-version template=NEW_INSTANCE_TEMPLATE_NAME,target-size=2 \
        [--zone=ZONE | --region=REGION]

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

ローリング アップデートの速度の制御

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

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

これらの方法を組み合わせて使用することで、更新の速度を制御することもできます。

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

再起動ではインスタンスに対して stop メソッドと start メソッドが実行されます。置換では、インスタンスが実際に削除されて再作成されます。

ローリング再起動およびローリング置換では、インスタンス テンプレートなどグループの内容は変更されません。選択したメソッドを使用して、グループのインスタンスが更新されるだけです。

ローリング再起動またはローリング置換を実行する理由はさまざまです。たとえば、次のいずれかの理由で、VM インスタンスを随時更新する必要がある場合があります。

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

Cloud Console、gcloud コマンドライン ツール、または Compute Engine API を使用して、再起動または置換を行います。

Console

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

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

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

gcloud

restart コマンドまたは replace コマンドを使用します。

次のコマンドは、MIG 内のすべてのインスタンスを 1 つずつ置換します。

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

次のコマンドは、各インスタンスを 1 つずつ再起動します。

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

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

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

updatePolicy.minimalAction フィールドに、RESTART または REPLACE を指定します。またいずれの場合も、アクションをトリガーするために versions.instanceTemplate プロパティと versions.name プロパティを指定する必要があります。

たとえば、ゾーン MIG の場合、次のリクエストは、すべてのインスタンスを自動的に再起動するために必要な最小限の構成を示しています。

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

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

追加の置換 / 再起動の例

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

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

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

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

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

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

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

インスタンス名の保持

更新後も VM インスタンスの名前を保持する必要がある場合は、replacementMethodRECREATE に設定します。また、maxUnavailable0 より大きく、maxSurge0 に設定する必要があります。置換せずに再作成すると、更新の完了に時間がかかりますが、更新されたインスタンスの名前は保持されます。

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

gcloud

rolling-action コマンドを発行するときは、--replacement-method=recreate フラグを含めます。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

API

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文に、updatePolicy.replacementMethod フィールドを含めます。

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

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

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

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

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

リージョン MIG の更新とゾーン MIG の更新の違い

リージョン MIG のデフォルトの更新値は次のとおりです。

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES は、リージョン MIG に関連付けられているゾーンの数です。デフォルトでは、リージョン MIG のゾーン数は 3 です。異なる番号を選択することもできます。

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

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

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

割合を指定できるのは、MIG に 10 個以上の VM インスタンスが含まれる場合に限られます。割合の扱い方は、場合によってやや異なります。

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

  • maxSurgemaxUnavailable などの更新オプションで割合を指定すると、その割合はゾーンごとに独立して四捨五入され丸められます。

次のステップ