もう一度Nginx+Unicorn+Railsを試してみる
もう3年以上前のことですが、一度Unicornを試してはいます
Rails3アプリをnginx+unicornで動かしたら速すぎた - ぱろっと・すたじお
その頃はまだ「運用」に関するノウハウが足りておらず、
サーバ再起動のたびに失敗する起動スクリプト*1を手動で実行するとか、
速さの代償にいろいろ面倒を背負い込んでいる感じでした(´-ω-)
なにより、動かしていたサイト自体が頓挫し、
その後構築していたRO用のシステム*2は、
一つのサーバに複数動かす仕組みだったので、あまりUnicorn向きではありませんでした
（今の仕事でも、Rack以外の部分も含めて統一した運用をしたいということで、
あえてApache+Passengerという環境で動かしています）
そして今取り組んでいるのがこちらですが・・・
Get our light! - チェンクロパーティーシミュレーター
・・・これを独立したドメインにするか悩んでいて、
とりあえずサーバだけ移行しようかな・・・と考えていたところ、
今月のWEB+DBでRackサーバの記事を読んだわけです*3
- 作者: 原田騎郎,吉羽龍太郎,山口陽平,青木雅弥,松下誠太,三宅英明,高橋征義,南川毅文,伊藤直也,海野弘成,高安洋輝,佐藤歩,泉水翔吾,佐藤太一,横江直輔,舘野祐一,橋本翔,渡邊恵太,中島聡,はまちや2,小沢邦雄,長沢智治,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2014/10/24
- メディア: 大型本
- この商品を含むブログを見る
一つのサーバに一つのアプリならUnicornで問題ないですし、
記事の中でもだいぶ枯れていると紹介されていたので、
いい機会だからやり直してみようかと
以上、経緯と前置きでしたΣ(・ω・ノ)ノ
なお、今回参考にさせていただいたサイトはこちらです
Ruby - Nginx+Unicorn設定ファイルサンプル - Qiita
Unicorn+Rails入門 - Less is Best
Unicornの設定
Unicorn側は3年前とそんなに変わるところがないのですが、
同一サーバの場合はソケットがいいらしいので、
そこが以前と変わったところでしょうか
https://github.com/parrot-studio/cc-pt-viewer/blob/master/config/unicorn.rb
といっても、以前のシステムはソースをGitHubに置いてない*4ので、
比較しようもないわけですが・・・(´･ω･`)
あと、以前は「unicorn_rails」ってコマンドを使っていましたが、
今はただの「unicorn」で起動するのが主流だそうです
Nginxの構築
Passengerの場合、組み込む都合で専用のインストーラーがあったりしますが、
今回はProxy経由なので普通にyumでインストールしただけです
設定ファイルもひな形を作ってくれるツールがあります
https://github.com/i2bskn/nginx_utils
Unicornとの連係を前提にしたconfを出力できるので、
そこだけ指定した形で出力し、細かいところは後からいじりました
upstream backend-unicorn {
server unix:/path/to/app/tmp/sockets/unicorn.sock;
}
server {
listen 80;
server_name ccpts.parrot-studio.com;
root /path/to/web/root;
index index.html;
location / {
try_files $uri @proxy;
}
location @proxy {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://backend-unicorn;
}
}「ファイルがあればそのまま返し、なければProxy」って設定が、
これだけ簡単に書けるのはすばらしいですね(｀･ω･´) ｂ
まあ、以前からあったのを、当時の私が知らなかっただけ、という可能性も・・・
あとは自動起動スクリプト（for CentOS6.5）ですが、
調べるといろいろ出てきますので、必要なところを書き換えて使用しました
私がやったのは、「unicorn_rails」を「unicorn」に変えた程度です
運用レベルでのPassengerとの違い
PassengerはNginxに組み込まれて動いており、
アプリ再起動のために「restart.txt」の仕組みが存在します
なので、基本的にはアプリの管理を一般ユーザで実行できます
Unicornの場合はアプリ自体をinit.dで自動起動しているため、
実行権限はrootになります
そのため、システムが生成するtmp以下のファイルは、root権限になります
このため、アプリのcacheクリア等*5をsudo経由でやらないといけないのが面倒なのですが、
一般権限でUnicornを動かすような指定も面倒だったので、そこは許容してますΣ(・ω・ノ)ノ
いやまあ、「最近のサーバ管理手法」とかなんとかいろいろあるのはわかりますが、
今回の目的は「Nginx+Unicornで動かすこと」なので、
その辺は "面倒になったら" 考えます
以上、わかっている方には当たり前の話でしたが、
例によって自分用のメモ書きということで...φ(･ω･｀)