あーありがち

過去の日記 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ RotationMaker を作った

最近は iCal づいています。

/lang/ruby/misc/rotation-maker – CodeRepos::Share – Trac

これは何か？

README より抜粋

• 例えば毎週月曜に何かやります
• メンバーが 5人いて担当は 2人ずつとします
• いつ誰が担当するのか先々の予定を算出したい
• ハッピーマンデーがあるので、その場合は火曜にスライド

みたいなときに便利かもしれないツールです。

使い方

オプションを与えずに起動するとなんとなく分かります。たぶん。

$ ruby rotation-maker.rb 
Usage: rotation-maker [options]
    -x, --exclude DATE
        --exclude-from-ical ICS
        --exclude-from-file FILE
        --exmethod [METHOD]
    -s, --dtstart DATE
    -e, --dtend DATE
    -i, --interval INTERVAL
    -d, --date EVENT DATE
        --date-from-ical ICS
        --date-from-file FILE 
    -m, --member MEMBER
        --member-from-file FILE
    -a, --atonce NUMBER
    -y, --yaml FILE

最低限必要なものは

• date
• member

です。-d や -m を複数書いてもいいですが、それぞれ1行1アイテム形式のファイルから読み込ませることもできます。

また、date ではなく -s START, -e END, -i INTERVAL でくり返しの予定を記述することもできます。INTERVAL は基本的に整数ですが、activesupport をインストールしてあれば week, month, year も指定できます。

exclude で除外する日付を指定します。デフォルトでは除外日に予定が当たったらその日はスキップします。exmethod オプションに backload を与えていたら次の日にずらします。次の日も除外日だったら除外日でなくなるまでスライドします。*1

あ、今気づいたけど slide オプションは YAML からしか与えられないじゃないか。後で直します。

YAML で設定を書く場合はこんな感じで書きます。

dtstart: '2008-12-01'
dtend: '2009-03-31'
interval: week
atonce: 2
exmethod: backload
members:
  - abc
  - def
  - ghi
  - jkl
  - mno
  - pqr
  - stu
excludes:
  # PATH or URI
  ical: http://www.google.com/calendar/ical/japanese%40holiday.calendar.google.com/public/basic.ics

出力部分は自分で書いてください^^;

例えばこんな感じのものを用意すると iCal 形式で予定を吐き出せます。

#! /usr/bin/env ruby
# -*- coding: utf-8 -*-

require File.dirname( __FILE__ ) + '/rotation-maker'
require 'erb'
require 'nkf'

def main
  rot = RotationMaker.new.run
  puts NKF::nkf( '-w -Lw', ERB.new( template, nil, '-' ).result( binding ) )
end

def serialized_time( time )
  return time.gsub( /-/, '' )
end

def template
  return <<EOD
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
X-LIC-LOCATION:Asia/Tokyo
BEGIN:STANDARD
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:JST
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
<%- rot.each do |r| -%>
BEGIN:VEVENT
SUMMARY:社内勉強会
DESCRIPTION:発表 <%= r['member'].join( ', ' ) %>
DTSTART;TZID=Asia/Tokyo:<%= serialized_time( r['date'] ) %>T180000
DTEND;TZID=Asia/Tokyo:<%= serialized_time( r['date'] ) %>T190000
END:VEVENT
<%- end -%>
END:VCALENDAR
EOD
end

main

結果はこんな感じ。

あ。あれ？ Google Calendar にある Japanese Holidays の成人の日の情報が

DTSTART;VALUE=DATE:20090112
DTEND;VALUE=DATE:20090113
DTSTAMP:20081203T115909Z

になってますね。見た目は 12日だけに見えるんだけど。えーまぁ、これはデータの問題ということで。

問題というか

iCal の Rrule *2って、くり返しの終了が指定されていない場合、無限に続いてしまいますよね？ これをどう扱ったらいいのかが全然分かっていません。今回、除外日を設定できるようにしたため、除外日を Array にして Array#include? でチェックしているのですが、Array で無限なんて扱えないですよね。

実際には Vpim::Icalendar がイベントの日時情報を DateTime ではなく Time で扱っているため、2037年問題に引っかかって有限の配列を取得することができているのですが、本当に無限のものを扱いたい場合は全部を計算で扱う Array 以外の何かが必要になるんじゃないかと思っています。とにかく動くものを作りたかったのでその辺突っ込んで調べてませんが。

