aws nginx + unicorn (13:permission dnined) while connecting to upstream でハマッた時に試したことのTIPS

nginx + unicorn

下記、記事を aws のサーバーにあげた時のお話。
Rubyで仮面ライダークウガのグロンギ語翻訳ロジックを書いてみた-part1-

unicorn に接続しようとしても
nginx のログにエラーログが出力されて、一向に unicorn との連携ができなかった。

前提

nginx からの、リバースプロキシで unicorn に接続。
サーバーを勉強始めて6ヶ月目(？)くらい

unicorn の port にするつもりの3000番は、
aws の EC2 インスタンスから開放済み(ネタバレ：今回の落とし穴)
諸々の設定を終えて、unicornの立ち上げ！！

bundle exec unicorn -c config/unicorn.rb -D

あれ？繋がらないぞー。エラー・・・

*11 connect() to unix:/home/centos/unicorn/tmp/unicorn.sock failed (13: Permission denied) while connecting to upstream

さぁ、検索を始めよう・・・(仮面ライダーWてきな

確認したこと・試したこと

unicorn.sockのパーミッションは正しいか？

パーミッションがないって言われたら、まず対象のファイルのパーミッションを調べたくなりますよね。
というわけで、本能に従って調べました。
パーミッションは777で指定してあったので問題なし。

srwxrwxrwx. 1 centos centos  0  1月 10 14:33 unicorn.sock

うーん。。。じゃあどこで駄目なんだろうか。調査続行。

nginxを立ち上げたユーザーと、unicornを立ち上げたユーザーが一致しているか？

nginx を立ち上げるユーザーと、 unicorn を立ち上げたユーザーが一致しないと同じく permission denined で弾かれるそうです。
注意するポイントは、nginx はデフォルトだと nginx というユーザーになるということ。
ユーザーがあっているかを確認する時は、以下コマンドです。

[centos@ip-10-0-0-67 tmp]$ ps aux | grep nginx
nginx    6984  0.0  0.0 112660   956 pts/0    R+   10:20   0:00 grep --color=auto nginx
root     13688  0.0  0.1  48668  1392 ?        Ss    1月10   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx   13689  0.0  0.3  51304  4032 ?        S     1月10   0:00 nginx: worker process

[centos@ip-10-0-0-67 tmp]$ ps aux | grep unicorn
centos    6986  0.0  0.0 112660   960 pts/0    R+   10:21   0:00 grep --color=auto unicorn
centos   14733  0.0  2.3 218344 24220 ?        Sl    1月10   0:00 unicorn master config.ru -c config/unicorn.rb -D -p 3000
centos   14736  0.0  8.2 301024 83880 ?        Sl    1月10   0:02 unicorn worker[0] config.ru -c config/unicorn.rb -D -p 3000
centos   14738  0.0  8.0 299012 81788 ?        Sl    1月10   0:02 unicorn worker[1] config.ru -c config/unicorn.rb -D -p 3000

確認した結果、案の定 nginx は nginx。unicorn は centos で立ち上がっていたとさorz
nginx のユーザー指定は、下記ファイルで行います。
/etc/nginx/nginx.conf

#user  nginx;　# 初期設定
user centos;　# unicorn側のユーザーに合わせる
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
　　　・
　　　・
　　　・

再起動

sudo service nginx restart

[centos@ip-10-0-0-67 tmp]$ ps aux | grep nginx
centos    6984  0.0  0.0 112660   956 pts/0    R+   10:20   0:00 grep --color=auto nginx
root     13688  0.0  0.1  48668  1392 ?        Ss    1月10   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
centos   13689  0.0  0.3  51304  4032 ?        S     1月10   0:00 nginx: worker process

無事にユーザーは一致しました。
ただ、これだけだと駄目だった。他にも原因があるっぽい。
うーん。。。じゃあどこで駄目なんだろうか。調査続行(2回目)

awsのEC2のポートは空いているか？

はっ！！これか！！？
・・・というのも、最初から調査段階でハマルと知っていたので、対応していたのですけどね。
unicorn の port を3000で繋ぎたかったため、
aws の EC2 インスタンスの3000番を接続できるように開ける必要あり。

再度、確認してみたのですが3000は空いている・・・
うーん。。。じゃあどこで駄目なん(ry

unicorn起動時のportの指定は大丈夫か？

unicorn を立ち上げるコマンド実行時に、aws で開けていたポートに -port で指定していなかった。
unicorn のデフォルト port は8080（らしい）。
上記で3000を指定して開けていたので、unicorn起動時にポートを指定してあげる必要あり。

bundle exec unicorn の時に -p で port 番号を指定してあげて無事に解決。立ち上がりました。

bundle exec unicorn config.ru -c config/unicorn.rb -D -p 3000

おまけ

bundle exec unicorn config.ru -c config/unicorn.rb -D -p 3000
-c 設定ファイルの指定
-D デーモン化の指定
-p ポート番号の指定（今回の立役者）

まとめ

サーバー、ハマッた。
噂どおり、サーバーはハマると余裕で一日中使いますね・・・
合宿中にハマッたのですが、朝の8:00から15:00まで戦っていました。

今回、ハマれたし、TIPSも貯められたのでよしとしよう。