MIG での OS イメージのワンクリック アップグレードの実施

---

カスタム イメージ ファミリーとローリング アップデートを組み合わせて使用すると、マネージド インスタンス グループ（MIG）で OS イメージのワンクリック アップグレードを有効にできます。

OS イメージのワンクリック アップグレードを使用すると、次のような数多くの利点があります。

• すべての VM マシンタイプとすべてのインスタンス グループサイズに対応します。
• Windows と Linux 両方のイメージとコンテナをサポートします。
• 現在のインスタンス テンプレート（または、必要に応じて新しいインスタンス テンプレート）に基づいてインスタンスが再作成されるため、カスタム起動スクリプトとメタデータをそのまま維持できます。
• ステートフル MIG と連動するため、必要に応じて非ブートディスクのデータを維持できます。
• 新しい OS バージョンへの更新のロールアウトは自動的に行われます。したがって、最初のリクエストの後にユーザーの入力は必要ありません。
• バッチ更新をサポートします。必要に応じて、バッチ更新でヘルスチェックを行うこともできます。

始める前に

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

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

     gcloud init

     Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
  2. デフォルトのリージョンとゾーンを設定します。

OS イメージのワンクリック アップグレードの仕組み

更新プロセスを起動すると、MIG により、グループ内のすべての VM のブートディスクが、カスタム イメージ ファミリーに含まれる最新の利用可能な OS イメージ バージョンに置き換えられます。MIG はグループ内の各 VM について、インスタンス テンプレートで設定されているメタデータと起動スクリプトを維持します。非ブートディスクは、インスタンス テンプレートでの仕様に基づいて再作成されます。データを維持する方法については、MIG でのステートフル ディスクの構成をご覧ください。

アプリケーションの中断を抑えるために、バッチ更新を行って、更新プロセス中に特定の割合の VM を稼働させ続けることもできます。信頼性を高めるには、MIG を対象としたアプリケーション ベースのヘルスチェックを構成します。この場合、MIG は、更新された VM 上のアプリケーションから正常なレスポンスが返されるのを待ってから、他の VM の更新を続行します。

注: Container-Optimized OS では、ワンクリックによる自動更新もサポートされます。

始める前に

• Google Cloud CLI の最新バージョンをインストールするか、最新バージョンに更新します。

• イメージ ファミリーを指すインスタンス テンプレートを作成済みであることを確認します。アプリケーションとの互換性がないイメージ バージョンをロールアウトするリスクを軽減するために、カスタム イメージ ファミリーを使用することをおすすめします。互換性があるイメージ バージョンだけがロールアウトされるようにするため、アプリケーションでの互換性テストを行ってからでなければカスタム イメージ ファミリーにイメージを追加しないようにします。

  インスタンス テンプレートがイメージ ファミリーを指している場合、MIG は常にそのイメージ ファミリーに含まれる最新のイメージを基にインスタンスを作成します。MIG は、たとえば次の場合にインスタンスを作成します。

  • ユーザーまたは MIG のオートスケーラーが MIG のサイズを増やしたため、MIG が新しいインスタンスを追加する場合。
  • MIG が手動で、または自動修復によってインスタンスを再作成する場合。
  注: MIG に、イメージ ファミリーの最新イメージ以外のイメージを使用してインスタンスを作成させる必要がある場合は、その特定のイメージを指すインスタンス テンプレートを作成します。その特定のイメージの新しいバージョンを使用するには、その新しいイメージを指定した新しいインスタンス テンプレートを作成し、新しく作成したテンプレートで MIG を更新するために、ローリング アップデートを使用します。

• 新しいイメージをアプリでテストしてから、イメージ ファミリーに追加してロールアウトします。

• 必要に応じて、MIG を対象としたアプリケーション ベースのヘルスチェックを作成します。アプリケーション ベースのヘルスチェックでは、MIG に含まれる各 VM 上のアプリケーションが正常に応答していることを確認します。これにより、更新プロセス中に使用できない状態の VM が 1 つだけになるように構成できます。アプリケーションが正常に応答しなければ、MIG はそのアプリケーションを実行している VM を使用不可としてマークし、ロールアウトは続行されません。