またこのため Time の ArgumentError を rescue してそのまま知らん顔するという暴挙に出ています。こんなんじゃいかんよなぁ。limit を設けるようにした方がいいのか、Icalendar に戻した方がいいのか。Icalendar は DateTime で扱っているので少なくとも 2037年問題には引っかからなそうなのですが。Icalendar にこの include?( date ) みたいな便利メソッドがあれば Array に展開することなく処理を続けられるのかな。ただ、実際にはどこかで区切らないと処理が終わらないのでどっちみち limit は要るのか。

Icalendar は Icalendar で to_ical がマルチバイト文字列をぶった切る問題があるしなぁ。ふーむ悩ましい。

何かご存知の方はツッコミください。

TODO とか

• slide オプションをコマンドラインからも与えられるようにする
• slide オプションで予定の前倒しもできるようにする
• 土日を除外するのはもっと簡単にできてもいいような気がする

げ。

*atonce をコマンドラインから与えられるようにする＞＜

参考

• http://icalendar.rubyforge.org/
• vPim - vCard and iCalendar support for Ruby
• RFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)

2008-12-04 追記

前のエントリのツールも一緒に checkout できるようにしました。手軽に cat できるなら月水金カレンダーとかでも割とすぐ作れるので、こっちで頑張りすぎる必要ないかなぁという気がしてきました。

_ CGI を rackup してみた

Ruby は自分の大好きな言語だが、実は長く運用する Web アプリを Ruby で書いたことはない。cgi.rb の評判はずいぶん前から芳しくないし、決定打となるフレームワークの不在が長く続いたこと、すでに PHP を使っていたことが大きな理由だった。

Rails が登場した。勉強した。「うーん、なんか DBMS とか要らないんだけど、どうしたらいいのよ？」と思っているうちに世間ではすっかり定着、代わりに自分の中では興味は薄れていった。そうこうしているうちに Rails の問題点もちょこちょこ指摘されるようになり、prototype.js とともに先駆者ゆえの苦難を味わっているなぁと感じている今日この頃。

Merb だなんだと言われていた中、Rack が登場した。これだ！と思った。こういうシンプルなやつが欲しかったんだよ！　しかしそれから特に何の理由もないまま一年半の月日が流れた。なんかこんなんばっかだな。RSS の登場により情報の収集は速くなったけど、知識にするための時間、手を動かして「つかむ」までの時間は、自分という人間の性能が変わらない*1のでちっとも短くならない。

そんなオレ語りはどうでもよく、今回はようやく自分で Rack を使ってみましたよというお話。しかも、あんまり見ない、WEBrick と CGI の二本立て。試したのは gem で入れた rack 0.4.0

Rack の使い方は二段階ある

超簡単なチュートリアルを読んでもリファレンスを見てもこの違いを明確に意識することができなくて苦労した。Rack の機能には以下の二段階がある。

1. Handler によってアプリケーションサーバの違いを抽象化する
2. rackup によって便利なミドルウェアを使う

この違いは

• ruby から直接 Rack::Handler::FOO.run( App.new )
• rackup から run( App.new )

の違いからくる。要するに

ミドルウェアを use したければ rackup しろ

ってこと。

逆に言うと rackup しなくても Request, Response の抽象化は行えるので基本的なことはできる。

ではそれぞれの方法をもう少し詳しく見てみる。

※ ブコメいただきました。ミドルウェアの中にアプリケーションを突っ込んで、ミドルウェアを Handler に渡すという方法もあるようです。なんかちょっと不思議な感じもしますが、そもそも内部ではミドルウェアでアプリケーションを再帰的に wrap する構造のようです。

lib/rack/lobster.rb at master from chneukirchen's rack ― GitHub

ruby から直接 Handler を呼ぶ方法

WEBrick の例

komagata さんの記事から拝借。

ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす

#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
 
class HelloRack
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
  end
end
 
Rack::Handler::WEBrick.run HelloRack.new, :Port => 3000

この hello-rack.rb を

ruby hello-rack.rb

で起こし、これにブラウザからアクセスすると

Hello, Rack

