まいど！
作成したアプリをHTTPS接続させたいなぁと思って、AWSのインフラ構成を見直してよりセキュアなものに作り直す機会があったのですが、その際にいくつかのエラーと遭遇したので忘れないように対処等をまとめました！
##構成図
- ALBに証明書を割り当てる
- EC2は全てプライベートサブネットへ
- WEBサーバーとAPサーバーを分離
- WEBサーバーはキャッシュの読み込みとリバースプロキシ設定
- APサーバーは投稿画像をS3へアーカイブ
- メンテやエラー用の踏み台サーバー
##ALBを設定した際のunhealthy
ALBとターゲットグループの設定を行っていた所、状態がいつまでたってもunhealthyだったので見直しも兼ねて構築手順をまとめます。
###ALB設定手順
①EC2のナビゲーションペインからターゲットグループを選択し、右側の「ターゲットグループの作成」を選択します。
②ターゲットはインスタンスを選び、ターゲットグループ名、プロトコル、ポート、VPC、プロトコルバージョンを画像のように選択します。
③ヘルスチェックの設定をします。私はここで成功コードを「200」に設定していました。本来はこれで問題ないのですが、リバースプロキシ設定を行っていたWEBサーバー側のNGINXから302リダイレクトが出ており、ALBがヘルスチェックの際にそれをキャッチし、結果としてunhealthy状態となっていました。解消策として、成功コードに302を記述し、リダイレクトの際もhealthyとしました。ちなみに、ターゲットグループに登録されたインスタンスが1台の場合は、ヘルスチェックの結果を問わず必ず転送するという仕様らしく、シンプルに作る場合はこういったunhealthy状態になることは稀です。
④使用可能なインスタンスからWEBサーバーを選び、「保留中として以下を含める」を選択します。すると、ターゲットに保留中のWEBサーバーが追加されるので保存を選択します。
⑤すると、ターゲットグループに登録されます。
⑥ALB用のセキュリティグループを作ります。HTTPSの443を開けます。忘れずに！
⑦ナビゲーションペインからロードバランサーを選択し、名前とIPアドレスタイプ、ロードバランサーのプロトコル、AZをそれぞれ入力していきます。パブリックサブネットを２つ選択しておきましょう。
⑧事前に用意しておいた証明書を選択します。
⑨セキュリティーグループとルーティングのターゲットグループは先ほど設定しておいたものを選択します。
⑩ターゲットの登録は済ませてあるのでそのまま進んで、作成を選択します。これでALBの設定は終わりです。
##Route53の設定
こちらは準備しておけば後はポチポチするだけなので簡単です。
①「レコードを作成」を選択します。
②シンプルルーティングのAレコードでエイリアスを選択し、トラフィックのルーティング先はALBを選択し、レコードを作成します。
設定は以上！
##なんかつながらない……
なぜだろう。繋がらない。
そんな時はログを見てみましょう。ひとまず、WEBサーバー側（NGINX)に踏み台サーバーから入って、ログをチェックしてみます。
すると、
"POST /users/sign_in HTTP/1.1" 422 1705 "
これっぽいですね。
422エラーが起きてることがわかります。
The HyperText Transfer Protocol (HTTP) の 422 Unprocessable Entity 応答状態コードは、サーバーが要求本文のコンテンツ型を理解でき、要求本文の構文が正しいものの、中に含まれている指示が処理できなかったことを表します。
422 Unprocessable Entity
WEBサーバー側の問題っぽい。NGINXはHTTPSを受け取っているのでそこら辺の設定をすれば通るはず。
という事で以下のどれか１つを/etc/nginx/conf.d/○○○.confに追加します。
#どれか１つ追加！！！
proxy_set_header X-Forwarded-Proto: https
proxy_set_header X-Forwarded-SSL on;
####説明
X-Forwarded-Proto (XFP) ヘッダーは、プロキシまたはロードバランサーへ接続するのに使っていたクライアントのプロトコル (HTTP または HTTPS) を特定するために事実上の標準となっているヘッダーです。
X-Forwarded-Proto
これで無事、アプリにログインすることができました！
以上！