MIG での OS イメージのワンクリック アップグレードの実施

MIG 内のすべての VM をカスタム イメージ ファミリーの最新イメージに更新するには、次の手順を行います。

1. 次のコマンドを使用してローリング置換を開始します。

   gcloud compute instance-groups managed rolling-action replace instance-group-name \
       [--max-surge=max-surge ] [--max-unavailable=max-unavailable]

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

   • instance-group-name: 操作対象の MIG の名前。
   • max-surge: 更新プロセス中に一時的に作成できる、追加 VM の最大数。これは、固定数（例: 5）にすることも、MIG のサイズのパーセンテージ（例: 10%）にすることもできます。
   • max-unavailable: 更新プロセス中に許容される、使用できない状態の VM の最大数。これは、固定数（例: 5）にすることも、MIG のサイズのパーセンテージ（例: 10%）にすることもできます。

   --max-unavailable および --max-surge オプションをヘルスチェックと組み合わせると、更新プロセスで VM が使用できなくなった場合に更新を停止できます。

2. wait-until サブコマンドを使用して更新状況をモニタリングし、MIG の status.versionTarget.isReached フィールドが true に設定されていることを確認します。

   gcloud compute instance-groups managed wait-until instance-group-name --version-target-reached

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

   • instance-group-name: 操作対象の MIG の名前。

   このコマンドは、グループが更新されると戻ります。

   インスタンスを一覧表示して、各インスタンスのステータスを確認することもできます。

   gcloud compute instance-groups managed list-instances instance-group-name

   このコマンドは、インスタンスとそれぞれのインスタンスの詳細（各 VM のステータス、ヘルス状態、現在のアクションなど）からなるリストを返します。すべての VM が RUNNING ステータスになり、現在のアクションがなくなった時点で、MIG は最新で安定した状態になります。

3. 以前の OS イメージにロールバックしなければならない場合は、インスタンス テンプレートを作成して、使用するイメージを指定する必要があります。次に、ローリング アップデートを開始して、そのテンプレートを使用するようにすべてのマネージド インスタンスを更新します。詳細については、更新のロールバックをご覧ください。

例

この例は、次のタスクを行う方法を説明しています。

1. OS イメージを簡単に更新するためのインスタンス テンプレートを作成します。
   • インスタンス テンプレートでカスタム イメージ ファミリーを指定します。
2. テンプレートに基づく MIG を作成します。
3. ヘルスチェックを設定して、イメージの更新プロセスによる中断を抑えます。
4. イメージ ファミリーに新しいイメージを追加します。
5. 1 つのコマンドで OS 更新プロセスを起動します。
6. 更新状況をモニタリングします。

MIG で OS のワンクリック アップグレードを有効にして実施するには、次の手順に従います。

1. カスタム イメージ ファミリーを指定するインスタンス テンプレートを作成します。イメージ ファミリーには、テスト済みの信頼できるイメージを含めてください。MIG がテンプレートを基に作成する各 VM には、このファミリーに含まれる最新の利用可能なイメージが使用されます。

   gcloud compute instance-templates create example-template \
       --machine-type n1-standard-4 \
       --image-family my-image-family \
       --image-project my-project \
       --tags=http-server
   

   注: MIG に、イメージ ファミリーの最新イメージ以外のイメージを使用してインスタンスを作成させる必要がある場合は、その特定のイメージを指すインスタンス テンプレートを作成します。その特定のイメージの新しいバージョンを使用するには、その新しいイメージを指定した新しいインスタンス テンプレートを作成し、新しく作成したテンプレートで MIG を更新するために、ローリング アップデートを使用します。

   • ローリング アップデートでは、MIG 用に設定したインスタンス テンプレートの最新バージョンに基づいて VM が更新されます。
   • ローリング置換では、VM が置換され、マネージド インスタンスの現在のインスタンス テンプレートが再利用されます。

2. インスタンス テンプレートに基づく MIG を作成します。この例では、example-template に基づく 3 つのインスタンスで MIG を開始します。インスタンス テンプレートではイメージ ファミリーを指定しているため、ファミリーに含まれる最新のイメージを使用して各 VM が作成されます。

   gcloud compute instance-groups managed create example-group \
     --base-instance-name example \
     --size 3 \
     --zone us-east1-b \
     --template example-template
   

