Puppetのマニフェストに求められること
前回は、構成管理の自動化、Puppet、マニフェストについて簡単に説明しました。
今回は、マニフェストについてもう少し掘り下げて説明します。
マニフェストに求められること
前回取り上げた通り、マニフェストとは、システムのあるべき姿を記述したファイルであり、Puppet独自の言語で記述します。
各サーバに、マニフェストに記述したことを適用することで、各サーバ・システムをあるべき姿にします。
システムをあるべき姿にし続けるためには、マニフェストを作成する際に以下のポイントに気をつける必要があります。
- 依存関係
- 抽象化
- 冪等性
一つずつみていきましょう。
1. 依存関係
依存関係：自動構築する対象の構築順序が正しく考慮されていること
HTTPサーバの構築を例にとりましょう。
おおよその流れはこんな感じになると思います。
ここで、1.と3.の順序を入れ替えた場合、HTTPサーバの構築は可能でしょうか？
パッケージをインストールされた状態でないと、自動起動設定はおろか、httpd.confの設定も当然できませんよね。
このように、システムを構築する場合、構築の順序を考慮する必要があります。
マニフェストも例に漏れず、構築順序を正しく記述する必要があります。
マニフェストには、構築の依存関係を考慮した記述が可能ですが、詳しいことは割愛します。
2. 抽象化
抽象化：OSの違いなど環境差異に依存しないこと
CentOSとUbuntuのパッケージインストールを例にとりましょう。
それぞれこのようなコマンドでインストールします。
やっていることは同じですが、コマンド・パッケージ名が異なります。
仮に、マニフェストを書く際に、環境差異を考慮しなくてはいけないとしましょう。
パッケージを一つインストールするだけでも、環境ごとに分けてマニフェストを記述することになってしまいます。
様々な、OSが入り混じった環境を構成管理する場合、あまりスマートではありません。
Puppetでは、OSごとの環境差異を吸収し、同じ作業であれば同じ命令を使うことができます。
この抽象化の仕組みをRAL(Resource Abstraction Layer)といいます。
3. 冪等性
冪等性：何度自動構築を実施しても、その度にシステムが同じ状態に構築されること
再び、HTTPサーバの構築を例にとりましょう。
最初の構築では、1.〜4.全てを実施して問題ありません。
しかし、運用中にMaxClientsのチューニングが必要になった場合はどうでしょうか。
1.と3.を再びやる必要はなく、2.と4.だけやれば十分です。
仮に、手作業で冪等性を担保しようとすると、このような条件分岐をいちいち考える必要があります。
Puppetでは、「インストール済みなら何もしない」など、現状に応じて冪等性を担保するための仕組みが備わっており、マニフェストを何度適用しても同じシステムが出来上がるようになっています。
さいごに
今回は、マニフェストに求められる要素をそれぞれ取り上げました。
3要素を取り上げましたが、これらはPuppetに限らず「構成管理」をする上での大事な要素と考えた方が良いでしょう。