と表示される。うむ。

CGI の例

同じことは CGI でも当然できる。

#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
 
class HelloRack
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
  end
end
 
Rack::Handler::CGI.run HelloRack.new

こんな感じで Handler を CGI にしてやれば ok. これを

• Web サーバ配下の CGI の実行可能なディレクトリに置いて
• 実行権限を付けて

ブラウザからアクセスしてやるとさっきと同じように

Hello, Rack

と表示される。めでたしめでたし。

これで cgi.rb を使わなくても Ruby で CGI を書けるようになったよ！

（CGIAlt があるとか言わないでね。）

気をつけなきゃいけないこと

以下は自分のためのメモ

• CGI の場合は Web サーバがアプリケーションを勝手に起こしてくれるけど、実行権限の付与が必要
• WEBrick（など）の場合は自分でアプリを起こしてやらないといけない

自分の場合は生 CGI を触る機会が減っているので実行権限の付与をしょっちゅう忘れる。

でも Rack の本当の威力を味わうなら rackup

rackup は

rackup -s webrick [config file]

などとして server(handler) を指定してアプリケーションサーバを起動する。rackup が行われると、中で

Rack::Builder

がアプリケーションサーバの環境を作ってくれ、自分の書いたアプリケーションはこの中で実行される。

ここで初めて use が使えるようになる。

もうちょっと細かく見てみよう。

use は Rack::Builder の instance_method

Rack でミドルウェアを追加する use は Rack::Builder の instance_method となっている。

irb(main):001:0> require 'rack'
=> true
irb(main):002:0> Rack::Builder.methods.grep( /use/ )
=> []
irb(main):003:0> Rack::Builder.instance_methods.grep( /use/ )
=> ["use"]

つまり

require 'rack'

しただけでは use は使えない。

rackup の流れ

rackup を読んでみると、アプリケーションは rackup の中で以下のように実行されている。（詳細は端折ってある）

Rack::Builder.new {
  run inner_app
}

つまりそういうこと。Rack の便利機能を使いたければ rackup すべし。

では実際に rackup してみる。

WEBrick の例

直接起動で use の使えない様子

さきほどの hello-rack.rb に use を加える。

#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
 
use Rack::ShowExceptions

class HelloRack
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
  end
end
 
Rack::Handler.WEBrick.run HelloRack.new, :Port => 3000

すると、当然ながら