3. 省略可: アプリケーション ベースのヘルスチェックを構成して有効にします。ヘルスチェックのステータスと maxUnavailable 設定を組み合わせて使用すると、イメージの更新後にアプリが応答しない場合に MIG がロールアウトを続行しないようにできます。

   1. リクエストパス/health で HTTP 200 レスポンスを確認するヘルスチェックを作成します。各インスタンス上の GitHub アプリは、このパスに対応します。

      gcloud compute health-checks create http example-autohealer-check \
          --check-interval 10 \
          --timeout 5 \
          --healthy-threshold 2 \
          --unhealthy-threshold 3 \
          --request-path "/health"
      

   2. ヘルス チェッカー プローブに対してインスタンスへのアクセスを許可するファイアウォール ルールを作成します。ヘルス チェッカー プローブは、130.211.0.0/22 から 35.191.0.0/16 までの範囲のアドレスから送信されます。

      gcloud compute firewall-rules create default-allow-http-health-check \
          --network default \
          --allow tcp:80 \
          --source-ranges 130.211.0.0/22,35.191.0.0/16
      

   3. MIG にヘルスチェックを追加します。

      gcloud compute instance-groups managed update example-group \
          --zone us-east1-b --health-check example-autohealer-check
      

4. 更新が利用可能になってテストされ、アプリと互換性があると判断されたら、新しいイメージを作成し、--family フラグを使用してそのイメージをカスタム イメージ ファミリーに含めます。

   gcloud compute images my-image-v2 \
       --source-disk boot-disk-1 \
       --source-disk-zone us-central1-f \
       --family my-image-family

   この例で my-image-family の最新イメージに該当するのは、ソースディスク boot-disk-1 に基づく my-image-v2 です。

5. MIG 内のすべての VM を置き換えるために、ローリング置換を起動します。MIG は、グループのインスタンス テンプレートに基づいて各 VM を置き換えます。インスタンス テンプレートでは my-image-family を指定しているため、各 VM には、このファミリーの最新イメージ（my-image-v2）が使用されます。

   更新プロセスによって生じる中断レベルを構成できます。この例では、MIG がグループのターゲット サイズを超える追加の VM を 1 つ作成します。この VM が稼働中になるまでは、MIG は既存の VM を削除しません。

   gcloud compute instance-groups managed rolling-action replace example-group \
       --max-surge 1 --max-unavailable 0
   

6. 更新のステータスをモニタリングするには、--version-target-reached フラグを指定した wait-until コマンドを使用します。このコマンドは、グループが更新されると戻ります。

   gcloud compute instance-groups managed wait-until --version-target-reached example-group \
       --zone us-east1-
   Waiting for group to reach version target
   ...
   Version target is reached
   

   list-instances コマンドを使用して、各 VM のステータス、健全性、現在のアクション、インスタンス テンプレート、バージョンを確認することもできます。

   gcloud compute instance-groups managed list-instances example-group \
       --zone us-east1-b
   
   
   NAME       ZONE        STATUS   HEALTH_STATE  ACTION     INSTANCE_TEMPLATE  VERSION_NAME                        LAST_ERROR
   test-211p  us-east1-b  RUNNING  HEALTHY       NONE       example-template   0/2020-01-30 13:34:28.843377+00:00
   test-t5qb  us-east1-b  RUNNING  UNKNOWN       VERIFYING  example-template   0/2020-01-30 13:34:28.843377+00:00
   test-x331  us-east1-b  RUNNING  HEALTHY       NONE       example-template   0/2020-01-20 20:39:51.819399+00:00
   

7. 前のイメージにロールバックする必要がある場合は、次の手順で操作します。

   1. 目的のイメージを指定する新しいインスタンス テンプレートを作成します。
   2. ローリング アップデートを開始して、新しく作成したインスタンス テンプレートを適用します。

次のステップ

• イメージ ファミリーに関するベスト プラクティスの詳細を確認する。
• インスタンス グループの詳細を確認する。
• インスタンス テンプレートの詳細を確認する。
• MIG でのローリング アップデートの詳細を確認する。