OSSのサーバ構築自動化ツール、4製品徹底検証 2016年版：実際に検証済み！OSS徹底比較（4）サーバ構築自動化【後編】（8/8 ページ）

[森元敏雄,TIS]

4製品を振り返って

　4製品を実際に評価してみて分かったこと、感じたことを以下にまとめてみたい。

1.環境構築の情報入手と作業負荷

　基本的に、どの製品も公式サイトのガイドを参照することでインストールできた。Ansible／Itamaeのインストール作業は数ステップであり、さらにnode側のエージェントも不要のため、導入コストは非常に少ない。

　インターネットで検索しても、各製品とも多くの情報を入手できる。ただ、Puppetだけは歴史が長く利用者数も多いため、3.x時代の情報が非常に多く見つかってしまい、インストール手順が異なる4.xの情報を探すのに少し苦労させられた。だが環境構築の部分が違うだけで、manifestの作成方法やpuppet agentの使い方が変わっているわけではないので、その部分では問題なかった。

2.各製品の機能の差異を比較するには

　各製品でどのような機能が提供されているかについては、以下のリファレンスで提供されているリソース／モジュールを参照すると分かりやすい。

• Chefのリソースのリファレンス
• Ansibleのモジュールのリファレンス
• Puppetのリソースのリファレンス
• Itamaeのリソースのリファレンス

　特にAnsibleのモジュールの数の多さには驚かされる。提供するリソース／モジュール数を多くすることで利便性を向上するか、必要最低限のリソースを提供することでシンプルな使い方にするか、といった各製品の特徴がよく表れている。

3.cookbook/playbook/manifestの作成の難易度

　全製品を評価して感じたのは、先行製品であるPuppetの機能がベースになっており、共通点が非常に多いという点である。製品ごとに若干の違いはあるが、サーバ構築自動化ツール共通のリズム（?）のようなものがあり、どれか1つの製品でも使用経験があれば、他の製品を使用する場合も学習コストを下げられると考えられる。

　各製品ともベストプラクティスが定義されているが、最初からそれに準拠して作成しようとすると、RubyやPythonなどの言語に、アプリケーションが開発できる程度に習熟している必要性が生じてしまう。今回の検証例はベストプラクティスにある程度準拠しているが、できる限りシンプルな構成にしている。まずは動くところまで確認してから、徐々に改善していくのが良いのではないかと考えている。

4.cookbook/playbook/manifestのサンプル

　いったん製品を動かしてみて、ある程度まで使えるようになったら、公開されているサンプルを使ってみることをお勧めする。特に公式サイトが提供してるサンプルはベストプラクティスに準拠しており、製品の正しい使い方を理解することができる。

　ただ、一部のサンプルは、多プラットフォームに対応するため、複雑なプログラミングが実装されている場合も多い。そのため理解するのが難しいだけではなく、障害が発生した場合の調査にかなり苦しんだ。私見ではあるが、本番環境の運用にサンプルをそのまま使うのは、問題発生時のリスクも大きいため、あまりお勧めしない。

5.検証する環境

　cookbook/playbook/manifestの検証を行う場合、環境の構築を繰り返すこととなり、nodeを初期状態に戻したいニーズが何回も発生する。検証中はVMwareやVirtualBoxなどのスナップショットを活用して、初期状態にいつでも戻せる状態を実現するのが非常に便利である。製品評価の前に、検証用の環境を準備することをお勧めする。

最後に

　本稿はサーバ自動構築ツールを初めて使う方が“実際に使い始められる状態”を実現することを目的としており、必要となるコマンド、設定ファイル、手順は全て記載されているはずである。各ツールとも、動かしてみないとなかなか理解が難しいが、一度、動かすことができれば、改善や拡張は比較的容易に行える。まずは実際に動かしてみて“体験”することをお勧めしたい。本稿がその一助になれば幸いである。

著者プロフィール

森元 敏雄（もりもと　としお）

TIS株式会社

R&D部門である戦略技術センター所属。

金融系の大規模システム開発やプライベートクラウド開発環境の構築・運用の経験を生かし、OSS製品を中心とした技術調査・検証を担当。