OS Configuration Management で VM の構成管理を一元化してみる
オンプレミスやクラウドなど、仮想マシン (VM) を稼働するためのプラットフォームはさまざま存在しますが、どのようなプラットフォームであっても異なる OS が存在する多数の VM をどう管理するかは永遠のテーマです。
この記事では、Google Cloud の Compute Engine を管理する機能である OS Configuration Management (2021 年 11 月時点でプレビュー) を利用するとどのようなメリットがあるかについて、また実際の設定についてご紹介します。
なお、OS Configuration Management (ベータ版) というバージョンもあってわかりづらいのですが、現在はプレビュー版の利用をおすすめしており、本記事もプレビュー版について記載しています。ベータ版とプレビュー版の比較についてはこちらのドキュメントに記載がありますので、ご紹介します。
Tl; dr;
OS Configuration Management を利用することで Compute Engine の管理を行う際に以下のメリットを享受できます。
- ソフトウェアのインストールを一括で行うことで管理工数が削減できる
- インスタンスごとに構成に差分が生じることを防げる
- インスタンスが「あるべき状態」に保たれることが保証される
OS Configration Management の概要
OS Configuration Management は、Compute Engine の各インスタンスへのソフトウェアのデプロイやその構成、メンテナンスを一元管理できる機能です。
ユーザーが “インスタンスがこうなっていてほしい” というあるべき姿、例えば「すべてのインスタンスにモニタリング用のエージェントがインストールされていてほしい」といった定義を行うことで、OS Configuration Management はその定義に則って常にインスタンスをユーザーが指定した状態に保ちます。つまり、Configuration as Data (CaD) のアプローチで IaaS VM の管理ができます。
このアプローチの何が嬉しいかというと、定義さえ間違っていなければ、(状態の検証は一定間隔で行われるので多少のタイムラグは生じるものの) 追加の構成などを行うことなくインスタンスが常に管理者が望んだ状態であることが保証されることです。VM のイメージに必要なパッケージをすべて含んで展開したとしても、何らかの理由であるパッケージがアンインストールされることもないとは言い切れませんが、OS Configuration Management を利用することでインスタンスは管理者が望んだ状態に自動的に修正されます。
類似機能を持つ OSS もあるかと思いますが、Google Cloud のネイティブ機能としても提供してることはあまり知られていない (?) かと思ったので本記事で取り上げてみました。
OS Configuration Management の動作の流れ
OS Configuration Management の機能は、主に以下の 3 つのコンポーネントから構成されています。
- OS ポリシー : あるべき姿を定義するための JSON またはYAML ファイル
- OS ポリシーの割り当て : OS ポリシーの適用対象などを指定する設定 (特定の OS のみに適用するなど)
- OS Config エージェント : インスタンスの状態が OS ポリシーの定義に則っているかの検証などを行うインスタンス上で実行されているエージェント
60 分に一度、OS Config エージェントは自身が動作するインスタンスが OS ポリシーの定義に則っているかを検証します。もし OS ポリシーの定義に則っている場合には何も行いませんが、必要なパッケージがインストールされていないなど、定義に則っていない場合には必要なアクション (パッケージのインストールなど) を行います。(厳密には、OS ポリシーで “検証のみ” と定義した場合にはアクションは行いません)
実行可能なアクションは以下の通りです。
- パッケージのインストール (yum や apt などによるインストール)
- bash スクリプトや PowerShell スクリプトの実行
- ファイルの配置
OS Configuration Management のユースケース
OS ポリシーでは実行アクションとしてスクリプトを実装できるので、わりと幅広い定義ができます。あくまでも一例になりますが、例えば以下のようなユースケースで利用できます。
- 監視用エージェントのインストール
- パッケージの一括アップデート
- 常時実行されているべきプロセスの実行状態の確認 (および実行)
特に、監視用エージェントのインストールや実行状態の確認などは、最適なユースケースのひとつかと思います。トラブルが発生していない場合にはメトリックやログはあまり気にしないかもしれませんが、いざトラブルが発生した場合にエージェントがインストールされていなかったのでログがないとなってしまっては取り返しがつきません。
Configuration as Data (CaD) の良さ
リソースのデプロイをコード化する方法として、CaD の他に Infrastructure as Code (IaC) という概念もあります。IaC では、インフラの構成 (vCPU 数やメモリー容量など) を定まったフォーマットに沿ってコード化し、そのファイルを利用してリソースをデプロイします。定義ファイルを適用するのみでリソースをデプロイするため、Cloud Console や gcloud コマンドを利用した場合と比較して属人性の排除、構成ミスの発生抑止といった効果が期待できます。
IaC も効率的なインフラ管理の方法のひとつですが、基本的にはリソースのデプロイ時に利用するものです。そのため、例えばデプロイ後にコードで定義された構成に変更が加えられた場合には IaC の仕組みの中でその変更が感知されず、定義と実際の構成にズレが生じる可能性があります。CaD の場合、リソースが定義に則っているかが CaD の仕組みの中で定期的に検証され、定義に則っていない場合には差異を修正する動作となることで、常に意図した状態にリソースを保つことができます。
実際に構成してみる
それでは、実際に OS Configuration Management を構成してみます。今回は、モニタリングとロギングの機能が統合された Ops エージェントを Compute Engine にインストールするというシナリオを試してみます。なお、Ops エージェントは基本的にすべてのインスタンスにインストールすることをおすすめしておりますが、今回は動きを確認するためにあえて数台にしかインストールしない構成としてみます。また、以下の手順では Compute Engine インスタンスがデプロイ済みであることを前提としています。
手順 1. VM Manager の有効化
OS Configuration Management は VM Manager という Compute Engine の管理を支援するスイートの中のひとつの機能です。費用は OS Config エージェントが稼働しているインスタンス数に応じて時間単価で課金されますが、ひと月に 100 インスタンス分までの無料枠があります (2021 年11 月時点)。
VM Manager は自動、もしくは手動での有効化ができ、自動で有効化した場合にはプロジェクト全体、手動で有効化した場合にはプロジェクト全体、もしくは個別の VM ごとに有効化されます。今回はプロジェクト全体で有効化させるために自動で有効化してみます。具体的には、Cloud Console の Compute Engine メニューから [OS 構成管理] を開いて VM Manager を有効化します。(手動で VM ごとに有効化する場合にはこちらのドキュメントをご参照ください)
VM Manager を有効化すると、既存のインスタンスの一覧が表示されます。今回は 4 種類の OS のインスタンスを作っており、まだポリシーを何も作成していないので “状態” の列は「ポリシーなし」となっています。
手順 2. OS Config エージェントのインストール
OS Configuration Management の機能を利用する場合、OS Config エージェントがインスタンス内で動作している必要があります。Google Cloud より提供しているイメージの場合、ビルドの日付が v20200114 以降であれば OS Config エージェントは既定でインストールされています。なお、OS Configuration Management の費用は OS Config エージェントが稼働しているインスタンス数に応じて発生しますが、既定でインストールされているエージェントはアイドル状態にあり、VM Manager を有効化するまでは課金対象ではありません。
もしイメージ インポートなど、その他の方法で作成いただいたイメージをご利用の場合には、以下の方法で OS Config エージェントをインストールします。
※ エージェント ポリシーを利用する方法もドキュメント上紹介されておりますが、ポリシー設定などが必要となり、上記の方法の方が簡易かと思いますので割愛しています。
手順 3. OS ポリシーの作成
OS Configuration Management のメインである OS ポリシーを作成します。OS ポリシーにはインスタンスにどのような状態であってほしいかを定義しますが、今回は「Ops エージェントのある特定のバージョンがインストールされていてほしい」という例を考えてみます。(パッケージは意図しない動作変更などの影響を受けないようにバージョンを固定するのが一般的かと思いますので、常に最新に保つといった指定ではなくバージョンを固定するポリシーを作成します)
今回は OS ポリシーを YAML で定義し、Ops エージェントは 2021 年 11 月時点における最新バージョンのひとつ前である 2.6.0 を指定します。大まかな流れは以下の通りです。 なお、現状の動作では、パッケージのバージョン判定はインストール時 (下記の手順 3.) ではなくスクリプトにて行う (下記の手順 4.) 必要があります。
- ポリシーに則っているかの検証のみを行うかアクションの実行まで行うかの指定 (mode)
- パッケージをダウンロードするリポジトリを指定 (repository)
- Ops エージェントのインストール可否を検証し、インストールされていない場合にはエージェントをインストール (pkg)
- Ops エージェントのバージョンを検証し、要件に沿うバージョンではない場合にはバージョンを修正 (exec)
上記を踏まえた OS ポリシーのサンプルは以下のようになります。mode 部でポリシーへの準拠を強制 (ENFORCEMENT) し、repository 部でパッケージを取得するためのリポジトリを指定します。そして pkg 部で利用するパッケージ マネージャー (今回は yum) とパッケージ名を指定し、exec 部で意図したバージョンに沿っているかの確認を行います。
Github のリポジトリにサンプルが公開されていますので、ご紹介します。
また、OS ポリシーを構成する各項目の概要やリファレンスについてもご紹介します。
手順 4. OS ポリシーの割り当ての作成とロールアウト
最後に、手順 2. で作成した OS ポリシーをどのインスタンスに適用するかを指定するために OS ポリシーの割り当てを作成します。
OS ポリシーの割り当ては、Cloud Console の画面上部にある [+ OS ポリシーの割り当ての作成] から作成します。OS ポリシーの割り当てを作成する場合、以下の項目を設定します。
- 割り当て ID : 任意の名前
- OS ポリシー : 作成した OS ポリシーの YAML ファイル
- 可用性ゾーン : インスタンスが存在するゾーン (※1)
- OS ディストリビューションのマッチング : OS ポリシーを適用する OS
- ラベルを含める/除外する : ラベルで適用対象のインスタンスを区別する場合に指定
- ロールアウト率 : 一度にポリシーを適用するインスタンスの割合 (※2)
(※1) OS ポリシーの割り当てはゾーン単位で作成します。
(※2) 最初に OS ポリシーを適用するインスタンスの割合、および残りのインスタンスに OS ポリシーを適用するまでの間隔 (分) を指定します。この機能は、誤った OS ポリシーを適用してしまった場合にその影響を一部のインスタンスに限定できるなどの効果があります。
今回は OS ポリシーの割り当てがどのように動作するかの確認のため、あえて CentOS と RHEL のみを適用対象の OS としています。
OS ポリシーの割り当てを作成すると定義がロールアウトされ、CentOS と RHEL のインスタンスにだけ OS ポリシーが適用されます。なお、OS ポリシーの割り当ての作成後にすぐにポリシーがロールアウトされますが、ロールアウト率の設定によっては一部のインスタンスにだけすぐにポリシーがロールアウトされ、残りのインスタンスは指定した時間の経過後にロールアウトされる動作となります。(ロールアウト率を 100% にすることで、すべてのインスタンスに同時にポリシーがロールアウトされます)
ちなみに、ポリシーに遵守しているとの記載の通り CentOS と RHEL のインスタンスには Ops エージェントがインストールされていますが、これが OS Configuration Management の効果でインストールされたことを念のため確認してみます。(あらかじめインストールしておいたわけではないことを確認してみます)
OS ポリシーの適用結果は Cloud Logging に保存されるので該当のログを抜粋してみてみると、ログは 2 つのパートに分かれています。1 つ目 (赤枠部分) がポリシー適用時のログで、install-pkg と check-version のステップがともに NON_COMPLIANT と表示されていることからポリシーを遵守していなかったことがわかります。そしてその後 yum による google-cloud-ops-agent をインストールや、OS ポリシー内の exec 部分に指定したスクリプトによって適切なバージョンをインストールするログが確認できます。2 つ目 (緑枠部分) がポリシー適用後のログで、ポリシーの適用後に再度検証が行われた際の検証結果が記載されたログです。ポリシーの適用によって想定した状態となったため、すべてのステップが COMPLIANT となっていることがわかります。
そして、念のため次の検証が行われた 1 時間後のログを再度見てみると、前回の OS ポリシーの適用時に定義した構成となっているため、install-pkg と check-version のステップがともに COMPLIANT となっており、アクションを実行せずに検証が終了したことが確認できます。
まとめ
本記事では、IaaS VM の管理を少しでも楽にする機能として OS Configuration Management についてご紹介しました。この機能を利用することで、主に以下のようなメリットが得られるかと思います。
- ソフトウェアのインストールを一括で行うことで管理工数が削減できる
- インスタンスごとに構成に差分が生じることを防げる
- インスタンスが「あるべき状態」に保たれることが保証される
クラウドと言っても IaaS は管理が大変といったイメージもあると思いますが、クラウドならではの機能を利用することで管理工数も減らせます。今回ご紹介した OS Configuration Management が含まれる VM Manager には、他にも更新プログラムの適用を自動化する機能などもありますので、今後も管理を楽にする機能をご紹介していこうと思います。
