ただのにっき

■ PuppetからAnsibleへ

(といっても「乗り換えノウハウ」みたいな有用な情報はない)

開発環境をさくっと作るために用意していたPuppet manifestsが、Debian Jessieのインストール時に動かなくて、読み返しても何やってるのか理解できない(笑)。やっぱりPuppetのDSLはメンテナンス性低いなぁと思い、かねてからAnsibleへの乗り換えを画策していたので実行することにした。AnsibleならWindows対応もあるので仕事でも有用だろう。

最初に(タイトルに惹かれて)「Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌」を読んだのは間違いで、ディレクトリ構成を考えるのはチュートリアルくらい済ましてからね。というか、これを読むとAnsibleにも暗部というか歪みがけっこうあって、Ansibleならきれいに書けてメンテナンス性が高いなんて思い込みは早くも崩れる。あと「Ansible チュートリアル | Ansible Tutorial in Japanese」はメンテされてないのでざっと参考にするくらい。

けっきょく公式ドキュメントがちゃんとしていて良いという各所にあるアドバイスのとおりだった。英語だけど。ドキュメントがしっかりしているのはPythonカルチャーかな。だいたい書き方がわかったら「All Modules — Ansible Documentation」をリファレンスしながら自分のPlaybooksを書けばよい。基本的にshellモジュールでざっくり手順を書いてから、冪等性を確保するように手を入れるというのがスムーズで良さそう。

こんへんで「role」はいわゆるホストの役割というよりはパッケージ単位に分割すべきだわかってきて、冒頭にあったような標準的なディレクトリ構成を作りはじめるんだけど、ベストプラクティスとされる構造はかなり大規模で複数人でメンテするような場合が対象なので、個人で使うにはオーバースペックだ。変数だってhostsファイルかトップレベルのPlaybookに書いちゃえばいい。というわけで、各ロールの下にはtasksとhandles、filesがある程度に。

あと、変数が定義されてることを前提に書かれているtaskが、変数定義がない場合に失敗するようにしたいなぁと思ってやり方を探すも、なんだかスマートな手法が見つからず悩んでいたら、error_on_undefined_varsという変数をTrueにしておくと勝手にチェックしてくれると教えてもらう。試してみたらちゃんと失敗してくれるのでこれでいいやと安心していたら、そもそもerror_on_undefined_varsはデフォルトでTrueだとわかってずっこけた。つまり最初に失敗するテストを書けってことですよ、とほほ。