thinよりlighttpdなの

nginx + thin とかやってみたけど、lighttpd + fastcgi が良い。

script/server lighttpd

とかやると、 config/lighttpd.conf が出来るので適当にいじっておく。の前に、public/dispatch.fcgi の実行パスと実行権限を書いておくのを忘れていつも1分くらい時間無駄にする私マーメイ

あとは

script/process/spawner

を使って自動監視的なことをするんだ。

rails@xxx:~/$ ruby script/process/spawner --help
Usage: spawner [options]

Description:
The spawner is a wrapper for spawn-fcgi that makes it easier to start multip le FCGI
processes running the Rails dispatcher. The spawn-fcgi command is included w ith the lighttpd
web server, but can be used with both Apache and lighttpd (and any other web server supporting
externally managed FCGI processes).

You decide a starting port (default is 8000) and the number of FCGI process instances you'd
like to run. So if you pick 9100 and 3 instances, you'll start processes on 9100, 9101, and 9102.

By setting the repeat option, you get a protection loop, which will attempt to restart any FCGI processes
that might have been exited or outright crashed.

Examples:
spawner # starts instances on 8000, 8001, and 8002
spawner -p 9100 -i 10 # starts 10 instances counting from 9100 to 9109
spawner -p 9100 -r 5 # starts 3 instances counting from 9100 to 9102 and at tempts start them every 5 seconds

Options:
-p, --port=number Starting port number (default: 8000)
-i, --instances=number Number of instances (default: 3)
-r, --repeat=seconds Repeat spawn attempts every n seconds (defa ult: off)
-e, --environment=name test|development|production (default: produ ction)
-s, --spawner=path default: /usr/bin/env spawn-fcgi
-d, --dispatcher=path default: /home/rails/radiodays/public/dispa tch.fcgi

-h, --help Show this help message.

みたいな感じなので、

script/process/spawner fcgi -p 8100 -i 2 -r 5

みたいな感じにすると、8100,8101 番ポートで FastCGI 立ち上げてくれて、5秒おきに死活監視してくれる感じになってるみたい。だけど、もしFastCGIのプロセスが落ちても、次のアクセスで自動的に立ち上がるようになってるみたいだから特に気にしなくてもいいのかな?

自前で HTTPリクエストを飛ばしてステータス見てるよりは良いのかもしれない。

FastCGIが System Exit したときのリクエストが気になる。 thin + nginx でunix のソケット経由でやったときは、1個のリクエスト中に裏の thin のプロセスを kill と、すぐ他のとこつないで 500 的なステータスは返らず正常に表示できたみたいで、そこは良かったなぁと思うのです。

で、 spawner を kill する方法がわからないので、 pid 調べて kill しています…。

Rails のソースを変更したときは、FastCGIのプロセスだけ再起動してあげればよくて、

script/process/reaper -a graceful

とやればいいんだ。

フロントは pound が安定してていい感じ。10以上のサーバで使ってるけど、まったく落ちない。そして、URLの正規表現で簡単に振り分けが出来るのが素敵だと思う。

http://ecpplus.net/weblog/linux/rails%E3%81%AEredirect_to%E3%81%A7https%E3%81%AB%E8%A1%8C%E3%81%8B%E3%81%AA%E3%81%84%E4%BB%B6with-pound/

RubyAMFはお気軽に入れるっていう感じにはならない

RubyAMFを使ってみる
Railsも然りなんだけど、RubyAMFもちょっとしたことに使おうっていう気分にはなれない。時間にしたらRubyAMFの連携でサーバサイドと、AS側あわせても15分もあれば出来ちゃうんだけど。なんか大きくて怖いなーっていう。素直にXMLでも使っとこう。

人力検索を初めて使ってみた

投稿完了の画面で、500 Internal Server Error が帰って来た。でも見たら投稿出来てた。Web作ってると、こういう状況になるのが一番怖い>< これで問い合わせが来て、調べたらちゃんと出来てますっていうのでも何て説明したらいいのか分からないという。

SSHトンネリングで複数ポートを指定する

192.168.1.1 経由で、そこから見た 192.168.10.1 の 8080, 80 番ポートにつなぐときは並べればおk。

$ ssh -L8081:192.168.10.1:8080 -L8082:192.168.10.1:80 ecp@192.168.1.1

トンネリングだけするなら、-N -f (トンネリング、バックグラウンドで実行) のオプションを付けた方が良い。

$ ssh -N -f -L8081:192.168.10.1:8080 -L8082:192.168.10.1:80 ecp@192.168.1.1

