MIG で新しい VM 構成を適用する

このページでは、マネージド インスタンス グループ（MIG）で仮想マシン（VM）インスタンスを構成する方法と、グループ内の既存の VM への構成の適用に使用できる方法について説明します。

MIG 内の VM に目的の構成を指定するために、次の VM 構成コンポーネントを使用します。

• 必須: インスタンス テンプレート
• 省略可: 全インスタンスの構成
• 省略可: ステートフル構成

これらのコンポーネントを使用して目的の構成を更新するたびに、Compute Engine は更新された構成を、グループに追加された新しい VM に自動的に適用します。

更新された構成を既存の VM に適用するには、このページで説明する方法を使用します。

• 停止制限と新しいテンプレートのオプションのカナリア更新による自動ロールアウト
• 特定の VM のみを選択して手動で更新し、中断を最小限に抑える
• 特定の VM の再作成

また、VM の修復中に最新の利用可能な構成を VM に適用するように MIG を構成することもできます。詳細については、修復中に構成の更新を適用するをご覧ください。

MIG のサイズ変更のみが必要な場合は、ドキュメントで インスタンスをMIGでVMを追加または削除する方法をご確認ください。 MIG 機能の構成の詳細については、自動スケーリング、自動修復、ロード バランシングおよびステートフル ワークロードのドキュメントをご覧ください。

始める前に

• まだ設定していない場合は、認証を設定します。認証とは、Google Cloud のサービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

  2. Set a default region and zone.

  REST

  このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

MIG 内の VM の構成コンポーネント

MIG 内の VM は、次のコンポーネントで構成します。

これらのコンポーネントを使用してグループの構成を更新する場合、更新された構成を有効にするには、更新された構成をグループ内の既存の VM に適用する必要があります。

既存の VM に新しい構成を適用する方法

MIG の VM 構成を更新したら、次の方法を使って、グループ内の既存の VM に新しい構成を適用できます。

• 自動（先行型）: MIG でグループ内の既存の VM のすべてまたはサブセットに新しい構成を自動的に適用する場合は、この方法を使用します。VM の実行を中断するレベルは、構成した更新ポリシーによって異なります。この方法を使用すると、新しいインスタンス テンプレートをカナリア更新できます。この方法を使用するには、MIG の更新タイプを「先行型」に設定します。
• 選択型（追従型）: 更新を手動で適用する場合、またはグループ内の既存のすべての VM を一度に更新する場合は、この方法を使用します。一部またはすべての VM を最新の構成に更新します。この方法を使用するには、MIG の更新タイプを「追従型」に設定します。
• VM の再作成: 特定の VM を再作成して、新しい構成を適用します。

MIG の更新タイプの設定の詳細については、先行型または追従型の更新を設定するをご覧ください。

自動（先行型）

自動更新タイプは、先行型更新タイプとも呼ばれます。MIG の更新タイプを先行型に設定すると、MIG は必要に応じて更新された構成を VM に自動的に適用します。

MIG の更新タイプを先行型に設定すると、次に示す 2 つの主なメリットがあります。

• 更新のロールアウトは指定に従って自動的に実行されます。最初のリクエストの後にユーザーが新たに入力する必要はありません。デプロイの速度、サービス中断のレベル、更新範囲を指定できます。
• 部分的なロールアウトを自動化して、カナリアテストを行うことができます。

MIG の更新タイプの設定方法については、先行型または追従型の更新を設定するをご覧ください。

自動ロールアウトの詳細については、MIG で VM 構成の更新を自動的に適用するをご覧ください。

選択型（追従型）

選択型更新タイプは、追従型更新タイプとも呼ばれます。MIG の更新タイプを追従型に設定すると、更新する特定の VM を選択的にターゲットにした場合にのみ、MIG は既存の VM に新しい構成を適用します。

MIG の更新タイプを追従型に設定すると、次のようなメリットがあります。

• 更新する VM を選択できます。
• 更新のタイミングと順序を制御できます。
• gcloud CLI または REST を使用して、すべてのインスタンスを直ちに更新できます。

システムの不安定さはできる限り避けたいものであるため、シナリオによっては、選択的更新タイプが有用です。たとえば、次の点を考えます。

• MIG 内の VM の 1 つが停止し、修復が必要だが、構成を変更したくない。MIG の更新タイプを追従型に設定し、修復中の更新を強制的に適用しない場合、Compute Engine は元のインスタンス テンプレートが存在しない場合でも、VM の作成に使用されます。

• 自動スケーリングされる MIG があり、緊急ではなく重要性の低い更新を適用したい。Compute Engine が既存の VM を破棄して更新を適用しないようにするには、MIG の更新タイプを追従型に設定します。スケールインすると、オートスケーラーは古い構成の VM を優先します。グループをスケールアウトする場合は、最新の構成で VM が作成されます。

MIG の更新タイプの設定方法については、先行型または追従型の更新を設定するをご覧ください。

VM を選択的に更新する方法の詳細については、MIG で VM 構成の更新を選択的に適用するをご覧ください。

VM の再作成

MIG 内の任意の VM を再作成できます。これを行うと、MIG は、その VM にまだ適用されていない更新済みの構成を適用します。詳細については、MIG 内の VM の再作成をご覧ください。