$ ruby hello-rack.rb
hello-rack.rb:6: undefined method `use' for main:Object (NoMethodError)

怒られる。use なんて使えない。

rackup してみる

#! /usr/bin/env ruby
require 'rubygems'
require 'rack'

use Rack::ShowExceptions

class HelloRack
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
    cho_www
  end
end

run HelloRack.new

ここで注目してほしいのは、

• cho_www という syntax error をアプリケーションの中に仕込んであるところ
• run の呼び方を変えたところ

どうも

rackup するときは Handler は外から（rackup の -s オプションで）指定してあげた方がなんかうまくいく感じ。

これを hello-rack.ru の名前で保存し、

rackup -s webrick -p 3000 hello-rack.ru

で実行。

ご覧のようにブラウザ上に Exception を表示できる。画像では端折ってあるが TraceBack も表示できる。当然のことながら cho_www を削除すれば普通に動く。

CGI の例

直接起こして use してダメなのはさっき WEBrick で見たので省略。

rackup する

ru ファイルはさっき用意した hello-rack.ru をそのまま利用。CGI の方は以下のようにする。

#! /bin/sh

/opt/local/bin/rackup hello-rack.ru

パスが /opt/local/bin なのは MacPorts で入れた Ruby で gem を使ってインストールしているから。rackup のパスは適宜調整すること。

これを hello-rack.cgi の名前で保存、ごにょごにょしてブラウザからアクセスしてみる。画像の中の URL の違いに注目。確かに CGI で動いている。

ただし、当然のことながら CGI で rackup するのは負荷的には不利。

従来の流れ

1. shebang から Ruby を起動
2. 自分自身を読み込ませる

rackup 時の流れ

1. shebang で sh や他のインタプリタから
2. rackup コマンドを呼び出し
3. そこから ruby が呼ばれ
4. アプリケーションがロードされる

という長い道のりを要するようになってしまう。でもメリットでかいし。

わざわざ別プロセスの rackup から起動しなくてもいんじゃね？と思いたいのは分かる。自分も思った。でも結局 rackup と同じとまではいかないまでも似たような流れで Rack::Builder を呼んであげなきゃいけないので、Rack に頼るうまみが薄れちゃうよね？と思うのでそういうことはしないことにした。

まとめ

何はともあれ、Rack の基本的な使い方は分かった。map とかは分かってないけど、これで

1. WEBrick で開発
2. とりあえず CGI で deploy
3. 負荷的にまずいので FastCGI にしましょうか

といった柔軟な運用が可能になった。

よしよし。

参考

• KoshigoeBLOG: Rack解説を試みて失敗しつつも晒す、の巻
• Greenbear Laboratory - Rack日本語リファレンス
• Rackを読むのまとめ - I am Cruby!

• dmsolutions blog » WSGI ことはじめ

• 満足せる豚。眠たげなポチ。:CGI から Mongrel まで、Rack で Web アプリを Web サーバから抽象化する
• ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす

_ Capistrano は思ったよりシンプルで思ったよりすごい

システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な（らしい）Capistrano についてです。紹介？ いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。

Capistrano: Home

システム管理の話なのになんで Puppet じゃないの？と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。

で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない？と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。

なお、例によって嘘書いてる可能性があります。識者のツッコミお待ちしております。

Capistrano の動作に必要なのは Ruby と ssh だけ

• Puppet は daemon をいくつか用意してやる必要があります。
  • https を使ってくれるので fw friendly ですが、それにしたっていろいろ準備が必要です。
• Capistrano の準備で大事なのは以下の2点だけ。
  • Capistrano*1 をセットアップする1台のマシン
  • 管理される方のマシンには sshd と作業用の ssh アカウント

しかも Puppet と違い C/S 方式ではないため、Capistrano のセットアップが必要なマシンは1台だけです。

なんか、ちょっとお手軽な感じがしませんか。

Capistrano 自体は Windows でも動く

依存している gem パッケージは以下の通り。

$ gem dependency capistrano
Gem capistrano-2.5.3
  net-ssh (>= 2.0.0, runtime)
  net-sftp (>= 2.0.0, runtime)
  net-scp (>= 1.0.0, runtime)
  net-ssh-gateway (>= 1.0.0, runtime)
  highline (>= 0, runtime)
  echoe (>= 0, runtime)

あと echoe がこんな感じ。*2

$ gem dependency echoe
Gem echoe-3.0.2
  rake (>= 0, runtime)
  rubyforge (>= 1.0.0, runtime)
  highline (>= 0, runtime)

ext なライブラリはないので Capistrano 自体は Windows でも動かせます。*3自分で実際に確認はしてないですけど、動かしている例は探せばすぐ見つかります。

ただ管理対象は ssh でなんでもできる Un*x 系システムじゃないと Capistrano の利用に旨味はないでしょう。

要するにできることは ssh HOST COMMAND

ssh は interactive な login shell を提供するだけではなく、

ssh HOST COMMAND

の形で

HOST に接続して COMMAND に書かれた処理を実行して終了する

という使い方もできます。大雑把に言うと Capistrano はこの機能をより便利に使うために

• 接続先の管理と接続の自動化
• 接続先と作業内容のセットをタスクで管理
• タスクの実行

を提供してくれるものです。そして

そのために Rake を使う

ようになっています。

deploy ツールとして紹介されることの多い Capistrano ですが、それは deploy 用のタスクがあらかじめ定義されていて、変数をセットするだけで便利に使えるようにしてあるからであって、

タスクを用意すれば ssh でできる仕事はなんでもできます。

たぶん。

ただし、Puppet と違い、接続先のサーバ OS の抽象化などは行ってくれないため、基本的にその部分は生で相手しないといけません。逆に Puppet のように独自文法の習得を要求しません。

ということは従来の方法からの移行コストが小さい

まともな管理者なら、サーバ上のたいていの作業は sh や Perl、Ruby などのスクリプトである程度自動化されていると思います。これが cron ジョブとして管理できるなら手作業はずいぶん減っているはずです。ただ、

完全に定期実行になっていない作業

も中にはあるでしょう。その場合、しぶしぶ個々のサーバにログインしてスクリプトを実行していませんか？ 恥ずかしながら自分はそうです。しかし Capistrano を導入すれば

最後の「ログイン -> 実行」の部分を自動化、管理できます。

そうです。個々のサーバの管理方法を大幅に変える必要はありません。「ログイン -> 実行」という、最後に残った手作業部分を Capistrano のタスクとして管理できるようになるだけなのです。しかもサーバ側は基本的にいじる必要がありません。

これが複数のサーバ上の作業なら目に見えて楽になりますし、サーバの数がそれほど多くなくても

一定のワークフローを保証しやすくなります。

つまり

管理作業の共有、引き継ぎを楽にしてくれます。

もちろん独自タスクの管理のためには Ruby と Rake への理解を要求するので、楽になる一方ではありません。しかも Rake も Capistrano もそんなにドキュメントが充実しているわけでもありません。しかし、スクリプトを書いて自動化して、手作業によるミスを減らせるようにしてあるはずなのに、なんとなく属人的な作業が残っちゃう部分があって、なんか気持ち悪いなぁと感じているような場合には Capistrano の導入は十分に検討の価値があるんじゃないでしょうか。

超簡単な例

えーと概念の話からインストールの方法をすっ飛ばしていきなり実例に入ります。*4

カレントディレクトリに以下のような内容で Capfile という名前のファイルを作ってください。ここでログイン先のサーバのユーザー名、パスワードは一致しているものとします。

role :server, 'server1, 'server2'

set :user, 'user'
set :password, 'password'

desc "reporting disk usage with 'df -h'"
task :check_disk, :roles => :server do
  run 'df -h'
end

で

cap check_disk

と実行すると

 * executing `check_disk'
 * executing "df -h"
   servers: ["server1", "server2"]
   [server1] executing command
   [server2] executing command
