デプロイツール比較 CapistranoとFabric

by @dekokun on 2013/05/21 23:46

Tagged as: Capistrano, Fabric.

最近、Fabric, Capistranoと立て続けに2種類のデプロイツールを使ってデプロイ環境を構築する機会がありましたので、その際に感じた両者の利点を書いてみたいと思います。

両者の簡単な解説

そもそもCapistrano, Fabricについて、「片方は知っているけど片方は知らないよ」という人がいるかと思いますので、簡単な説明をします。

両方とも何かを知らない人は…「自動デプロイ」とかそのあたりで検索してみるといいんじゃないですかね。

Capistranoとは

Ruby製のFabricみたいなものです

Fabricとは

Python製のCapistranoみたいなものです

Fabricは私の中ではデプロイツールという認識なのですが、最近Chefと比較されることが多い気がします。Cuisineの登場によって冪等性を保証した操作もできるようになったからでしょうか。

個人的には、Chefと比較されるべきPythonツールはAnsibleなのではないかという気がしていますが、どうなんですかね。

Capistranoの利点

  • デフォルトのデプロイタスクが存在する
    • これはRails使いにはたまりませんね。ほんの少し設定を行うだけでRailsのデプロイが可能になります
    • Railsにかぎらず、設定を適切にすればPHPなど多言語のデプロイにも使えますしね
    • Capistranoのデフォルトのデプロイタスクで私は「シンボリックリンクを使用したデプロイ」という概念を初めて知り感動したのでした
    • デフォルトのデプロイタスクを使わない場合も、デフォルトのデプロイタスクはデプロイタスクを書く上で非常に参考になりますね
  • 日本語のドキュメントが多い
    • やはり、日本はPythonよりRubyのほうが強いイメージがありますね
    • 最近、VagrantやChefなどのRubyツールの勢い強いですよね
    • 私はPython製のAnsible, Fabricを陰ながら応援しています。今年はへび年ですしね
  • ストリームが簡単に扱える
    • ごめんなさい、こちら、CapistranoだけではなくFabricのほうでも普通にrun関数で実施可能でした
    • Capistranoはstreamメソッドで簡単にtail -fの結果を一箇所で見たりすることが可能ですよね
    • Fabricで同様のことを行いたい場合はどうすればいいんでしょうか。私が方法を知らないだけですかね…
    • デプロイツールという意味ではこの機能は不要ですが、せっかくデプロイツールで大量のサーバに対して色々できる環境が整ったのであれば、デプロイ以外でも使うべきですよね
  • 全体的に細かい機能が充実している
    • cap shellとかすごく便利ですよね
    • 便利な機能が多すぎて迷ってしまうイメージはありますが

Fabricの利点

  • Capistranoとくらべて薄いフレームワークであるため動きを把握しやすい
    • テストを除いたコードの行数を比較すると、Capistranoが9000行くらいでFabricが7000行くらいでした。コード行数だけでは一概に比較できないですが…(行数に思ったより差がついてなくて驚いた)
    • Fabricのほうが圧倒的に「わかりやすい」というイメージが強いんですよね。CapistranoはDSLを提供してくれていたりデフォルトのdeployタスクがあったりして、「覚えることが多い」というイメージが強い
    • 「Capistranoを使う場合でもデフォルトdeployタスクを使わなければ分かりやすさには大差ないのでは」という話はもちろんある
  • DSLを覚えなくても普通にPythonを書く感覚で書ける
    • 「関数がタスクになるよ」「run関数使おうね」くらいを知っていればひとまず使えるイメージ
    • Capistranoは、「まず、taskでタスクを登録して…」「勝手に作られているこのデプロイタスクはなんですか」と、最初の導入の際に知るべきことが少し多い
  • CuisineによりChef的に使える
    • このあたり、話には聞くんですけども、よく知らないです
  • 世界全体ではこちらのほうが人気
    • Googleトレンドの結果をご確認ください Ruby Capistrano, Python Fabric
    • 2011年あたりからFabricがCapistranoを追い抜き、現在では圧倒的にFabricの検索数のほうが多いですね

その他感じたこと

  • Fabricのputはファイルをアップロードするのに対して、Capistranoのputは引数の文字列が中身のファイルを作成するのですね。驚きました。Capistranoでのファイルアップロードはuploadですね
  • Fabricが基本的に直列実行であるのに対してCapistranoは基本的に並列実行ですよね。まぁ、どちらも、直列/並列を切り替えることが可能ですが
    • Fabricの同時並列実行数の指定はデコレータの引数で行うのに対して、Capistranoの同時並列実行数の指定はメソッドのオプションを使うというのが、それぞれの言語っぽさがあって素敵だなと思いました。

まとめ

ちゃんと、両方ともロールが扱えたり、少し手を加えればプロダクション環境やデベロップ環境の使い分けも可能ですし、デプロイのための最低限の機能は両方共に揃っていると思います。

まぁ、PythonやRubyのプロダクトを扱っているのであればそれぞれの言語のデプロイツールを使えばいいんじゃないんですかね知らんけど。PerlだったらCinnamonもありますしね。

問題はPHPのデプロイですよ。Phingを使うためにXMLを書きたくないなという感じなのですよ(あぁ、Altaxをちゃんと触っていない私がこんなことを言っていていいのだろうか)

眠くなってきた。正直、「ハマった時にソースを読むもしくは英語で解決する能力があればFabric, 日本語でググって解決したいのであればCapistrano」とかそんな感じで適当に決めればいいんじゃないですか。

「デコレータ？よくわからんしそういう知らない言語の謎機能は使えません」とか言うバカはcapistranoを使っていればいいんじゃないですかね。

なお、以下の理由でこの記事はCapistrano推しに寄っている可能性があります

  1. 私はFabricよりもCapistranoのデプロイ構築経験のほうが多い(人生初のデプロイ自動化はCapistranoを使ったものでした)
  2. 私はPythonよりもRubyを書いた経験のほうが多い(昔はRuby大好きっ子だったのです)

あ、ちなみに現在の私はPHP書きです。

comments powered by Disqus