概要

ACMの機能で発行したSSL証明書をELBに適用することにより、インターネットからELBまでのトラフィックをHTTPS通信にすることが可能となります。
HTTPS通信はSSL/TLSプロトコルにより暗号化されたhttp通信のため、個人情報など秘匿性が求められる情報の盗聴や改ざんを防ぐことに役立ちます。

変更前、変更後の構成イメージは以下の通り。

HTTPS化を行うにはそこそこの手順があり、間違えるとどう直せば良いのかわからなくなってしまいます。
何を、どこまでやったのか、確認しながら行うようにしてください。

まずは段階的にロードバランサーの作成から行っていきます。
※既にEC2インスタンス上にDjangoアプリケーションが動いている前提で進めていきます。

なお、以降では
・仮想環境名　：　venv_private_diary
・プロジェクト名　：　private_diary
・EC2ユーザ名　：　app_admin
としていますので、ご自身の環境と異なる箇所は読み替えを行って実行してください。

ロードバランサーの作成

1. AWSマネジメントコンソールにてEC2のダッシュボードに移動し、左側のメニューから「ロードバランサー」を選択。

2. 「Create load balancer」をクリック。

3. `Application Load Balancer`の「Create」をクリック。

4. Basic configurationの`Load balancer name`にロードバランサー名を入力。

5. Network mappingの`VPC`にEC2インスタンスのVPCを選択。

6. Network mappingの`Mappings`でそれぞれのAZからパブリックサブネットを選択。

※「~subnet-public1」などとなっているものをそれぞれから選べばよい。

7. Security groupsの「Create new security group」リンクをクリック。

8. セキュリティグループ作成

8-1. 基本的な詳細で、`セキュリティーグループ名`と説明を入力。

8-2. 基本的な詳細で、`VPC`からEC2インスタンスのVPCを選択。

8-3. インバウンドルールで、`HTTP：80`を設定。

8-4. 「セキュリティグループを作成」をクリック。

9. ロードバランサー作成画面に戻り、Security groupsで作成したセキュリティグループを選択。

10. Security groupsで`Default`を削除。作成したセキュリティグループだけを残す。

11. Listeners and routingの「Create target group」リンクをクリック。

12. ターゲットグループ作成

12-1. `Instances`を選択。

12-2. `Target group name`を入力。

12-3. Protocolに`HTTP`を選択し、Portを`10080`に設定。VPCにはEC2インスタンスのVPCを選択。

※Portを10080にしている理由は、Nginxとの兼ね合いがあり、エラーとなることをふせぐため。

12-4. その他はデフォルトのまま、「Next」をクリック。

12-5. Register targets画面で、対象のEC2インスタンスを選択し、「Include as pending below」をクリック。

12-6. Targetsの一覧に、対象のEC2インスタンスが追加されていることを確認し、「Create target group」をクリック。

13. ロードバランサー作成画面に戻り、更新した後に作成したターゲットグループを選択。

14. その他はデフォルトのまま、「Create load balancer」をクリック。

15. 作成したロードバランサーのStateが`Active`になるまで待機。

アクティブになったことを確認する。

16. AWSマネジメントコンソールにてEC2のダッシュボードに移動後、一覧から自身のEC2インスタンスのチェックボックスを選択し、セキュリティタブを開き、`セキュリティグループ`リンクをクリック。

17.　「インバウンドのルールを編集」をクリック。

18. 「ルール追加」をクリックし、以下のように、ポート：`10080`、ソース：`カスタム`＋`作成したALBのセキュリティグループ`を選択し、「ルールを保存」をクリック。※もともとあったhttp、httpsのルールは削除してよい。

環境変数の設定変更

1. PuttyでEC2インスタンスにSSH接続を行う。

2. .bash_profileをviエディタで編集し、環境変数ALLOWED_HOSTSを変更する

コマンド

# .bash_profileをviエディタで開く
sudo vi ~/.bash_profile

~/.bash_profile

# 変更：ALLOWED_HOSTSに＊（アスタリスク）を設定する
export ALLOWED_HOSTS='*'

3. 変更を即座反映。

コマンド

source ~/.bash_profile

4. 環境変数ALLOWED_HOSTSが変更されたか確認

コマンド

env | grep ALLOWED_HOSTS

5. 変更後の環境変数を適用するため、Gunicornを再起動

コマンド

# gunicornプロセスの削除
pkill gunicorn
cd ~/venv_private_diary/private_diary/
# gunicorn起動
gunicorn --bind 127.0.0.1:8000 private_diary.wsgi -D
# gunicornプロセス確認
ps -ef|grep gunicorn

Nginx設定ファイルの変更

1. nginx.confのバックアップを作成。

コマンド

#　バックアップの作成
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf_bk

※バックアップは「nginx.conf_bk」という名前で作成されます。

2. nginx.confをviエディタで編集し、listenのポートを10080に変更。

コマンド

#　nginx.confを修正
sudo vi /etc/nginx/nginx.conf

nginx.confの修正は下記の通り。

nginx.conf

    :(省略)
    server {
        listen       10080;    # 80 -> 10080 に変更
        listen       [::]:10080;    # 80 -> 10080 に変更
        :(省略)

3. nginx.confの構文チェック

コマンド

sudo nginx -t
#下記のように出力されたらOK
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

※エラーが出た場合は、エラー内容にしたがってnginx.confを修正する。

4. Nginxの再起動

コマンド

# nginx再起動
sudo systemctl restart nginx.service
# 状態の確認
sudo systemctl status nginx.service

ロードバランサー経由での接続確認

2. AWSマネジメントコンソールにてEC2のダッシュボードに移動し、左側のメニューから「ターゲットグループ」を選択。

2. 自身が作成したターゲットグループのNameリンクをクリック。

2. Health status が healthy となっていることを確認。Unhealthy の場合は、設定などに問題あり。先に進まずにセキュリティグループなどの設定を確認すること。

2. EC2のダッシュボードに移動し、左側のメニューから「ロードバランサー」を選択。

3. 自身が作成したロードバランサーの`DNS name`をコピー。

4. Chromeなどのブラウザにコピーした`DNS name`を入力しアクセス。画面が表示できればOK

■ページが表示されない場合
PuttyでEC2インスタンスに繋ぎ、アクセスログを確認しましょう。

コマンド

# アクセスログ確認
sudo tail -f /var/log/nginx/access.log

10.0.17.60 - - [21/Nov/2022:09:52:54 +0900] "GET / HTTP/1.1" 200 3520 "-" "ELB-HealthChecker/2.0" "-"

ロードバランサー（ELB）のHealthCheckerによるログが記録されていれば、ロードバランサーからNginxに接続できていることが確認できます。
※接続されていない場合は、セキュリティグループなどの設定を確認しましょう。

・ログの内容が4xxまたは5xxなどのエラーコードを返している場合
"GET / HTTP/1.1" 500 のようにエラーコードを返している場合は以下のコマンドからDjangoのログを確認し、エラー内容から修正を行ってください。
※原因としては、Gunicornが起動していない、環境変数に誤りがある、といったものがありがち。

コマンド

# Djangoログ確認
sudo tail -f ~/venv_private_diary/private_diary/logs/django.log