もともとchef serverのよる構成管理を行っていたが、よりシンプルな仕組みにしたかったのでansibleに移行した。ansibleは処理も軽く、コードも構成もシンプルで気に入っていたのだが、難しい処理を扱い始めてくると表現力に物足りなさを感じてしまった。具体的には、素のpythonを書けないことのストレスと、pythonでの構造体操作がperlやrubyに比べるとやりづらいという点。その手間も相まって、Jinja2でのtemplate定義に悩むことが多かった。 構成管理ツールでは、ohaiで取得するような複雑な構造体からデータを取り出して、レシピの中で扱うことになる。pythonの場合、複雑な構造体からデータを取り出しづらいため、Jinja2の中でもif文やloop文を駆使して取り出すことになる。それに加えて変数スコープが厳密なため、更に手間がかかってしまう。こういうことを繰り返していると徐々にansibleの魅力が薄れていき、rubyでさくさく書けるchefに気持ちが戻ってきてしまった。chefは、rubyによる構造体の操作もやりやすいし、業務で使うことも多いし。 an

自分のevernoteを見返すと3年前からchefを使っているようだ。当初からchef server構成を使っていたため、冗長化の方法に何かと頭を悩ましてきた。個人で使う分にはそれほど更新頻度は高くないので、定期的にrsyncしていれば何とかなるのだが、それでも切替のときには一旦止めてreconfigureして再起動のようなコールドスタンバイくらいしか方法がなかった。また、chef server上ではelastics searchやpostgresqlなど、多くのミドルウェアが動いてしまうため、独立ノードで使う事になってしまう。貧弱なクラウド環境での動作は性能的にイマイチなので、クラウド環境と自宅環境をopenvpnで繋いで、自宅でchef serverを動かす形を取っていた。 この構成を見直すきっかけとなったのがglusterfsを使い始めた事。glusterfsの冗長性を利用して、glusterfs上にlxcコンテナを作成、そこでchef serverを動かす事を考えた。しかし、glusterfsはfile open処理が非常に遅く、やたらとファイルにアクセスするchefの処理