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 に対する認証を行います。

このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール

Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
1. Google Cloud CLI をインストールし、次のコマンドを実行して初期化します。
```
gcloud init
```
  注: すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して、最新バージョンがインストールされていることを確認してください。
2. デフォルトのリージョンとゾーンを設定します。
REST

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

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

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

コンポーネント	プロパティ	ユースケース
インスタンステンプレート	マシンタイプ、ブートディスクイメージ、ラベル、起動スクリプト、その他の VM プロパティ	必須: インスタンステンプレートを使用して、グループ内のすべての VM に必須のインスタンスプロパティとオプションのインスタンスプロパティを定義します。省略可: セカンダリ VM 構成のカナリアテストを行う場合、セカンダリインスタンスのテンプレートをグループに追加して、グループ内の VM のサブセットに適用できます。
全インスタンスの構成	ラベルとメタデータ	省略可: 全のインスタンス構成を使用すると、グループ内のすべての VM のインスタンステンプレートプロパティをすばやくオーバーライドできます。
ステートフル構成	ステートフルディスク、IP アドレス、メタデータ	省略可: ステートフルワークロードをサポートする必要がある場合は、グループ内の 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 の更新タイプを追従型に設定すると、次のようなメリットがあります。

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

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

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

このタスクに必要な権限

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

ゾーン MIG の場合、instanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限
リージョン MIG の場合、regionInstanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限

コンソール

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

[インスタンスグループ] ページに移動
更新する MIG を選択します。
ページの上部にある [Update VMs] をクリックします。
グループの別のテンプレートを設定するには、[新しいテンプレート] で、使用するインスタンステンプレートを選択します。
[構成の更新] で、自動更新または部分更新を選択します。

gcloud

rolling-action start-update コマンドを使用し、--type フラグを opportunistic または proactive に設定します。

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

ベータ版の update コマンドを使用し、--update-policy-type フラグを指定することもできます。

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

次のように置き換えます。

INSTANCE_GROUP_NAME: グループの名前
NEW_TEMPLATE: グループの新しいテンプレートの名前
TYPE: 更新のタイプ（opportunistic または proactive）

REST

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

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",
    }]
}

次のように置き換えます。

PROJECT_ID: MIG が存在するプロジェクト。
REGION: MIG が配置されているリージョン。ゾーン MIG の場合は、regions/REGION を zones/ZONE に置き換えます。
INSTANCE_GROUP_NAME: グループの名前。
NEW_TEMPLATE: グループの新しいテンプレートの名前。
TYPE: 更新のタイプ（OPPORTUNISTIC または PROACTIVE）。

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

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

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

gcloud

describe コマンドを使用し、--format フラグを指定すると、updatePolicy の設定のみが一覧表示されます。

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

REST

ゾーンまたはリージョンの MIG で GET リクエストを行い、updatePolicy フィールドを確認します。

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

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

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

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

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

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

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

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

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

VM を再開または起動します。
実行中の VM で更新を実行します。
初期化プロセスを実行します。
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 に関する情報を表示する。

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

始める前に

コンソール

gcloud

REST

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

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

自動（先行型）

選択型（追従型）

VM の再作成

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

このタスクに必要な権限

コンソール

gcloud

REST

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

gcloud

REST

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

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

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

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

次のステップ

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

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

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