今OpenStack(R)の構成管理ツールはAnsible(R)がアツい!
2015年5月18日から22日まで、カナダのバンクーバーで開催された「OpenStack Summit May 2015 Vancouver」からたった数ヶ月で「OpenStackの構成管理ツールはAnsibleを使おう!」が合言葉となり、Ansibleの新規導入や別ツールからの転換が活発になっています。
テクノロジーコラム
- 2015年08月24日公開
********************
2015年5月18日から22日まで、カナダのバンクーバーで開催されたOpenStack開発者/ユーザ/管理者のための国際イベント「OpenStack Summit May 2015 Vancouver」では、構成管理ツールAnsibleの技術に関するセッションは立ち見が出るほどの大盛況でした。
その際の参加者アンケートでは、OpenStackの構成管理ツールに"Puppet(R)"を利用するユーザがまだまだ圧倒的に多かったのですが、たった数ヶ月で「OpenStackの構成管理ツールはAnsibleを使おう!」が合言葉となり、Ansibleの新規導入や別ツールからの転換が活発になっています。
以下は、2014年におけるOpenStackユーザ調査の洞察(構成管理ツール)です。
1. なぜ構成管理ツールを使うのか
近年のシステム開発では、構成管理は非常に大きな役割を果たしています。
- 短期間かつ高品質で、低コスト化が求められている
- オフショア開発など異なる拠点で開発を進めたい要望が増えつつあり、
拠点に関わらず同じ構成を簡単にデプロイできる仕組みが求められている
構成管理ツールは、これらの要望に対して予め準備した処理に従って自動実行することで、
的確なデプロイを実現してくれます。
OpenStackは、セルフプロビジョニングによる操作性のあるサービス提供と、
大量のリソース要求にも応えられるスケーラビリティを実現しています。
つまり、インフラとなるリソース(サーバ、ネットワーク、ストレージ)を迅速かつ柔軟に提供するためにも
OpenStackと構成管理ツールを併用することがその特性と効果を充分に発揮するのです。
2. 構成管理ツールの比較
分類 |
Puppet |
Chef |
Ansible |
開発元 |
Puppet Labs |
Opscode |
Ansible |
初リリース |
2005年 |
2009年 |
2012年 |
ベース言語 |
Ruby |
Ruby、Erlang |
Python |
定義ファイル |
独自 |
独自(Rubyベース) |
YAML(※2) |
導入事例(※1) |
クックパッド(株) |
グリー(株) |
LINE(株) |
(※1)導入事例の参考
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
(※2) 構造化データやオブジェクトを文字列にシリアライズするためのデータ形式の1つ。読み易く書き易い。
Ansibleは、他と比べてリリース後の期間は短いですが、
以下の理由から新たな採用や移行を考える企業が増えたのだと考えます。
- 導入しやすい(初心者にも理解しやすい)
- 高い安定性(過去に作り出された構成管理ツールの反省や改善も考慮されている)
- 技術の刷新(システム更改時の技術アピール等)
3. 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. AnsibleでOpenStackをお試しインストールしてみましょう
4.1. AnsibleにはOpenStackのモジュール群が用意されていますが...
Ansibleがデフォルトで提供するOpenStackモジュールを使ってOpenStackデプロイのコーディングを試したところ、
微妙な対応範囲で「惜しい!」と思う部分が散見されました。
主なKeystoneコマンド |
Ansible対応モジュール(デフォルト) |
Ansible対応モジュール(GitHubコミュニティ) |
テナント作成(create tenant) |
keystone_user |
keystone_user |
ユーザ作成(create user) |
keystone_user |
keystone_user |
ロール作成(create role) |
keystone_user |
keystone_user |
ユーザ/ロール連携(user-role-add) |
keystone_user |
keystone_user |
エンドポイント作成 |
なし |
keystone_service |
例えば、Keystoneの主要CLIのAnsibleデフォルトモジュール対応は2015年7月現在には以下であり、
たった1つの不足する処理"エンドポイント作成"のために、べき等性の処理(データベース事前登録有無の確認、
サービス起動状態の確認)を付加した結果、コーディング量が増え、Ansibleのお手軽さが半減してしまいました。
4.2. OpenStackコミュニティではAnsibleを使ったデプロイ改善が活発です
今コミュニティでは、OpenStackのデプロイにAnsibleを使うための改善/取組みが為されています。
OpenStackの各コンポーネント対応範囲を確認したところ、導入~運用するうえでの主要な処理はほぼ網羅されており、
私がAnsibleデフォルトモジュールだけでは不便に感じた処理にも対応が為されていました。
採用ユーザが急激に増えたからこその状況なのではないでしょうか。
例)openstack-ansible GitHub対応状況(2015.7.23時点)
OpenStack Havana版でリリースされたコンポーネントまでが対応済み。
コンポーネント名 |
概要 |
説明 |
コミュニティ対応状況 |
Swift |
Object Storage |
オブジェクトストレージサービスを提供する。NFSのバックエンドとしてよく利用される |
○ |
Nova |
Compute |
仮想マシン管理やハイパーバイザとの接続を提供する |
○ |
Glance |
Image |
仮想マシンの起動イメージサービスを提供する |
○ |
Horizon |
Dashboard |
セルフサービスポータル(Web GUI)を提供する |
○ |
Keystone |
認証 |
認証サービスを提供する |
○ |
Neutron |
Networking |
L2/L3ネットワーク、Firewallの仮想ネットワークサービスを提供する |
○ |
Cinder |
Block Storage |
永続的なブロックストレージサービスを提供する |
○ |
Ceilometer |
メータリング、運用監視基盤 |
各サーバからシステム情報を定期的に収集して保存する |
○ |
Heat |
自動化 |
仮想マシン作成からアプリのインストール等を自動化するテンプレート |
○ |
Trove |
データベース |
データベースに係るサービスを提供する |
|
Sahara |
ビッグデータ |
ビッグデータに係るサービスを提供する(例:Hadoop、Spark) |
|
Ironic |
ベアメタル |
仮想マシン(Nova)に代わってベアメタル・プロビジョニングを実施する |
5. OpenStack × Ansibleのススメ
Ansibleはユーザフレンドリーな構成管理ツールです。
OpenStackのように更新サイクルの早いオープンソースにも追従しやすく、
またサービス運用/メンテナンスの面でも構成管理しやすいと感じました。
OpenStackの操作性評価ならばDevstackを、
一歩踏み込んで構築部分の理解やサービス運用性評価するならばopenstack-ansibleに触れてみることをオススメします。
また、Ansbileの構成や記述方法の理解も深めるには、openstack-ansibleのソースとOpenStack手動インストール手順を
比較することが近道です。
NTTソフトウェアでは、OpenStack本体だけでなく、
OpenStackとの連携ソフトウェア(例:ロードバランサや監視ソフトウェア)やパラメタ設計のノウハウを、
Ansibleを使ってデプロイするプライベートクラウド構築ソリューションを提供しています。
OpenStackの導入を検討している方は、ぜひお問い合わせください。
OpenStackクラウドに関する定額制サポートチケット:
6. 参考文献・関連情報
- Ansible Documentation
http://docs.ansible.com/index.html
http://www.kyoshida.jp/ansibledoc-ja/index.html
- OpenStackインストールガイド(Juno版)
http://docs.openstack.org/juno/install-guide/install/apt/content/index.html
- コミュニティ版OpenStack-Ansible(GitHub)
https://github.com/openstack-ansible/openstack-ansible
- OpenStack User Survey Insights(OpenStackユーザ調査の洞察)
http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014
※OpenStack(R)はOpenStack, LLCの登録商標又は商標です。
※Ansible(R)はAnsible, Incの登録商標又は商標です。
※Puppet(R)はPuppet Labsの登録商標又は商標です。
※Chef(R)はChef Software, Incの登録商標又は商標です。