背景

先日AWSにrailsアプリケーションをデプロイする機会がありました。
そのときの作業内容をメモ的に残しておきたいと思います。

構成

railsをデプロイするとき、
nginx + unicorn + rails
という構成にする事が多いようです。

1. nginx　とは
apacheのようなwebサーバです。
webサーバはユーザからのリクエストが来ると最初に対応してくれます。受付のようなものです。
自分だけでリクエストを処理することもあれば、他にリクエストを渡して処理をさせることもあります。
・静的ファイルを返すだけの時などは、自分で処理をしてくれます。
・railsの処理を必要とするリクエストの場合はアプリケーションサーバに処理を渡します。

2. unicorn　とは
アプリケーションサーバです。今回で言えば、railsのアプリケーションを動かしているサーバです。
railsアプリケーションを動かすのであれば、アプリケーションサーバだけでも動きます。（しかし、webサーバだけでは動きません。nginxだけではrailsは動かせません。）
これは開発環境の時にやっていることです。
ただ、本番環境では通常はwebサーバとアプリケーションサーバを用意します。
処理するリクエストの数が違うからです。

Rack

unicornを検索してみるとRackという単語に遭遇する事が多いので、これについて少し調べてみました。

Rackはwebサーバとフレームワークをつなぐ橋渡し的なものです。
以前はwebサーバそれぞれをサポートするために、フレームワーク側でコードを記述する必要がありました（？）
そのため、このフレームワークではこのサーバしか使えないという状況があったようです。

それを解消するのがRackというわけです。
Rackに対応する事でwebサーバ、フレームワークの両者は個別具体的な対応をする必要がなくなりました。
という事で、どのフレームワークを使っていてもwebサーバの選択に対する制約がなくなりました（逆もまた然り）。

リクエストの流れは、以下のようになっています。（レスポンスが返る時はこの逆順に返されます。）
nginx -> unicorn -> rack -> rails -> routes.rb -> 適当なcontroller

設定

設定する時にちょっとハマったところをメモ書き程度に書いておきます。
nginx と　unicornをつなぐための記述は以下の二つのファイルのunicorn.sockのパスを合わせます。

/etc/nginx/conf.d/アプリケーション名.conf

upstream unicorn {
  server unix:/home/ec2-user/projects/tmp/unicorn.sock;
}

config/unicorn.rb

  $app_dir = "/home/ec2-user/projects"
  $listen  = File.expand_path 'tmp/unicorn.sock', $app_dir
  listen $listen

これで基本的にはnginxとunicornはコミュニケーションを取れるようになったというわけです。