ぬまのどろ

namazuのゆるい日記。　ゆるり更新。

Nginxでちょっと引っかかった

今日したこと

  • ボスから卒論が終わったらならさっさと発表パワポを作りなさいと圧を掛けられる会があった
  • ノートPCのFirefoxからひたすら音が鳴らなくて発狂した。　とりあえず＝＞PulseAudio - ArchWiki 　これを見て一つ賢くなった。 Linux常用してるとやっぱ色々触ることが多くなって、知識が増えやすくなっていいなーって感じた　もっと昔からWindowsを放り投げてノートPCをLinuxにするべきだった。
  • ３年生が創成課題でいろいろしているなか一人で机でタイピングゲームずっとしてた　タイプ音がたぶん迷惑だったと思う　でも気にしない
  • コードを書いて闇と闘った
  • Nginxの設定であれ？となったので調べた

こんなところ。

Nginx

みんな大好きNginx。

私は半年くらい、とりあえずテストするために、とりあえず２００とか３０１とか返すエンドポイントを用意したい！ってなることが数回あり、それを速攻で実現する手段を考えていました。 今日（やっと）それってNginxでいいのではということに気づきました。　設定はすぐ書けるし、柔軟だし、インストールもすぐだし、高機能だしGood。　なんかコード書かないと実現しないかなーなんて考えていたのが思い至らなかった原因だと思う。　思考が凝り固まっててよくないですね。

今日は実際にNginxであれ？ってなったことについて、ちょろっと反省の意を込めて書きます。

auth_request

今日気になったのはこいつ。　SSOをやったりするために使うディレクティブです。　本番のproxy_pass前にauth_requestに指定したところにサブリクエストを送って、その結果で色々してアクセス検証したりしようなーってやつ。

Module ngx_http_auth_request_module

これは某所でも研究室でも使っていました。

ただ今日、

  • authのproxy先が300系返したらどうなんの？　
  • その後にリダイレクトしたい先をauthのサブリクエスト結果から返したりするのどうやんの？　

って気になった。

分かったこと

①　ちゃんと読むと書いてあるけど、proxy先が301とか返した場合、リクエストは500になる。

②

server {
   server_name: hoge.com;
   auth_request /auth;
   auth_request_set $auth_request_res_value $upstream_http_*
   #以後　$auth_request_res_value をつかってリダイレクトなりなんなりをする
   location /auth {
     internal;
     proxy_pass login.hoge.com;
   }
   location / {
      proxy_pass http://app;
  }
}

server {
  server_name login.hoge.com;
  location / {
     proxy_pass http://login-app; # proxy結果ヘッダになんか情報がつく
  }
}

これが出来るのか確かめたかった(設定は大分省略しているが）。　結論からいうと、普通に実現できた。

実際の問題はできるか試行錯誤していた段階で発生し、（私がアホなせいで）いくつか引っかかった。　まずログインサーバからの情報付与をNginxのテスト段階で実現させるために、

location / {
   proxy_pass http://login-app; # 401が返る
  add_header X-Mofu Nyan; 
}

みたいなことをした。　これではだめ。 curlしてもヘッダにX-Mofuヘッダは付かない。

Module ngx_http_headers_module ここを読めばちゃんと書いてあるわけだが, add_header X-Mofu Nyan always;といったように401で付けるためにはalwaysが必要になる。

いつも適当な解法例をコピって実現しており、それを暗記していたせいで今回引っかかった。 一度は公式のドキュメントに一通り目を通さないとダメだなと痛感。 暗記していてさらっと触れる物(今回はNginx）ほどこういうことが多いんだろうと想起して怖くなった。

Nginxの実行順序

上の設定ができるのか試していたとき、この問題に引っかかった。　私はアホだったので,proxy_pass http://app;とか書かずにとりあえず return 200;って書いてcurlでテストすればいいと思った。 そうするとどうなるか。 auth_requestはそもそも実行されず、綺麗に２００だけ帰ってくる。

nginxのlocationの記法による優先度などはちゃんと理解していたが、nginxの処理フェーズについては完全に失念していた。

例えば　return , proxy_pass , rewrite , if 等諸々があったときどういう順番で処理が回るのかしっかり理解できていなかった。

時間も無かったので適当なところで済ませてしまったが、

こちらを参考に

フェイズに注意 return や rewrite, set などは deny とか allow より先に処理される等、ディレクティブの処理順番に注意。 deny all; としていても同じ location に return 200 "hello"; とか書くと 200 が返ってくる。 処理順番はドキュメントに記載されていない場合が多いので、気になる場合は実験するかソースを読むしかない。 基本的に set, rewrite, return などのリライト系が最初に処理され、limit_req などのリソース制限系が次に処理され、deny, allow などのアクセス制限系が次に処理され、次に proxy_pass などのレスポンス生成系が処理される。ログの出力は一番最後。 internal redirect があると内部的にフェイズが巻き戻り、また最初から順番に処理される。

nginx の設定をレビューするときの観点をまとめてみた - Cybozu Inside Out | サイボウズエンジニアのブログ

覚えた。

今度一度ちゃんと調べたい。

どうでもいいはなし

最近まったく練習していなかったこともあり、タイピング速度がだいぶ落ちてしまったことが、今日明らかになった。　悲しい。　また練習して恥ずかしくないようにしたい。

コードを書いてると楽しい、寝不足になってしまった。　寝ようとするとなんかアイデアが浮かんできて眠れず、結局PCの前に座ってしまうのが良くない。　寝不足の頭では進捗が出ないのは分かっているから、寝ないといけないのだけどなかなか難しい。 スイッチ切るみたいに人って眠れないんですかねぇ。。。

ねむねむなまま研究室でジェンガしたら負けた。　なんかぼーっと抜いたら同時に２ブロックも抜けるとかいうNoobだった。　１００円奢るっていうルールだったので、アイスをたかろうと思ったのだが、自分がみんなに奢る羽目になった。

ねむねむなので、ダーツバーいこうよって研究室メンバーのお誘いを断っておうちに帰ってきてしまった。　行ったとしても、眠い状態で酒飲むのは怖いのであれ。　眠いときに飲むと酷い思い出しかないのでまぁしかたなし。 また今度チャンスがあったら是非行きたい。