Ansibleを使い始めていた

Chefも引き続き使っているが、新しく始めるプロジェクトではAnsibleを積極的に使っている。昨年末くらいから。
AnsibleはChefに比べて基礎がシンプルなところがいいなと。

レシピをRubyでごりごり書いて何でもできるみたいな自由さはないけれど、中小規模なインフラを管理するにはYAMLで十分だし、ベストプラクティスに従えばプレイブックが雑多なカオスになることもない。
ベストプラクティスに関しては結局Chefと同じく色々覚えるのが面倒なんじゃないかと最初は思っていたけど、試してみるとそんなにややこしくもなく。

あと気に入っているのは複数サーバーやマルチステージ(production,staging等の環境)を管理できる機能が標準で付いているところ。

ちなみにAnsibleにもChefのコミュニティクックブックのように他人が書いたプレイブックをパッケージのように使えるAnsible Galaxyという仕組みがあるが、これはChefでサードパーティのクックブックを使って痛い目を見た経験から参考にするにとどめている。
Chefに疲れたのもだいたいサードパーティ製のクックブックを使ってにっちもさっちもいかなくなったからだったりするので。

加えて今考えると学習コストがかかるようなクックブックをがんばって使っていたのはナンセンスで、準備した各種設定ファイルを設置するだけのシンプルなものがあればよかった。変数から設定ファイルを組み立てるようなクックブックがあるけど、項目が多くなりすぎるとクックブック自体の学習コストが発生するので、そういう羽目に陥るなら絶対に設定ファイルを直接書いた方がいい。

テンプレートは使うけど、そういう行き過ぎた汎用性のためではなくて、ステージングとプロダクション環境で微妙に変数を変えたりとか、そういう単純な用途に。少しのフラグがあって分岐するだけ。
学習コストが発生するクックブックやプレイブックはイカン。自分で作っても時間経つと忘れちゃうしね。

とりあえず必要なところだけを都度ベタに作るかんじで、Debian系とRHEL系で同じプレイブックを使えるように、なんて面倒なことはしない。使い回せるようなものを作るのは三回同じ処理を書いたら考える。そんな風に徐々に育てていけば良い。

まあChefやAnsibleを使うよりいいのは自分でサーバーをセットアップしないことだけどね。
Herokuも東京リージョン使えるようになったことだし。シビアなインフラでなければそれで十分なはず。であってほしい。

前の記事

CircleCIからデプロイする云々

次の記事

iPad Pro 12.9インチ雑感