Puppet人がAnsible界にきてみて
この記事はPuppet Advent Calendar 2015の14日目の記事です。 昨日はおっくんのPuppetの予約語 $name と $titleでした。
書いている人
- Puppetはペパボで6年間、複数のサービスインフラ用に書いてきた。社内で一番書いたかも
- 新規やら導入やら引き継ぎやらいろいろ
- オンプレもクラウドもある
- AnsibleはQuipperで2ヶ月ちょい。既ににあるのに書き足したりリファクタリングしたり
- 当然だけど2ヶ月ずっとそれだけやってたわけではないです
- EC2オンリー
経験値が全然違うけど、できるだけ公平に評価してみるつもり。 尚、Puppet、Ansible以外は語れるほど使ったこと無いので言及しません。
結論
- クラウド(IaaS)に
Configuration Management Toolを導入したいならAnsibleがいいと思う - オンプレ、特に歴史ある複雑なシステムに対して使うならPuppet
- どんだけ慣れてたとしてもAnsibleを選択するのはドMだと思う
- Ansible超人なら大丈夫かも
普通の結論だと思う。
初期導入コストについて
これは、さんざん言われているけど、やはりエージェントレスなAnsibleの方が始めやすいと思います。Ansibleの方は最初から導入したことないけど、途中から触るようになった自分でもそう思います。
puppetは慣れててもマスターとエージェントのバージョン不整合とか認証まわりでハマることがしばしばあるので、その辺考えなくていいのはとても楽です。（あと巷で得れる情報量が…）
ただし、Ansibleの方もある程度初期の頃から、ベストプラクティスに従って設計しないと後々辛いことになるので、その辺のこととかトレンドを学習した上で始めた方がいいと思います。
学習コストについて
DSL（Ansibleのあれを単なるYAMLだと思ってはいけない）の学習コストは似たようなもんだと思います。
Ansibleの方がYAMLで簡潔に定義できていいよねぇ〜という意見を見ることが多いような気がしますが、自分はどっちかといえばAnsibleの方が癖があって馴染みにくいように感じています。
Puppetの方はまぁゆうても普通のLLぽいです。なので、多分こんか感じかなぁで書いても大体うまく行く感じがします。対してAnsibleの方は「え！マジで！それそう書くの？」みたいなことが多いです（短くは書けるので普通に書いててもGolfぽい）。
とはいえ、どちらも基本的な文法についてはすぐに慣れます。
表現力について
ここが全然違う。これについてはPuppetの圧勝だと思います。
上述したように基本的な文法で単純なリソース定義をする分には大差はないように思いますが、複雑な環境や構成を表現するにはAnsibleではきついと思います。
複雑というのは例えばこういうの
オンプレだと、こういったことは望む望まざるとにかかわらず発生します。
Ansibleにもroleの概念などは有りますが、変数のscopeがざっくりしてたり、条件分岐や依存関係の表現が分かりにくかったりして、上記のような複雑なものを綺麗にレイヤーをわけて適切に抽象化し、メンテナンス性の高い状態を維持するのは困難であろうと感じています（Puppetでも大変ではあるけど、うまく設計すれば可能）。
逆にいうと扱う対象がシンプルであればAnsibleで十分というか、コンパクトに記述できる分、全体の把握もしやすいので、Puppetより適していると思っています。
クラウドをクラウドらしくということ
上記のような複雑な状態をつくらないということです。
H/Wレイヤーの複雑性はそもそも発生しないので、いいとして、オンプレの時の感覚で単一ホストにどっちゃりいろいろつめ込んだりしないで、1ホストにつき1つのことだけをやるようにするのが肝要かと思います。
OSについては、クラウドでもいつかは切り替える日が来ますが、マシン調達のためのリードタイムが無いに等しいので、オンプレのように長い期間をかけてOSをリプレースせざるを得ないといった理由で複数のOSが混在するという状況は避けやすいと思います。
構成管理ツールの方では複数のOSに対応させるような書き方は最初から諦めて、切り替えのタイミングでそれように全部新たに書いてしまったほうが安上がりです。古い環境はすっぱり捨ててしまえばよい。
以上、文字ばかりのこのエントリをここまで読んでいただきありがとうございました。
お前のAnsible評価は間違っておるぞ。という方、突っ込お待ちしています。
明日はあの人です。
