僕が chef-server を使わない理由

昨日、chef 系の記事をちゃんと書いていこうと思ったので、
さっそく一本書いてみようかと思います。

chef に関して、いろんな人と話したり、ブログで見聞きしていると、みんな chef-server でハマっているようです。
chef-server は、最近リリースされた erchef によって構成がシンプルになったものの、
それでもインストールにはちょっと手間がかかるシロモノです。
僕も erchef 登場以前に試そうとして、セットアップの面倒さにげんなりした覚えがあります。
追記(3/13 15:00): @sawanoboly さんにこんな指摘をもらいました。chef-server にも omnibus installer があるようです！


現在、僕は chef-server は使わず、chef-solo のみで環境構築をしています。
インストールが面倒というものも理由にあるのですが、他にも chef-solo を選んだ理由はいくつかあります。
ここではその理由を書いてみようと思います。

サーバ群の規模が小さい

僕がやっているお仕事は、3〜5台ぐらいのサーバが対象となっていることが多いです。
Web兼アプリケーションサーバが 2台、DB サーバが 2台(Master/Slave)のような構成で済んでしまうものが多いです。
ステージング環境が追加されても +1,2台の範囲です。
また、いわゆるクラウド環境ではないためオートスケーリングもほとんど必要とされていません。

そのため、ここにセットアップ用の chef-server を用いるのはオーバースペックだと感じます。
サーバ台数が 20台未満の場合は chef-solo でも十分と人づてで聞いたことがあるので、
あまり chef-server を導入するモチベーションになりません。

拠点(ネットワーク)がわかれている

本番系の環境はともかく、開発環境はいくつか作ったりします。
大抵、プロジェクトの参加人数分に加えて、Jenkins 用と結合用(レビュー用)環境ぐらいは環境を作るので、
プロジェクトによるものの 5〜10台ぐらい作ることになります。

本番環境と合わせるとそれなりの台数になるので、今度こそ chef-server を使うチャンス！と考えたくなるのですが、
開発環境(社内)と本番環境(IDC)ではネットワークがわかれており、VPN 等で接続されていないケースがほとんどです。
そのため、ネットワークをまたがって chef-server を利用するのが難しく、
また開発環境のために独立した chef-server を立てるのも台数からモチベーションになりません。

プロジェクトがわかれている

SI っぽいお仕事をしているので、社内ではいくつもの開発プロジェクトが並行して動いています。
プロジェクトをまたがって chef-server を共有すればいいんじゃない? と考えたことがあるのですが、
プロジェクト A がアップロードした cookbook が、プロジェクト B へ影響を与えるのがよいことなのか判断しきれませんでした。

OS の distro. もバージョンも違うこともありますし、保守フェーズになってあまり手をかけないプロジェクトもあります。
そうしたときに、プロジェクトを横断して chef-server を共有して幸せになれるかというと、
不要なトラブルを起こす可能性がありそうに見えたのでこの部分でも chef-server は採用できませんでした。

もしかすると、今は複数のプロジェクトで共有しやすいよう、複数バージョンの cookbook を管理したりできるかもしれません。
ここが改善するとモチベーションになりうるかもしれません。

追記(3/13 14:40): @sawanoboly さんにこんな指摘をもらいました。Environments は便利かもしれません。

保守フェーズのプロジェクトの扱い

手がけているプロジェクトには保守フェーズに入っており、トラブルが起きた時だけ手を動かすようなものもあります。
こうしたシステムの場合、システムを更新するのはセキュリティフィックスが発見された場合になるので、
あとから chef を導入してもコストに見合いません。
こうしたプロジェクトの場合は、既に構築されたサーバ/システムをメンテナンスすることに注力されるので、
chef-server にかぎらず chef-solo も導入されません*1。

chef-solo をリモート実行する要素が揃っている

これまでいくつかのエントリの端々で紹介した roundsman を利用すると capistrano を介して
chef-solo をリモート実行することができます。
対象サーバが複数でもカバーすることができますし、role を定義してサーバごとにセットアップ内容を調整することもできます。

capistrano と組み合わせることで、chef による環境のセットアップに加え、アプリケーションのデプロイも行うことができます。
さらに Jenkins を利用することで、一部の環境(社内の結合環境やステージングなど)を自動的にアップデートすることもできます。

まとめ

  • 台数少なかったら chef-solo でいいんじゃない?
  • たくさんプロジェクトあったら、chef-solo でいいんじゃない?
  • capistrano かわいいよ、capistrano

というわけで、僕が chef-server を使わずに chef-solo を使っている理由を紹介しました。
こんなことを考えている人もいるんだよ、必ずしも chef-server を使わなくてもいいんだよ、という参考になると幸いです。

もしかしたら、しばらくして chef-server を使っていたらあしからず :-p
chef 自身も、対応ツールも新しくなっているので、僕が考えた/遭遇している問題なんて吹き飛ばしてくれるといいんですけどねえ。

*1:もしハードウェア故障などで再構築が必要になっても、chef kitchen を作るコストと手順書を流すコストでは、吊り合わないので手動になりがちです。