このページでは、マネージド インスタンス グループ(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
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
- 自動(先行型): MIG でグループ内のすべての既存の VM またはそのサブセットに新しい構成を自動的に適用する場合は、この方法を使用します。VM の実行を中断するレベルは、構成した更新ポリシーによって異なります。この方法を使用すると、新しいインスタンス テンプレートをカナリア更新できます。この方法を使用するには、MIG の更新タイプを「先行型」に設定します。
- 選択型(追従型): 更新を手動で適用する場合、またはグループ内の既存のすべての VM を一度に更新する場合は、この方法を使用します。一部またはすべての VM を最新の構成に更新します。この方法を使用するには、MIG の更新タイプを「追従型」に設定します。
- VM の再作成: 特定の VM を再作成して、新しい構成を適用します。
- 更新のロールアウトは指定に従って自動的に実行されます。最初のリクエストの後にユーザーが新たに入力する必要はありません。デプロイの速度、サービス中断のレベル、更新範囲を指定できます。
- 部分的なロールアウトを自動化して、カナリアテストを行うことができます。
- 更新するインスタンスを選択できます。
- 更新のタイミングと順序を制御できます。
- gcloud CLI または REST を使用して、すべてのインスタンスを直ちに更新できます。
MIG 内の VM の 1 つが停止し、修復が必要だが、構成を変更したくない。MIG の更新タイプを追従型に設定し、修復中の更新を強制的に適用しない場合、Compute Engine は元のインスタンス テンプレートが存在しない場合でも、その VM の作成に使用されたのと同じ構成を使用して VM を修復します。
自動スケーリングされる MIG があり、緊急ではなく重要性の低い更新を適用したい。Compute Engine が既存の VM を破棄して更新を適用しないようにするには、MIG の更新タイプを追従型に設定します。スケールインする場合は、オートスケーラーは古い構成の VM を優先的に停止します。グループをスケールアウトする場合は、最新の構成で VM が作成されます。
Google Cloud Console で、[インスタンス グループ] ページに移動します。
更新する MIG を選択します。
ページの上部にある [Update VMs] をクリックします。
グループの別のテンプレートを設定するには、[新しいテンプレート] で、使用するインスタンス テンプレートを選択します。
[構成の更新] で、自動更新または部分更新を選択します。
INSTANCE_GROUP_NAME
: グループの名前NEW_TEMPLATE
: グループの新しいテンプレートの名前TYPE
: 更新のタイプ(opportunistic
またはproactive
)PROJECT_ID
: MIG が存在するプロジェクト。REGION
: MIG が配置されているリージョン。ゾーン MIG の場合は、regions/REGION
をzones/ZONE
に置き換えます。INSTANCE_GROUP_NAME
: グループの名前。NEW_TEMPLATE
: グループの新しいテンプレートの名前。TYPE
: 更新のタイプ(OPPORTUNISTIC
またはPROACTIVE
)。- 実行中、一時停止、停止した VM
- ステータスが
SUSPENDING
またはSTOPPING
の VM - 一時停止または停止された VM を削除します。
- 新しいインスタンス テンプレートを使用して新しい VM を作成します。
- 初期化プロセスを実行します。
- VM を一時停止または停止します。
- VM を再開または起動します。
- 実行中の VM で更新を実行します。
- 初期化プロセスを実行します。
- VM を一時停止または停止します。
manual
スタンバイ ポリシーモードでは、MIG は更新を適用する VM の数または割合に基づいて、実行中の VM のみを更新します。一時停止または停止された VM は以前のバージョンのままとなります。scale-out-pool
スタンバイ ポリシーモードでは、MIG でカナリア更新を開始することはできません。両方のフィールドを同じ値に設定する。
これは有効なリクエストです。この場合、あいまいさがなくなり、新しいインスタンス テンプレートが 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" } }
- 新しいインスタンス テンプレートを MIG に自動的にロールアウトする方法を確認する。
- MIG で VM を選択的に更新する方法について確認する。
- MIG とその VM に関する情報を表示する。
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 に必須のインスタンス プロパティとオプションのインスタンス プロパティを定義します。
省略可: セカンダリ VM 構成のカナリアテストを行う場合、セカンダリ インスタンスのテンプレートをグループに追加して、グループ内の VM のサブセットに適用できます。全インスタンスの構成 ラベルとメタデータ 省略可: 全のインスタンス構成を使用すると、グループ内のすべての VM のインスタンス テンプレート プロパティをすばやくオーバーライドできます。 ステートフル構成 ステートフル ディスク、IP アドレス、メタデータ 省略可: ステートフル ワークロードをサポートする必要がある場合は、グループ内の VM にステートフル構成を追加します。 これらのコンポーネントを使用してグループの構成を更新する場合、更新された構成を有効にするには、更新された構成をグループ内の既存の VM に適用する必要があります。
既存の VM に新しい構成を適用する方法
MIG の VM 構成を更新したら、次の方法を使って、グループ内の既存の VM に新しい構成を適用できます。
MIG の更新タイプの設定の詳細については、先行型または追従型の更新を設定するをご覧ください。
自動(先行型)
自動更新タイプは、先行型更新タイプとも呼ばれます。MIG の更新タイプを先行型に設定すると、MIG は必要に応じて更新された構成を VM に自動的に適用します。
MIG の更新タイプを先行型に設定すると、次に示す 2 つの主なメリットがあります。
MIG の更新タイプの設定方法については、先行型または追従型の更新を設定するをご覧ください。
自動ロールアウトの詳細については、MIG で VM 構成の更新を自動的に適用するをご覧ください。
選択型(追従型)
選択型更新タイプは、追従型更新タイプとも呼ばれます。MIG の更新タイプを追従型に設定すると、更新する特定の VM を選択的にターゲットにした場合にのみ、MIG は既存の VM に新しい構成を適用します。
MIG の更新タイプを追従型に設定すると、次のようなメリットがあります。
システムの不安定さはできる限り避けたいものであるため、シナリオによっては、選択的更新タイプが有用です。たとえば、次の場合を考えます。
MIG の更新タイプの設定方法については、先行型または追従型の更新を設定するをご覧ください。
VM を選択的に更新する方法の詳細については、MIG で VM 構成の更新を選択的に適用するをご覧ください。
VM の再作成
MIG 内の任意の VM を再作成できます。これを行うと、MIG は、その VM にまだ適用されていない更新済みの構成を適用します。詳細については、MIG 内の VM の再作成をご覧ください。
先行型または追従型の更新を設定する
新しい構成を既存の VM に自動的に適用するには、MIG の更新タイプを「先行型」に設定します。VM を更新すると選択した場合にのみ新しい構成を既存の VM に適用するには、MIG の更新タイプを「追従型」に設定します。
Google Cloud コンソール、Google Cloud CLI、または REST を使用します。
コンソール
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
次のように置き換えます。
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", }] }
次のように置き換えます。
新しいテンプレートを設定し、そのテンプレートを 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 を更新します。
自動更新の場合、MIG は実行中の VM のターゲット数のみに基づいて最大サージとオフライン上限を計算しますが、スタンバイ プールの VM は考慮されません。
自動更新でグループ内の VM を置き換える必要がある場合、MIG は次の処理を行います。
自動更新でグループ内の VM の更新または再起動のみが必要な場合、MIG は次の処理を行います。
カナリア更新
VM を一時停止または停止した 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 つの可能性が考えられます。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
フィールドで明示的に指定されていないインスタンス テンプレートを能動的に展開しなくなります。次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-11-21 UTC。
-