VM Manager の基礎: VM へのパッチ適用前にディスクのクローンを作成
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
今年の初め、Google は Google Cloud で動作する大規模な仮想マシンの管理に使用できるツール群、VM Manager を本格導入しました。
VM Manager で使用可能なサービスの一つに、オンデマンドで、スケジュールに従って仮想マシンにパッチを適用できるよう支援する OS Patch Management が挙げられます。OS Patch Management は、Linux と Windows のいずれのオペレーティング システムでも動作し、オペレーティング システムの各更新インフラストラクチャ（apt、ZYpp、yum、Windows Update エージェントなど）を使用して、パッチの特定および不足パッチの適用の両方を行います。
このサービスを使用する予定のお客様またはすでにご利用中のお客様とのお話しの中で、パッチ適用またはパッチ自体に問題がある場合に前の状態に戻せるよう、パッチ適用前に仮想マシンの状態のバックアップを取る機能を備えてほしいとよくリクエストされます。残念ながら、この機能は、VM Manager ではデフォルトでサポートされていません。
ただし、このサービスが備えている機能の一つに、パッチ適用の対象となっている各 VM でパッチ適用前スクリプトとパッチ適用後スクリプトを実行する機能があります。パッチ適用事前実行スクリプトまたは事後実行スクリプトは、VM インスタンス上で、これらいずれかのパッチ適用に関連付けられたサービス アカウント（Compute Engine のデフォルト サービス アカウントまたは作成中に使用されたサービス アカウント）のコンテキストで実行されます。
本ブログでは、パッチ適用前スクリプトを活用して、パッチ適用前に VM のアタッチ済み永続ディスクのクラッシュ整合ディスク クローンを作成する方法についてご説明します。
考慮事項
このブログでは、お客様が遭遇する一般的な問題の解決策をご紹介します。理想的な解決策は、VM 上に関連付けられたサービス アカウントのコンテキストでスナップショットを作成する必要がない、サービス内での直接統合です。必要な権限をサービス アカウントに付与することで、VM にログインできるすべてのユーザーにこれらの権限を最終的に付与できます。
VM のパッチ適用をディスクのクローン作成に依存させる（この記事に掲載されたサンプル スクリプトはそのようにして作成されています）ということは、クローンの作成に失敗した場合には、最終的に VM へのパッチ適用が行われないことを意味します。
前提事項
VM Manager と OS Patch Management の設定は、この記事では取り扱っていません。プロジェクトに対し VM Manager を有効化するには、VM Manager の設定の指示に沿って操作してください。
権限
ディスクのクローンを作成するには、VM に関連付けられたサービス アカウントに少なくとも以下の権限を付与する必要があります。
compute.disks.create # プロジェクトに対し
compute.disks.createSnapshot # ソースディスクに対し
スコープ
クローンを作成するスクリプトは、最終的に、パッチ適用される VM で実行されます。つまり、VM に関連付けられたサービス アカウントに正しい権限を設定するだけでなく、API スコープも設定する必要があります。
スコープを [すべての Cloud API に完全アクセス権を許可] に設定します。
スクリプトをアップロードする
このセクションの最後に、Linux と Windows の両方のオペレーティング システム向けのサンプル スクリプトを掲載しています。これらのスクリプトは Debian 10、Ubuntu 20.04、最新版の Container-Optimize OS、Windows Server 2019 でテスト済みです。別バージョンの OS を使用している場合は、スクリプトをテストすることを強くおすすめします。
いずれのバージョンのサンプル スクリプトも、以下の同じロジックに従って作成されています。
パッチジョブの ID を取得する（検出しやすいよう、スナップショットへのタグ付けに使用されます）。
VM に関連付けられたディスクを取得する
ディスクのクローンを作成する
適切なバージョンの更新スクリプトをダウンロードしてから、これをストレージ バケットにアップロードする必要があります（このガイドでは、この方法についてご説明します）。
# スクリプトを GCS バケットにコピーします
gsutil cp clone-linux.sh gs://<BUCKET>/clone-linux.sh
ここで、アップロードしたファイルのバージョンを取得する必要があります。パッチサービスが正しいバージョンを選択して実行できるよう、バージョンを渡す必要があります。
# ファイルのバージョンを取得します
gsutil ls -a gs://<BUCKET>/clone-linux.sh | cut -d'#' -f 2
Linux
Windows
パッチ適用前スクリプトを実行してパッチジョブを作成する
これでスクリプトのアップロードが完了したため、パッチジョブを作成できます。パッチジョブは、オンデマンド方式でもスケジュールに従う形でも作成可能です。また、パッチジョブは、VM インスタンスの複数のサブセットを対象とするよう設定できます。インスタンス フィルタに関する詳細については、こちらのドキュメントをご覧ください。
以下のサンプルでは、すべてのインスタンスを対象としたオンデマンド パッチジョブが作成されます。GCS バケットとスクリプトのファイル バージョンの正しい値を必ず指定してください。
Linux
Windows
スナップショットの作成を検証する
パッチ適用結果 / Cloud Logging
[Compute Engine] > [OS Patch Management] の順に移動します。
[Patch Jobs] を選択します。
ジョブを選択して、ステータスを確認します。
詳細を確認する場合は、パッチジョブ実行の詳細のオーバーレイを下にスクロールして、このジョブの対象となっていた VM のビューを選択します。
Cloud Logging が開き、スクリプト実行の詳細ログが表示されます。
クローン
[Compute Engine] > [Disks] の順に移動します。
使用可能なディスクを確認します。
ディスクのクローンの名前は、元のディスク名にパッチジョブの ID が付けられたものです。また、見つけやすいよう、複数のラベルが設定されています。
ディスクのクローンの名前は、元のディスク名にパッチジョブの ID が付けられたものです。また、見つけやすいよう、複数のラベルが設定されています。
まとめ
パッチ適用前スクリプトとパッチ適用後スクリプトを使用して、企業の一般的な要求事項に自動的に対応する方法をご説明した今回のブログはいかがでしたでしょうか。制約と考慮すべき事項がありますが、このプロセスを利用すれば、パッチの大規模適用前にワークロードを保護できます。
VM Manager について詳しくは、ドキュメントにアクセスするか、Google Cloud Next ‘20: OnAir セッション、大規模な Compute Engine VM フリートの管理（Managing large fleets of Compute Engine VM fleets）をご参照ください。
-EMEA 担当ソリューション リード Christoph Petersen
