What have you found for these years?

2009-01-13

app-deploy, rack-cluster

(把閒聊拆成另一篇好了)

一開始只是在整理 app-deploy 的 gem install task,
調整到也支援一般的 gem, 還有 install 忽略已 install,
uninstall 忽略已 uninstall, 統一輸出訊息,於是可以任意:

rake app:install # => git clone + gem install
rake app:gem:install # => gem install 包括 build 和直接 install
rake app:gem:uninstall # => 比較單純因為不用 build
rake app:gem:reinstall # => [:uninstall, :install]

git clone 的部份也是如果目標已存在,忽略掉。

所以以前常常半路掛掉結果整個就要重來的狀況應該已經沒了。

然後手癢就開始寫起 rack cluster tasks...
寫到剛才測試沒什麼問題,就開始想抽到 rack-cluster...
大概就模仿 thin runner 做一次吧。除了 restart 的部份,
我是做成一個一個重啟,而不是全部關掉再全部打開。

godfat ~/p/g/photos> rake app:rack:restart config=image_server/rack.yml
(in /home/godfat/projects/gits/photos)
Sending TERM to mongrel(25857)...
Killed mongrel(25857)
Starting mongrel on 0.0.0.0:3500...

Sending TERM to mongrel(25860)...
Killed mongrel(25860)
Starting mongrel on 0.0.0.0:3501...

Sending TERM to mongrel(25863)...
Killed mongrel(25863)
Starting mongrel on 0.0.0.0:3502...

restart 大概就是這個感覺。此外 pid/log 應該都有處理好。
(應該是比那該死的 merb -K all 好太多了......)

然後發覺 rack 的 script 寫得很爛... thin 的 script 寫得很好。
我用 rack 的 daemonize 好像都會有問題,所以我是學 thin 用 daemons
這個 gem, 感覺是還不錯,Daemonize.daemonize log 就可以把 stdout
都導到 log file 上,第二個參數是 process name, 我測試是有點怪,
不過這或許是 mac 的問題也說不定?

另外 term 的部份倒是完全自己寫的,大概就是每 0.1 秒丟一個 TERM,
然後發現 pid 不見時才跑下一個。如果 pid file 卻還在,表示有問題...
不過除了把這 pid file 刪掉大概也沒啥好做法就是了。所以只是噴個警告就算了。

至於 soft restart, 這個可能就... 再研究吧,需要每個地方都支援才行。
而我直覺認為這似乎不太可能... 因為這意味不能有任何人寫骯髒程式啊!
在 ruby 世界感覺不太可能 XD 除非從頭到尾的程式都是自己寫的...

0 retries:

Post a Comment

All texts are licensed under CC Attribution 3.0