Subscribed unsubscribe Subscribe Subscribe

Chefのあれこれ #pfcasual

昨日Provisioning Frameworks Casual Talks vol.1というイベントに参加した。イベントの内容はスライドも上がってるだろうし割愛して、今の状況や思うことなどを書いてみよう。

前提として、現職での管理対象のサーバは少なくて仮想サーバを含めてせいぜい40台程度。各人が使う開発マシンとバッチ処理が走っているマシンが半々くらい。残りは雑多な用途とproductionが数台。web系の会社と比べると極端にproductionサーバが少ないと思う。僕が入社するまではお手製のセットアップスクリプトで諸々の設定をしていたようだ。

chef-solo vs. chef-server

サーバ台数はさほど多くないがchef-serverを使っていて、chef-clientを常時起動させて30分ごとにsyncするようにしている。productionサーバについてはかなり慎重に設定する必要があるのと台数が少ないのでchef-soloを使って手動で1台ずつ反映している。

この構成を選んだ理由は幾つかある。

  • 前職でchef-serverを使っていたので扱いに慣れている
  • いわゆる「サーバ管理ツール」を持ってないので、chef-serverのweb UIがあると便利
  • 一部のサーバがとても遅いVPN接続の向こうにあるので、手動でのデプロイ作業は時間がかかってストレスフル
  • production以外のサーバは、事故が起きてもまあクリティカルではない

良く言われるセットアップの手間は、Ubuntuを使っていれば公式apt repositoryが使えるため苦にならない。chef-serverのweb UIはお世辞にも使いやすいとはいえないけれども、使えないほど悪くない。

逆に悪い点は、常時起動しているchef-clientの品質があまりよくなさそうなこと。突然死していることがよくあるし、メモリリークしているのか知らないがresidentで1 GB使っていることがよくある。たいていのマシンでは1 GB余分に使われても大丈夫なくらいメモリを積んでいるけど、メモリ割り当ての少ない仮想ホストでは悲しい。カジュアルに再起動しましょうということなんだろうか。

もう一つ思い出した。chef-serverの冗長化はしてないが壊れても悲惨なことにはならないので、作り直せばいいかなと思っている。

テスト

chef-server + chef-client常時起動だとテストが大事になるのだけど、これがあまりできていない。現状でやっているのはJenkinsでknife cookbook testを回しているのと、environmentsを使ってproductionとdevelopmentに分けてdevelopmentで確認する程度。なんどかdata bagsがenvironmentsごとに分かれて無くて嵌った気もする。

一月ほど前にtest-kitchenを試してみたのだけど、READMEの通りでは動かなくて調べる時間が無くて放置している。タイムラインを見る限りちゃんと使っている人が居るようなので、また時間を取って試してみたい。

serverspecについては単体では良さそうに見えた。Chefと組み合わせることについての是非は純正ツールと比較してみないとちょっとわからないなという印象。

Chef vs. Puppet

Puppetは前職で数年前に少しだけ使っていた。id:antipopさんは外部DSL・内部DSLはあんまり関係ないと仰っていたけど、当時は個人的にはそこが一番クリティカルだった。文法自体はもちろん文法エラーもわかりにくい、言語の自由度が低いなど。詳しく覚えてないし、今は改善されているのかもしれない。

今でこそprovisioning frameworkはidempotencyが命だ!と叫ばれているけど、当時PuppetはdeclarativeでChefはimperativeみたいな風潮があったのは、この制限された文法によるところが大きかったのではとも思う。もちろん制限がきつすぎるとexecの嵐になって単なるシェルスクリプトになってしまうんだけど。

結論は特にない。楽できそうな方を使えば良いんじゃないかと思う。

良かったところメモ

イベントで新しく知ったことをメモ。

事前登録なしについて

最後に登録なしのイベントについては、僕はいいんじゃないかなと思いました。主催者の負担を少なくして継続開催するのが開催側・参加者側双方にとっていいという理由です。