G-gen の杉村です。Compute Engine インスタンス群を管理・運用するための機能である VM Manager について徹底解説します。
VM Manger とは
VM Manager は、Google Cloud (旧称 GCP) の Compute Engine VM 群の管理・運用を自動化するためのサービスです。各種 Linux ディストリビューションに加え、Windows Server にも対応しています (対応 OS) 。
VM Manager には以下の機能が存在します。
No | 機能名 | 説明 |
---|---|---|
1 | Patch | OS やパッケージへのパッチ適用自動化やレポーティング |
2 | OS Inventory Management | OS やパッケージの情報収集 |
3 | OS policies | パッケージのインストール・削除・更新 |
なお Patch はかつて OS patch management
と、OS policies はかつて OS configuration management
と呼ばれていましたが2023年9月に機能名が改名されました。
これらの機能を実現するため、OS 上には OS Config エージェント と呼ばれるエージェントソフトウェアをインストールします (特定日以降の Ubuntu, RHEL, Windows Server などの公式イメージにはプリインストール済み) 。
このエージェントが Google Cloud 等と通信し、様々な管理タスクを実行してくれます。
余談ですが Amazon Web Services (AWS) にも類似のサービスとして AWS Systems Manager (SSM) があります。VM Manger はこれの Google Cloud 版とも言えます。
料金
料金 は VM Manager を有効化している VM の台数に対して発生します。
ただし、月に 100 台までの無料枠があります。100 台を超える VM から 1 台につき $0.003 / 時間の料金が発生します。
31 日ある月の場合、744 時間ですので $2.232 / 台 / 月です。
課金が発生するのは無料枠を超えた 101 台目のインスタンスからのみですので、安価に大量の VM を管理できることとなります。
Patch
Patch とは
Patch は OS やソフトウェアの管理をする機能です。2023年9月までは OS Patch Management と呼ばれていました。
以下の2つの主要機能があります。
- パッチ コンプライアンス レポート
- パッチデプロイ
前者は VM OS やパッケージのパッチ状況を分析・レポーティングしてくれる機能です。後者は OS やパッケージのパッチ当てを自動化する仕組みです。いずれも VM 内で OS Config エージェントが動作し、yum や apt などのコマンドを実行して実現してくれます。
パッチ コンプライアンス レポート
パッチ コンプライアンス レポート では、VM の OS やインストール済みパッケージのアップデート情報の整理・ダッシュボード化をすることができます。
VM Manager が有効化されると OS Config エージェントは約 10 分ごとに各種情報を取得し VM のメタデータ (ゲスト属性) に書き込みます (後述の OS Inventory Management でも利用される情報です) 。
さらに VM Manager は一般公開されている各 OS ごとの脆弱性情報と照合してレポートを作成します。脆弱性情報は RHEL / CentOS / Debian / Ubuntu で対応しており SLES / Rocky Linux / Windows Server では対応していません (参考) 。
入手可能なアップデートがあった場合、レポート上ではアップデートが 重大 (赤)、重要/セキュリティ (オレンジ)、その他 (黄色)、最新 (緑) に分類されます。
![](https://cdn-ak.f.st-hatena.com/images/fotolife/g/ggen-sugimura/20221108/20221108153326.png)
パッチデプロイ
概要
パッチデプロイ 機能により OS やミドルウェアに対してパッチ適用を実行することができます。
パッチデプロイ自体の実行は、Google Cloud コンソール / gcloud コマンド / API 直接実行により、Patch API (OS Config API) を呼び出すことで実行します。
- 参考 : パッチジョブを作成する
Patch API によりパッチデプロイが開始されると、Patch API は VM 内の OS Config エージェントに指示を出し、エージェントは apt / yum / Windows Update 等、OS 固有のパッケージ管理サービスを呼び出してアップデートを実行します。
そのため yum / apt といったパッケージ管理サービスがレポジトリにアクセスするために当該 VM からインターネットにリーチできる (パブリック IP を持っている / Cloud NAT を使う) か、ローカルレポジトリを用意する必要があります。
パッチ適用タイミング
パッチ適用はオンデマンド (即時) 実行するか、事前にスケジュール指定することができます。
繰り返し予定としてスケジューリングすることも可能です。
オンデマンド (即時) 実行は「同時パッチ適用 (Simultaneous patching)」、スケジュール実行は「定期パッチ適用 (Scheduled patching)」とも呼ばれます。
対象 VM の指定
パッチ適用の対象インスタンスは次のいずれかの方法で指定します。
- プロジェクトに所属する全 VM を指定
- 単一のインスタンス名で指定
- インスタンス名のプレフィクス (接頭辞) で指定
- ゾーン単位で指定
- ラベル で指定
また、対象となった VM 群のうち一度に停止する VM 数の割合を % で指定することができます。これにより一斉に VM が停止してしまうことを防ぐことができます。
対象となるアップデート
特定パッケージを指定したり、Windows の場合は KB 番号を指定することもできます。
例として Debian では Distribution updates / Package manager updates が対象であり、Windows では定義更新プログラム、ドライバー更新プログラム、機能パックの更新、などが対象です。
対象となるパッケージ種別は以下のドキュメントも参照してください。
- 参考 : OS パッチジョブの内容
![](https://cdn-ak.f.st-hatena.com/images/fotolife/g/ggen-sugimura/20221112/20221112101824.png)
前処理・後処理
アップデートを適用した VM の挙動として「再起動なし」「常に再起動」「必要なら再起動」のいずれかから指定することができます。
また、パッチ適用前、あるいは適用後 (再起動があれば再起動後) に実行するスクリプトを指定することもできます。スクリプトは Cloud Storage バケットに配置します。
組織・フォルダレベルでの情報閲覧
パッチのサマリ情報を組織レベル・フォルダレベルで閲覧することができます。
組織・フォルダ・プロジェクトに対して適切な権限を持っていれば、プロジェクトをまたいだ情報確認ができます。詳細は以下のドキュメントをご参照ください。
参考 : View patch summary for VMs in an organization or folder
OS Inventory Management
OS Inventory Management では以下のような情報を収集・表示できます。また、脆弱性情報を表示することもできます。
OS Config がおよそ 10 分間隔で以下の情報を収集します。
- OS 情報
- ホスト名
- LongName (OS の詳細名称。例 : Microsoft Windows Server 2016 Datacenter)
- ShortName (OS の短縮名。例 : Windows)
- カーネルバージョン
- OS のアーキテクチャ
- OS バージョン
- OS Config エージェントのバージョン
- Last updated (OS Config エージェントが最後に情報を更新した時間)
- Linux / Windows Server の RPM/yum/DEB/apt/GooGet for Windows Server から取れる情報
- Windows Server で以下から取れる情報
- Windows Update Agent
- Windows Quick Fix Engineering アップデート
- Windows Installer
情報を閲覧する方法は、以下のドキュメントを参考にしてください。
OS policies
概要とユースケース
OS policies (OS ポリシー) 機能では VM に対し、ソフトウェア構成のデプロイ・メンテナンス・レポート作成を行うことが出来ます。2023年9月までは当機能は OS Configuration Management と呼ばれていました。
OS ポリシーという定義ファイル (JSON or YAML) により VM のあるべき姿を定義して VM に適用すると、その状態とのズレが発生したときに是正アクションが自動的に取られます。
前述の Patch のパッチデプロイがオンデマンドあるいは定期的にアップデート指示を配信するものであるのに対して、OS policies はあるべき姿を定義してズレをなくしていくというイメージです。
以下のようなユースケースが示されています。
- モニタリングエージェントやセキュリティエージェント等のインストール・保守
- スタートアップスクリプトの管理
- コンプライアンスチェック
- パッケージレポジトリの管理
- ファイルの配信
- スクリプト実行によるサーバ内の状態維持
構成要素
OS ポリシー
OS ポリシー (OS policy) はタスクを定義するファイル (JSON または YAML) です。
以下の2つのモードのいずれかとして定義できます。
モード名 | 意味 |
---|---|
Validation | リソースが望ましい状態かチェックする。アクションは行わない。 |
Enforcement | リソースが望ましい状態かチェックする。望ましい状態でなければアクションを実行する。 |
また OS ポリシー内には以下の リソース を定義でき、実施するチェック / アクションを定義できます。
リソース名 | 意味 |
---|---|
pkg | パッケージのインストール / 削除を行う (Linux / Windows の両方で利用可能) 。 |
repository | パッケージを取得するレポジトリを指定する。 |
exec | /bin/sh (Linux) または Powershell (Windows) を実行する。 |
file | サーバー上のファイルを管理する。 |
YAML 形式だと、以下のサンプルのようになります ( ドキュメント より引用) 。以下のサンプルでは Cloud Storage から MSI ファイルをダウンロードし、インストールします。
# An OS policy to install a Windows MSI downloaded from a Google Cloud Storage bucket. id: install-msi-policy mode: ENFORCEMENT resourceGroups: - resources: - id: install-msi pkg: desiredState: INSTALLED msi: source: gcs: bucket: my-bucket object: my-app.msi generation: 1619136883923956
OS ポリシーの割り当て
OS ポリシーの割り当て (OS policy assignment) は OS ポリシーを実際に VM に適用する際に作成する設定です。
1 個の OS ポリシー割り当てで複数の OS ポリシーを指定できます。
また適用対象の VM は以下の軸で選択することができます。
- ゾーン
- OS ファミリー
- ラベル (含める)
- ラベル (除外)
例えば以下のような指定すると「 asia-northeast-1-b
ゾーンにある」「 ubuntu
の VM で」「 env:test
というラベルを持ち」「かつ goog-gke-node
というラベルを持たない」すべての VM に適用できます。
- ゾーン :
asia-northeast-1-b
- OS ファミリー :
ubuntu
- ラベル (含める) :
env:test
- ラベル (除外) :
goog-gke-node
ロールアウト
OS ポリシーの割り当てを実行する際に以下の ロールアウトオプション を設定することができます。
- ウェーブサイズ
- 待機時間
ウェーブサイズは一度にポリシーを適用する VM の割合です。対象となる VM のうち、何割が同時にアップデート等の対象になるかを指定できます。デフォルトは 10% です。
待機時間は、ポリシー適用開始から実際にロールアウトが始まるまでの待機時間です。ウェーブサイズごとにポリシー適用が始まり、最初のウェーブで問題が発生した際などに、待機時間があれば次のウェーブが始まるまでにロールアウトを中止することが可能になります。
エージェントと情報収集
OS policies でも OS Config エージェントが活躍します。VM 上の OS Config エージェントが OS ポリシーの取得、実行を行っています。
OS ポリシーの割り当てが作成されると、VM では 60 分のチェック間隔でポリシー確認・適用が走ります。
ポリシーが VM に配信されると、OS Config エージェントは VM 内部状況を確認し、ポリシー通りの状況になっていれば何もせず、ポリシーとの差異があれば是正するアクションを実行します。
組織・フォルダレベルでの情報閲覧
OS ポリシーの遵守状況を組織レベル、またはフォルダレベルで閲覧することができます。
組織・フォルダ・プロジェクトに対して適切な権限を持っていれば、プロジェクトをまたいだ情報確認ができます。詳細は以下のドキュメントをご参照ください。
参考 : View OS policy compliance summary for all VMs in an organization or folder
設定作業
概要
VM Manager を利用するには、以下両方が必要です。
- 指定サービスの API が有効化されていること
- 対象 VM に OS Config エージェントがインストールされていること
- プロジェクト単位または VM 単位で必要な Compute Engine メタデータが設定されていること
- VM がネットワーク要件を満たしていること
- VM にサービスアカウントがアタッチされていること
一通りの手順は以下のドキュメントに記載されていますが、当記事では概要を解説します。
- 参考 : VM Manager を設定する
サービス API の有効化
既に使っているであろう Compute Engine API に加えて、以下サービスの API を有効化する必要があります。
- OS Config API (
osconfig.googleapis.com
) - Container Analysis API (
containeranalysis.googleapis.com
)
OS Config エージェント
「対象 VM に OS Config エージェントがインストールされていること」を満たすには、VM にエージェントをインストールします。
Google Cloud 公式のイメージで VM を作成した場合、ビルド日付が v20200114
以降の CentOS、Container-Optimized OS、Debian、Red Hat Enterprise Linux (RHEL)、Rocky Linux、SLES、Ubuntu、Windows Server
には既にエージェントがプリインストール済みですので、特に何もしなくても問題ありません。
もしこれら以外のイメージの場合、以下のドキュメントを参考にしてエージェントをインストールします。
なお VM Manager の各機能がサポートする OS 一覧は以下のページを参考にします。
- 参考 : オペレーティング システムの詳細
プロジェクト全体でメタデータを設定
プロジェクトに所属する全ての VM を管理対象にする場合は、当手順を実施します。実施すると、既存の VM に加え今後作成される全ての VM が自動的に対象になります。
該当プロジェクトの Compute Engine コンソールにて「メタデータ」ページに移動します。
ここで以下のメタデータを追加します。
enable-osconfig
:TRUE
enable-guest-attributes
:TRUE
参考 : メタデータ値を設定する
VM 単位でメタデータを設定
プロジェクト全体ではなく、個別の VM 単位で有効化したい場合は対象 VM 単位にメタデータを設定します。VM の新規作成時に追加することもできますし、既存 VM に設定することもできます。
プロジェクト全体でメタデータを追加済みの場合は、当手順を行う必要はありません。
コンソールでは、VM 編集画面からカスタムメタデータを設定できます。追加するメタデータはプロジェクト全体のときと同様で enable-osconfig
: TRUE
と enable-guest-attributes
: TRUE
です。
ネットワーク要件
OS Config エージェントが Google Cloud 側の API と通信できるよう、VM が通信要件を満たしている必要があります。
VM が外部 IP を持っていたり、Cloud NAT 経由でインターネットに出られるようになっていれば問題有りません。
そうではない場合、以下のような方法で VM (OS Config エージェント) が OS Config API と通信できるようにします。
- サブネットで 限定公開の Google アクセス 機能を有効化
- HTTP プロキシを利用 (参考)
VM にサービスアカウントアタッチ
対象 VM にはサービスアカウントがアタッチされている必要があります。
ただしこのサービスアカウントには IAM ロールは不要です。サービスアカウントは OS Config API との通信に署名をするためだけに用いられるため、IAM ロールが付与されていない空のサービスアカウントで問題ありません。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it