近年のシステム開発では、構成管理は非常に大きな役割を果たしています。

　- 短期間かつ高品質で、低コスト化が求められている
　- オフショア開発など異なる拠点で開発を進めたい要望が増えつつあり、
　　拠点に関わらず同じ構成を簡単にデプロイできる仕組みが求められている

構成管理ツールは、これらの要望に対して予め準備した処理に従って自動実行することで、
的確なデプロイを実現してくれます。

OpenStackは、セルフプロビジョニングによる操作性のあるサービス提供と、
大量のリソース要求にも応えられるスケーラビリティを実現しています。
つまり、インフラとなるリソース(サーバ、ネットワーク、ストレージ)を迅速かつ柔軟に提供するためにも
OpenStackと構成管理ツールを併用することがその特性と効果を充分に発揮するのです。

　(※１)導入事例の参考
　　http://www.slideshare.net/satoship/puppet-2666139
　　https://speakerdeck.com/ryotarai/guriniokeruchefdao-ru-shi-li-ji-cun-falsezi-chan-wohuo-kasixin-siiji-shu-wodao-ru-suru
　　http://www.slideshare.net/tagomoris/ansibleja?related=1
　(※２) 構造化データやオブジェクトを文字列にシリアライズするためのデータ形式の1つ。読み易く書き易い。

Ansibleは、他と比べてリリース後の期間は短いですが、
以下の理由から新たな採用や移行を考える企業が増えたのだと考えます。

　- 導入しやすい（初心者にも理解しやすい）
　- 高い安定性（過去に作り出された構成管理ツールの反省や改善も考慮されている）
　- 技術の刷新（システム更改時の技術アピール等）

3.1. エージェントレス

AnsibleはPush型ツールのため、構成管理対象ノードにエージェントをインストールする必要がありません。
Ansibleをインストールしたマシン1台と構成管理対象ノードとの間でssh接続ができればよいため、
導入作業は簡単でしかもスモールスタートができます。




一方、PuppetやChefは全ての構成管理対象ノードにエージェントの導入が必要となるため、
初心者にはAnsibleよりも導入やメンテナンス作業が煩雑です。

3.2. シンプルな処理記述

ChefやPuppetの定義ファイルは、独自フォーマットで作られていること、Rubyの知識を要することから、
Ruby初心者には理解するまでに時間と労力がかかります。
一方、AnsibleではYAMLフォーマットが採用されているため、どのような処理かイメージしやすいです。

以下はパッケージインストールする際の記述例です。
指定オプションはたくさんありますが、シンプルに書けばたったこれだけです。
開発経験が少なくても処理内容が分かりやすいと思いますが、いかがでしょうか？


⇒説明：
ノード"testnode1"に対して、ユーザ"user1"(sudo使用)にてaptモジュールを使って
パッケージ"keystone"をインストールする。

3.3. 簡単な処理走行

Ansibleは処理実行も簡単です。

実行対象ホストを増やす場合は"ホスト情報ファイル"の編集を、実行処理を増やす場合は
"実行するplaybookファイル(Ansibleによる処理情報一式)"を編集するだけで済みます。

また、実機からシステム内の実行対象ホストを一覧で参照し動的にホスト情報ファイルを生成できるので、
OpenStackの開発目的でもある「インフラへの対応・変動の激しいシステムに対応」して構成管理や運用をするうえで
有効な手段になります。

3.4. 記載した順序通りに実行される

Chefでは記載順序の通りに（上から順に）実行されるとは限りませんが、Ansibleは順序通りに処理が進みます。
これまでの手動インストール手順に沿ってAnsibleに書き起こせばよいので製造が簡単ですし、
順序が明快のため追加処理の要望にも即座に対応できます。

また、並列処理や待合せ処理も表現できるので、走行時間の短縮や手動確認介入の排除が実現でき、
なお且つ膨大なホスト台数に対応しやすいのもメリットです。

3.5. モジュールのべき等性によるコーディング量削減

Ansibleには"モジュール"と呼ばれるライブラリの概念があり、デフォルトで複数のモジュールを提供しています。
Ansbleモジュールは"べき等性"を持つため内部で挙動を自動判断してくれることが最大の特長です。
　（べき等性の例）サービス再起動指示のとき、サービス停止中ならば起動のみ行う

利用頻度の高い処理をモジュールにすることで、反復する確認処理を省略し、相対的にコード量の削減が実現できます。

3.6. モジュール記述言語の選択肢が豊富

Ansibleモジュールを作成する場合、モジュールの入出力の記述さえルールを守ればよいので、
Python以外にも様々な言語(例：Ruby、Perl、Java、bash)でコーディングすることができます。

既存モジュールの流用も可能なので、この点でも開発者はAnsibleの採用/移行に抵抗が少ないのかもしれません。

4.1. AnsibleにはOpenStackのモジュール群が用意されていますが...

Ansibleがデフォルトで提供するOpenStackモジュールを使ってOpenStackデプロイのコーディングを試したところ、
微妙な対応範囲で「惜しい！」と思う部分が散見されました。

例えば、Keystoneの主要CLIのAnsibleデフォルトモジュール対応は2015年7月現在には以下であり、
たった1つの不足する処理"エンドポイント作成"のために、べき等性の処理(データベース事前登録有無の確認、
サービス起動状態の確認)を付加した結果、コーディング量が増え、Ansibleのお手軽さが半減してしまいました。

4.2. OpenStackコミュニティではAnsibleを使ったデプロイ改善が活発です

今コミュニティでは、OpenStackのデプロイにAnsibleを使うための改善/取組みが為されています。

OpenStackの各コンポーネント対応範囲を確認したところ、導入～運用するうえでの主要な処理はほぼ網羅されており、
私がAnsibleデフォルトモジュールだけでは不便に感じた処理にも対応が為されていました。

採用ユーザが急激に増えたからこその状況なのではないでしょうか。

例）openstack-ansible GitHub対応状況（2015.7.23時点）
　　　OpenStack Havana版でリリースされたコンポーネントまでが対応済み。

Ansibleはユーザフレンドリーな構成管理ツールです。
OpenStackのように更新サイクルの早いオープンソースにも追従しやすく、
またサービス運用/メンテナンスの面でも構成管理しやすいと感じました。

OpenStackの操作性評価ならばDevstackを、
一歩踏み込んで構築部分の理解やサービス運用性評価するならばopenstack-ansibleに触れてみることをオススメします。

また、Ansbileの構成や記述方法の理解も深めるには、openstack-ansibleのソースとOpenStack手動インストール手順を
比較することが近道です。

NTTソフトウェアでは、OpenStack本体だけでなく、
OpenStackとの連携ソフトウェア（例：ロードバランサや監視ソフトウェア）やパラメタ設計のノウハウを、
Ansibleを使ってデプロイするプライベートクラウド構築ソリューションを提供しています。

OpenStackの導入を検討している方は、ぜひお問い合わせください。

OpenStackクラウドに関する定額制サポートチケット：