unix socket で nginx の後ろで thin (Rails) を動かす

ひょー、家のサーバ落ちたー。から hatena に書いておこう。

Railsを起動するとき、いつもPoundの後ろで複数ポートで振り分けっていうのをよくやっていたのだけど、unix socket で nginx の後ろで thin を動かすと早いらしいとのことで、試してみた。

環境はOSX

thinのインストール

$ sudo gem install thin
$ sudo gem install eventmachine --source http://code.macournoyer.com

2行目は、thinをsocket指定して動かす時に eventmachin の 0.11.0 以上が必要とのことで、OSXでデフォルトで入らなかったので入れた。

インストールはこれで完了。

nginxのインストール

Portで入るのが 0.5.1 ?とかで、ちょっと古かったので公式サイト(http://nginx.net/)から現時点で安定版の 0.6.31を取得してインストール

$ wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz
$ tar xvzf nginx-0.6.31
$ cd nginx-0.6.31
$ ./configure --prefix=/usr/local
$ make
# make install

で、無事インストールが終わるはず。configure で pcre チェックされてたので、 pcre とか入ってない場合はいれたほうがよさげ。VirtualHostの設定するときに使われるのかな?

nginxの設定

configure のオプションで --prefix=/usr/local とした場合、設定ファイルは /usr/local/conf/nginx.conf に生成されていて、デフォルトでこれを読みに行きます。

編集します。最低限の設定だけ。

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  0;

    upstream backend {
        server unix:/tmp/thin.0.sock;
        server unix:/tmp/thin.1.sock;
        server unix:/tmp/thin.2.sock;
        server unix:/tmp/thin.3.sock;
    }

    server {
        listen       80;
        location / {
            proxy_pass http://backend;

        }
    }
}

これで、80番ポートにきたものを、unix socket の /tmp/thin.[0-3].sock で動いてる何かに転送出来るようになりました。

以下のように、-t をつけて設定ファイルの文法チェックをします。OKなら以下のようなメッセージが出ました。

$ sudo /usr/local/sbin/nginx -t
2008/06/25 01:05:12 [info] 14511#0: the configuration file /usr/local/conf/nginx.conf syntax is ok
2008/06/25 01:05:12 [info] 14511#0: the configuration file /usr/local/conf/nginx.conf was tested successfully

thinの設定(起動)

Rails でしか使ったことないので、以下 Rails アプリのディレクトリ直下で叩いてくだしあ。コマンドに引数渡すだけだけど、先ほど nginx.conf で指定した unix socket で動かす。

  • s は サーバ4つで、--socket で /tmp/thin.sock とするとサーバの数だけ /tmp/thin.n.sock が出来るようだ。
$ thin start -s 4 --socket /tmp/thin.sock 

nginxの起動

以下のコマンドで起動します。ぼくの環境だと、何も標準出力されずに起動しました。起動したら lsof -i:80 とかして80番で立ち上がってることを確認します。

$ sudo /usr/local/sbin/nginx 


これで動いてるようだ。

この状態で、裏を切ってみる。Rails だと、thin の pid ファイルが tmp/pids/ 以下に出来ますんで、今 /tmp/thin.[0-2].sock で動いてるところを切ってみます。

$ kill cat `tmp/pids/thin.0.pid`
$ kill cat `tmp/pids/thin.1.pid`
$ kill cat `tmp/pids/thin.2.pid`

これで3だけが動いてる状態になりましたが、正常につながっているようです。ちゃんと振分けられてるみたいですねー。


Pound に比べていいなって思うところが、バックエンドが落ちたときの挙動です。Pound は Alive で指定した秒数でポーリングでバックエンドを死活監視をしてるみたいなので、後ろが落ちちゃったあと次のポーリングまではエラー画面が出てしまいます。

nginx で今回試してみた感じ、後ろが落ちても前にエラーが表示されることはないみたい?全部落ちると、もちろんエラー画面が出ますけど。

参考URL: http://wiki.codemongers.com/Main (nginx の wiki)

中国行ってるとき、家のサーバ落ちたら終わりかと('A`)

Linuxサーバの時刻を合わせる

Linuxの時刻をNTPサーバに合わせる

# ntpdate -b [サーバ名]

サーバ一覧でまとめられてた。
http://www.venus.dti.ne.jp/~yoshi-o/NTP/NTP-Table.html

# crontab -e
0 0 1 * * /usr/sbin/ntpdate -b [サーバ名]

とかしておけばおk。