新しい構成を MIG 内の VM に適用する

このドキュメントは、マネージド インスタンス グループ（MIG）の仮想マシン（VM）インスタンスに、更新されたインスタンス テンプレートとインスタンスごとの構成を適用する方法を決めるのに役立ちます。

次の場合には、新しいインスタンス テンプレートを適用することがあります。

  • 各インスタンスでアプリケーションやオペレーティング システムを更新する場合
  • A/B テストを実施して、同じアプリの異なるバージョンを比較する場合。
  • 新しいバージョンをテストする際の中断を最小限に抑えるためにカナリア更新を実行する場合。
  • マシンタイプやディスク オプションなど、MIG のインスタンスの他の仕様を変更する場合。

ステートフル MIG を使用する場合、更新されたインスタンスごとの構成を適用することもできます。

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

  • 自動ローリング アップデート。MIG が、インスタンス テンプレートの新しいバージョンを MIG のマネージド インスタンスのすべてまたは一部に自動的にロールアウトします。MIG では、適用されないステートフルなインスタンスごとの構成も対応するインスタンスに適用されます。インスタンスの実行を中断するレベルは、構成した更新ポリシーによって異なります。

  • 特定インスタンスの選択更新。選択した特定のインスタンスを対象にして更新できます。更新を手動でオーケストレートする場合は、このメソッドを使用します。

MIG のサイズ変更のみが必要な場合は、ドキュメントで インスタンスをMIGでVMを追加または削除する方法をご確認ください。

MIG 機能を使用または更新する場合は、自動修復、負荷分散、自動スケーリング、自動更新、ステートフル ワークロードのドキュメントをご覧ください。

制限事項

  • ステートフル MIG があり、自動ローリング アップデートを使用する場合は、置換メソッドを RECREATE に設定する必要があります。

自動更新か選択更新かの選択

新しい構成を MIG のインスタンスのすべてまたはサブセットに自動的にロールアウトするには、MIG の更新タイプを PROACTIVE に設定します。自動更新が大がかりになる可能性がある場合や、更新をより詳細に制御する場合は、MIG の更新タイプを OPPORTUNISTIC に設定してから、特定のインスタンスを選択して更新します。

自動先行型更新

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

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

先行型ローリング アップデートが開始すると、MIG は積極的にアクションをスケジュールし、必要に応じてリクエストされた更新をインスタンスに適用します。多くの場合、これはインスタンスを先に削除して再作成することを意味します。

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

選択更新

特定のインスタンスを選択して更新することには、次のメリットがあります。

  • 更新するインスタンスを選択できます。
  • 更新のタイミングと順序を制御できます。
  • API を使用すると、すべてのインスタンスをすぐに更新できます。

先行型更新で、選択的な更新と競合しないようにするには、MIG の更新タイプを OPPORTUNISTIC に設定します。

追従型更新

更新タイプが OPPORTUNISTIC に設定されている場合、MIG は、特定のインスタンスを選択して更新が適用されたとき、または MIG が新しいインスタンスを作成した場合にのみ更新を適用します。MIG が新しいインスタンスを作成するのは、自動または手動でインスタンスのサイズが変更された場合です。更新を適用するためのリクエストが Compute Engine から積極的に開始されることはありません。

システムの不安定さはできる限り避けたいものであるため、日和見更新は特定のシナリオにおいて有用です。たとえば、緊急性がなく必要に応じて適用可能な更新があり、アクティブに自動スケーリングされている MIG がある場合は、Compute Engine で更新を適用する既存のインスタンスを積極的に破棄しないように、追従型更新を行います。サイズを縮小する場合、オートスケーラーは古いテンプレートで作成されたインスタンスと、まだ RUNNING 状態でないインスタンスを優先的に解除します。

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

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

デフォルトでは、Cloud コンソールや Google Cloud CLI を使用して開始された更新は先行型になります。つまり、構成の更新はグループ内の VM に自動的に適用されます。Compute Engine API を使用して開始される更新は追従型です。つまり、MIG は新しいテンプレートやインスタンスごとの構成を既存のインスタンスに能動的には適用しません。

追従型更新か先行型更新かを選択するには、Cloud コンソール、Google Cloud CLI、または Compute Engine API でモードを追従型か先行型に設定します。

Console

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

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

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

  3. ページの上部にある [Update VMs] をクリックします。

  4. グループの別のテンプレートを設定するには、[新しいテンプレート] で、使用するインスタンス テンプレートを選択します。

  5. [構成の更新] で、自動更新または部分更新を選択します。

gcloud

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

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

API

ゾーンまたはリージョンの 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",
    }]
}

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

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

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

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

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

以前の instanceTemplate フィールドは、機能的に versions フィールドと重複しています。どちらのフィールドでも、MIG がインスタンスの作成に使用するインスタンス テンプレートを指定できます。ただし、高度な 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 がインスタンスの作成に使用するテンプレートを変更できます。このメソッドを呼び出すと、versions フィールドは setInstanceTemplate() メソッドに指定されたインスタンス テンプレートでオーバーライドされます。

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

次のステップ