** [out :: server1] Filesystem            Size  Used Avail Use% Mounted on
** [out :: server1] /dev/xvda1             32G   24G  7.2G  77% /
** [out :: server1] tmpfs                 201M     0  201M   0% /dev/shm
** [out :: server2] Filesystem            Size  Used Avail Use% Mounted on
** [out :: server2] /dev/mapper/XXX        17G   14G  2.1G  88% /
** [out :: server2] /dev/xvda1             99M   27M   67M  29% /boot
** [out :: server2] tmpfs                 181M     0  181M   0% /dev/shm
   command finished

みたいな結果が得られます。つまり、server1, server2 にログインして実際に df -h した結果をそのまま、Capistrano をインストールしたマシン上で確認できたということです。

どうです、なかなか面白くないですか。

情報収集が楽になるはず

これはちょっといきすぎてるかな？と思わなくもないのですが、cron ジョブの実行を Capistrano マシンに集中させることも可能ですね。こうすると

• 個々のサーバで crond が不要
• cron ジョブのレポートメールを Capistrano マシン上に集約可能
• cron ジョブの様子を一カ所で確認できるので、スケジュールを考えやすくなる

というメリットがあります。もちろんデメリットや不安材料もあって、

• ssh login のコスト
• 長い時間掛かる仕事をさせたときの ssh connection はどうなる？

なんかが気になるところです。まだ見落としてることもあるかもしれません。

cron のレポートの受け取りが面倒くさい

ただ、cron はレポートのメールの受け取りが面倒だなと以前から感じていたので、この問題を解決しやすくなるとしたらとても嬉しいです。というのも、cron のレポートは基本的にローカルのアカウントにメールされるのですが、

どうやって読むの？

という問題がつきまといます。今思いつくのは

1. 個々のサーバにログインして読む
2. 個々のサーバに POP サーバ立てる
3. forward する
4. mail -> html -> feed 変換して feed reader で読む

くらいですかね。数が増えてくれば当然 1, 2 はナシだと思うんですが、

forward する場合、forward 先のサーバには SMTP サーバと SMTP の通る穴が必要