先行型または追従型の更新を設定する

新しい構成を既存の VM に自動的に適用するには、MIG の更新タイプを「先行型」に設定します。VM を更新すると選択した場合にのみ新しい構成を既存の VM に適用するには、MIG の更新タイプを「追従型」に設定します。

Google Cloud コンソール、Google Cloud CLI、または REST を使用します。

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --type=TYPE

gcloud beta compute instance-groups managed update INSTANCE_GROUP_NAME \
    --update-policy-type=TYPE

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

{
  "updatePolicy": {
    "type": "TYPE" # Choose an opportunistic or proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
    }]
}

新しいテンプレートを設定してから、そのテンプレートを MIG の新しい VM と既存のインスタンスに適用する方法については、次のページをご覧ください。

• MIG で VM 構成の更新を自動的に適用する
• MIG で VM 構成の更新を選択的に適用する

グループの更新ポリシーのタイプを確認する

gcloud CLI または REST を使用して、MIG に現在構成されている更新ポリシータイプ（「追従型」または「先行型」）とその他の更新ポリシーの設定を表示できます。

gcloud beta compute instance-groups managed describe INSTANCE_GROUP_NAME \
    --format="(updatePolicy)"

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

ポリシータイプを変更するには、先行型または追従型の更新を設定するをご覧ください。

一時停止または停止された VM の更新

MIG で VM のプールを一時停止または停止している場合は、実行中の他の VM を更新するように、一時停止または停止した VM を選択的に（追従型で）更新できます。自動（先行型）更新を構成すると、MIG は次の順序で VM を更新します。

1. 実行中、一時停止、停止した VM
2. ステータスが SUSPENDING または STOPPING の VM

自動更新の場合、MIG は実行中の VM のターゲット数のみに基づいて最大サージとオフライン上限を計算しますが、スタンバイ プールの VM は考慮されません。

自動更新でグループ内の VM を置き換える必要がある場合、MIG は次の処理を行います。

1. 一時停止または停止された VM を削除します。
2. 新しいインスタンス テンプレートを使用して新しい VM を作成します。
3. 初期化プロセスを実行します。
4. VM を一時停止または停止します。

自動更新でグループ内の VM の更新または再起動のみが必要な場合、MIG は次の処理を行います。

1. VM を再開または起動します。
2. 実行中の VM で更新を実行します。
3. 初期化プロセスを実行します。
4. VM を一時停止または停止します。

カナリア更新

VM を一時停止または停止した MIG でカナリア更新を開始する場合、以下が適用されます。

• manual スタンバイ ポリシーモードでは、MIG は更新を適用する VM の数または割合に基づいて、実行中の VM のみを更新します。一時停止または停止された VM は以前のバージョンのままとなります。
• scale-out-pool スタンバイ ポリシーモードでは、MIG でカナリア更新を開始することはできません。

versions フィールドと instanceTemplate フィールドの関係

REST を使用する場合は、instanceGroupManagers.versions フィールドと regionInstanceGroupManagers.versions フィールドを使用して、ゾーン MIG とリージョン MIG のインスタンス テンプレートを構成することをおすすめします。

以前の instanceTemplate フィールドは、機能的に versions フィールドと重複しており、どちらのフィールドでも、MIG が VM の作成に使用するインスタンス テンプレートを指定できます。ただし、高度な 2 つのテンプレート（カナリア）構成を指定できるのは、versions フィールドのみです。

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

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

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

  これは有効なリクエストです。この場合、あいまいさがなくなり、新しいインスタンス テンプレートが MIG に適用されます。

  たとえば、次のリクエストでは、最上位の instanceTemplate および versions フィールドに既存のテンプレートと異なるインスタンス テンプレートを指定すると、MIG は新しいインスタンス テンプレートに更新されます。

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

• 両方のフィールドの設定値が一致せず、片方が MIG 内の現在のインスタンス テンプレートと異なる。

  これは有効なリクエストです。現在の設定と異なるフィールドが、目的の値として取得されます。たとえば、update() メソッドを呼び出し、両方のフィールドを指定しますが、1 つのフィールドのみが最新の場合です。

  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_TEMPLATE",
   "versions": [
    {
     "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    }
   ],
   "updatePolicy": {
     "type": "PROACTIVE"
   }
  }
  

• 両方のフィールドの設定値が一致せず、どちらも MIG 内の現在のインスタンス テンプレートと異なる。

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

  {
   "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() メソッドはこれまでと同じように動作し、MIG が VM の作成に使用するテンプレートを変更できます。このメソッドを呼び出すと、versions フィールドは setInstanceTemplate() メソッドに指定されたインスタンス テンプレートでオーバーライドされます。

また、setInstanceTemplate() メソッドは updatePolicy を OPPORTUNISTIC に設定します。これにより、MIG は、versions フィールドで明示的に指定されていないインスタンス テンプレートを能動的に展開しなくなります。

次のステップ

• 新しいインスタンス テンプレートを MIG に自動的にロールアウトする方法を確認する。
• MIG で VM を選択して更新する方法について詳細を確認する。
• MIG とその VM に関する情報を表示する。