になります。これがまた悩ましい。メールサーバが LAN 内にあるなら LAN 内のレポートは文句なし LAN 内のメールサーバで処理すればいいです。でもインターネット向けに公開しているサーバのメールはどうしましょう？ LAN 内のサーバ向けに forward ？ fw で閉じてませんか？ じゃあインターネット上の SMTP サーバに転送？ OBP25 とかに引っかかりませんか？ それにインターネット上に置いた SMTP サーバはあっという間に spam やエラーメールの嵐に飲み込まれてしまいます。すると今度は spam filter だ anti virus だ…。ふー。違うんだよ、オレはそんなことしたいんじゃないの。要するに

forward も意外に面倒なのです。

もう一つ、メールったってこんなの返信の必要もないし、みんな feed reader で読みたいなぁと以前から思っていました。実際、mail -> html -> feed 変換をしている人は見かけます。HTML にして URI が付けば内容の共有も楽です。*5しかしどうしても転送の部分がネックになります。各サーバで feed 吐いてそれpla で収集してもいいですけど、なんかそれもどうなんだと。

でも Capistrano からタスクを実行すれば、自動的に、少なくとも stdout や stderr の内容は取得できます。結果をファイルに落とすタイプでもファイルの転送が可能*6なのでそれを取得してくればオッケーです。

てことは、レポートの収集の部分は自動的にクリアしてしまいます。おう、なんかこれ面白そうじゃん。

できそうなことの一覧

クラスの一覧から一部を抜粋。

Capistrano::Configuration
Capistrano::Configuration::Actions
Capistrano::Configuration::Actions::FileTransfer
Capistrano::Configuration::Actions::Inspect
Capistrano::Configuration::Actions::Invocation
Capistrano::Configuration::Actions::Invocation::ClassMethods
Capistrano::Configuration::Callbacks
Capistrano::Configuration::Connections
Capistrano::Configuration::Execution
Capistrano::Configuration::Loading
Capistrano::Configuration::Loading::ClassMethods
Capistrano::Configuration::Namespaces
Capistrano::Configuration::Namespaces::Namespace
Capistrano::Configuration::Roles
Capistrano::Configuration::Servers
Capistrano::Configuration::Variables
Capistrano::Deploy
Capistrano::Deploy::Dependencies
Capistrano::Deploy::LocalDependency
Capistrano::Deploy::RemoteDependency
Capistrano::Deploy::SCM
Capistrano::Deploy::SCM::Accurev
Capistrano::Deploy::SCM::Accurev::InternalRevision
Capistrano::Deploy::SCM::Base
Capistrano::Deploy::SCM::Base::LocalProxy
Capistrano::Deploy::SCM::Bzr
Capistrano::Deploy::SCM::Cvs
Capistrano::Deploy::SCM::Darcs
Capistrano::Deploy::SCM::Git
Capistrano::Deploy::SCM::Mercurial
Capistrano::Deploy::SCM::None
Capistrano::Deploy::SCM::Perforce
Capistrano::Deploy::SCM::Subversion
Capistrano::Deploy::Strategy
Capistrano::Deploy::Strategy::Base
Capistrano::Deploy::Strategy::Checkout
Capistrano::Deploy::Strategy::Copy
Capistrano::Deploy::Strategy::Export
Capistrano::Deploy::Strategy::Remote
Capistrano::Deploy::Strategy::RemoteCache

いやーこうして見ると Deploy の充実っぷりがやはりすごいですね。Mercurial や Bzr なんて文字も見えるので、これらを使った deploy もできるんでしょう。

使えそうなリソース

Capistrano 自体が github でホスティングされているためか、github で検索するといちばんたくさん引っかかるようです。

• Capistrano 入門 - Ruby on Rails with OIAX
  • まとまって日本語で読めるのってこれくらい？

あとはシステム管理系のレシピが載ってそうなところとか。まだあんまちゃんと見てないですけど。

• deprec - Trac
• sauliusgrigaitis's centostrano at master ― GitHub
• → ‘capitate’: Capistrano recipes, plugins and templates.
• vigetlabs's capistrano_rsync_with_remote_cache at master ― GitHub
• capistrano-mailer - Google Code

• Capistrano 2.1向けのAPTレシピ : \ay diary
• Andrew Beacock's Blog: A Capistrano recipe for restarting Apache 2 (on Linux)
• CapistranoでタスクをDRY化したいときは Capistrano.plugin が便利 - 半隠遁日記

最後に。

みんな、実際に試してオラにやり方を教えてくれ！