Weblogアプリ（フルスクラッチ）デプロイの手順記録

概要

ここではフルスクラッチで作成したWeblogアプリのAWSへのデプロイ手順について詳細に説明したものを記述していきます（自分が忘れないための記録用として書いています）。

該当のデプロイについて紹介したものはこちら ↓

手順

実際の手順について紹介していきます。一気に書いていくとわかりにくくなりそうなので、
　①VPC構築
　②EC2インスタンスの作成
　③DBサーバの準備
　④WEBサーバの準備
　⑤HTTPS通信化
という流れで紹介していきます。

インフラ構築

最初にVPCとインターネットゲートウェイ、サブネットグループ、ルートテーブルの作成を行います。構成図に起こすと以下のような感じです。

VPCの作成

AWSサイトで「VPC」と検索し、VPC作成をクリックします。

今回はAWSの学習が目的なので「VPCのみ」をクリックします。そして名前、CIDRブロックを以下の通りに入力して「VPCを作成」とします。今回は名前をweblog-vpc、CIDRブロックは10.0.0.0/16としました。
これでVPC本体の作成は完了です。

インターネットゲートウェイの作成

現状ではVPC外部と内部でのアクセス経路がない状態なのでインターネットゲートウェイを作成して経路の開通を行います。

クリックするとインターネットゲートウェイの名前入力欄が出てくるのでweblog-igwと入力して「インターネットゲートウェイの作成」を押します。

しばらく待ち、作成したインターネットゲートウェイの状態が「Detached」になったらVPCへアタッチしていきます。
作成したインターネットゲートウェイにチェックボックスを入れて「VPCにアタッチ」をクリックします。

するとアタッチするVPCの選択画面が出てくるのでweblog-vpcを選択してアタッチを行います。インターネットゲートウェイの一覧画面に戻り、状態が「Attached」になればインターネットゲートウェイの設定は完了です。

サブネットの作成と設定

EC2インスタンスを配置する場所であるサブネットの作成を行っていきます。今回は外部からのアクセスを直接許可するパブリックサブネットと、外部からのアクセスは許可しないプライベートサブネットの２つを作成していきます。

▸パブリックサブネット
VPCページの「サブネット」からサブネットを作成をクリックします。

するとまずサブネットを作成するVPCの選択画面が出てくるので先ほど作成したVPCを選択します。

選択すると下に設定が出てくるので入力を行っていきます。パブリックサブネットから作っていこうと思うので名前はweblog-public-subnetとし、az（アベイラビリティゾーン）は1aを選択します。サブネットのCIDERブロックはIPv4サブネットのCIDRブロックを10.0.1.0/24として設定を行います。

ここまで入力できたらサブネットを作成をクリックしてサブネットの作成は完了です。

▸プライベートサブネット
プライベートサブネットの作成もほぼ同様の手順で行っていきます。サブネット作成画面へ移り、名前をweblog-private-subnet、IPv4サブネットCIDRブロックを10.0.101.0/24として作成を行います。

以上でサブネットの作成自体は完了です。

ルートテーブルの作成

パブリックとプライベートサブネットの作成は行えましたが、今のままではほぼ名前を付けただけで外部からのアクセスの設定は行えていません。このサブネット部分のアクセス許可をルートテーブルで行っていきます。

▸パブリックサブネットの設定
まずは外部通信を許可するパブリックサブネットの設定から行っていきます。VPCページから「ルートテーブル」を選択してルートテーブルを作成をクリックします。

すると以下のような画面が出てくるので名前をweblog-public-subnet-route-table、VPCは作成したweblog-vpcを選択して「ルートテーブルを作成」をクリックします。

無事に作成できると以下のように作成したルートテーブルの情報が表示されます。

デフォルトではVPC内での接続のみ許可する設定となっているので「ルートを編集」をクリックしてインターネットゲートウェイを登録します。
「ルートを追加」を押して送信先を0.0.0.0/0（すべての送信を許可）としてターゲットは「インターネットゲートウェイ」とします。すると先ほど作成したインターネットゲートウェイが出てくるので選択して「変更を保存」を押します。

パブリックサブネットのルートテーブルに作成したインターネットゲートウェイが紐づいていれば設定は完了です。

▸プライベートサブネット
先ほどと同様にVPCのルートテーブル一覧から「ルートテーブルを作成」を押して以下のように入力して作成ボタンをクリックします。

プライベートサブネットについては外部からのアクセスは許可しないので追加でテーブルを用意する必要はありません。下図のように10.0.0.0/16（VPC内の通信）のみアクセスする形でOKです。

ここまでできたら、パブリックサブネットと同じようにルートテーブルとサブネットの紐づけを行います。サブネットの関連付けからプライベートサブネットを選択して「関連付けを保存」をクリックします。

こちらも下図のように、正常に関連付けが行われれば設定は完了です。

EC2インスタンスの作成

ここまででVPCの構築ができたので、実際にEC2インスタンスを配置していきます。下図のようにパブリックサブネットへはWEBサーバ用の、プライベートサブネットへはDBサーバ用のEC2インスタンスをそれぞれ作成していきます。

▸キーペアの作成
今回はEC2インスタンス内にSSH接続で入って操作を行うのですが、その際に必要となるキーペアをまずは作成していきます。EC2ページのキーペアから「キーペアを作成」をクリックします。

以下のように入力して「キーペアを作成」を押すとキーペアがダウンロードされるので手元に保管しておきます。

これでEC2インスタンス作成の前準備は完了です。

▸Webサーバ用インスタンス
EC2のページに移動して、インスタンス一覧ページから「インスタンスを起動」をクリックします。

設定欄が現れるので、名前をweb-server、キーペア（ログイン）の部分は先ほど作成したキーペアを選択します。

そしてネットワーク設定で編集ボタンを押して作成したVPCと、作成したサブネットのパブリックのものを選択していきます。Webサーバ用のインスタンスは外部からの直接のアクセスが来るのでパブリックIPの自動割り当ては有効とします。

セキュリティグループは新規で作成していきます。このセキュリティグループを設定することでどの相手のどの通信を許可するのか、を定義していきます。
まず、名前をweb-sgとしてセキュリティグループ名をつけます。

そして許可する通信・相手を設定していきます。
今回はSSH接続でEC2インスタンス内部へアクセスして操作を行うのでSSH通信は許可する形とします。そして、本来は担当者のIPアドレスを割り振るのですが今回はあくまで学習なので0.0.0.0/0とすべての相手からの通信を許可する形としています。
また、Webサーバとして使用予定なのでHTTP通信も許可する形とします。Webサーバは一般には不特定多数にアクセスされるのでソースタイプは任意の場所としています。

最後にこのWebサーバのプライベートIPアドレスを設定します。「高度なネットワーク設定」よりプライマリIPを選択して10.0.1.10と入力します。

以上で設定は終わりなので「インスタンスを起動」を押します。

▸DBサーバ用インスタンス
Webサーバ用インスタンスのときと同様にEC2インスタンス一覧ページから「インスタンスを起動」をクリックして名前をdb-serverとして先ほど作成したキーペアを選択します。
そしてネットワーク設定の編集ボタンをクリックし、自分で作成したVPCを選択します。サブネットは作成したプライベートサブネットを選択、DBサーバは外部からの直接アクセスは行わないようにしたいのでパブリックIPの自動割り当ては無効化とします。

セキュリティグループの設定も行います。名前をdb-sgとしてSSH接続を許可するよう設定します。またDBアクセスに関してはWebサーバからのみ許可する形としたいのでタイプをMYSQL/Auroraとしたうえでソースタイプをカスタム、ソースにwebと打ち込むと先ほど作成したweb-sgのセキュリティグループが出てくるのでこれを選択します。

最後にこちらも「高度なネットワーク設定」よりプライベートIPアドレスを設定したら「インスタンスを起動」をクリックします。

少し待って下図のようにインスタンスが実行中、ステータスチェックにもチェックマークがついたらインスタンスの作成は完了です。

開発アプリのデプロイ

AWS側のインフラ構築がこれでおおむね完了したので、ここからはアプリのデプロイに関する作業を行っていきます。
流れとしては最初にWEB・DBサーバを構築し必要な設定を施したのち、ソースコードをgitから取得してAWS上で動作するよう一部修正していきます。

WEBサーバ作成

最初にWEBサーバ（apache）のインストールを行っていきます。
ローカルPC上のターミナル、もしくはAWSのCloudShellを立ち上げて、以下コマンドでまずWeb用サーバにSSH接続で入っていきます。

# 使用するコマンド
ssh -i <キーペア> ec2-user@<Web用サーバのパブリックIPアドレス>

# 使用例
ssh -i weblog-key.pem ec2-user@54.250.160.197

Permissions 0755 for 'weblog-key.pem' are too open.
という警告が出たらファイルアクセス権の変更が必要になります。
sudo chmod 400 weblog-key.pemをコマンド上で入力して読取り権限のみにすると解消できます。

インスタンス内に入れたら以下のコマンドを実行してapacheのインストールと起動を行います。

# パッケージの更新
sudo dnf update -y

# apacheインストール
sudo dnf install -y httpd

# apache起動
sudo systemctl start httpd

# EC2起動時にapacheも自動で起動するよう設定
sudo systemctl enable httpd

# 起動状態を確認
systemctl status httpd
#  Active: active (running) と表示されれば正常に起動している

試しにブラウザからアクセスしてみると（http://<パブリックIPアドレス>で検索）「It works!」と表示されると思います。しっかりとWebサーバが動いていることが分かります。

ここまででWebサーバの構築については完了になります。

DBサーバ作成と設定

次にDBサーバの立上げ作業を行っていきます。MySQLをインストールし、セットアップを行っていきます。

1点、MySQLをインストールする際にインターネットとの接続が必要となりますが現在の設定ではプライベートサブネット内にDBサーバ用のEC2インスタンスがあるので外部との通信は行えません。そこでまずNATゲートウェイで外部へアクセスできるようにしたのち、インストールを行っていきます。

▸NATゲートウェイの作成
では実際にNATゲートウェイを作成していきます。
VPCページのNATゲートウェイから「NATゲートウェイを作成」をクリックします。

設定画面が出てくるので名前をweblog-ngwとし、作成したVPCを選択したら「NATゲートウェイを作成」をクリックします。

これでNATゲートウェイ自体は作成できましたが、まだプライベートサブネットと紐づいていないのでルートテーブルを編集していきます。
VPCのルートテーブルからプライベートサブネットにチェックを入れてアクションプルダウンから「ルートを編集」をクリックします。

ルートテーブルの編集画面が出てくるので「ルートを追加」をクリックして送信先は0.0.0.0/0、ターゲットを「NATゲートウェイ」として先ほど作成したNATゲートウェイを選択します。これで「変更を保存」を押せば前準備であるNATゲートウェイの準備は完了です。

▸MySQLインストール
いよいよDB用サーバにMySQLをインストールしていきますが、外部から直接DB用サーバへはアクセスできないようにしているのでWeb用サーバを踏み台にしてアクセスします。
その際、Web用サーバにキーペアを置く必要があるのでこの作業から行っていきます。EC2インスタンスの外に出た状態で以下コマンドを実行してキーペアをWeb用サーバへコピーします。

# 使用するコマンド
scp -i <ssh接続で用いるキーペア> <ローカル上の送信したいファイル> <リモート先ホスト名>:<コピー先のディレクトリ>

# 今回使用したコマンド（例）
scp -i weblog-key.pem weblog-key.pem ec2-user@54.250.160.197:/home/ec2-user

コピーが完了したらWeb用サーバへSSH接続で入り、DB用サーバへSSH接続していきます。

# Web用サーバへSSH接続
ssh -i weblog-key.pem ec2-user@54.250.160.197

# DBサーバへSSH接続（プライベートIPを指定）
ssh -i weblog-key.pem ec2-user@10.0.101.20

無事に入れたら最初にpingコマンドでNATゲートウェイが正常に動いている、即ちインターネットに接続できることを確認します。

ping google.com 

# 以下のようにレスポンスが返ってくればインターネット接続できている
PING google.com (142.251.24.139) 56(84) bytes of data. 
64 bytes from rj-in-f139.1e100.net (142.251.24.139): icmp_seq=1 ttl=110 time=2.70 ms

インターネット接続を確認したらMySQLのインストールを行っていきます。

# パッケージ更新
sudo dnf update -y

# MySQLインストール
sudo dnf -y install https://dev.mysql.com/get/mysql84-community-release-el9-1.noarch.rpm
sudo dnf -y install mysql mysql-community-server

# MySQL起動
sudo systemctl start mysqld

# 次回以降はEC2起動時に自動でMySQLも起動するよう設定
sudo systemctl enable mysqld

# 起動状態を確認
systemctl status mysqld
# Active: active (running) と表示されればOK

無事に起動まで確認できればインストールは完了です。
※ 以降、DB用サーバはインターネット接続の必要はないのでNATゲートウェイは削除してもOK（ルートテーブルへの紐づけ解除も忘れずに）

▸MySQLの設定
続けてアプリを動かすうえで必要なDBの設定を行っていきます。今回のアプリではセキュリティ上の観点から、DB上にデフォルトであるrootユーザの他にtest_userという別のユーザの作成を作成するのでこの操作を行っていきます。

最初にrootユーザのパスワードを確認・変更します。
以下コマンドを入力して初期パスワードを確認して一度rootユーザでログインします。そして任意のパスワードを設定します。

# 初期パスワード確認
sudo more /var/log/mysqld.log | grep 'temporary password'

# ログインコマンド
mysql -u root -p

# パスワード変更(今回は「Root!1234」と設定)
ALTER USER 'root'@'localhost' IDENTIFIED BY 'Root!1234';

次に今回のアプリで使用するデータベースとユーザを作成していきます。以下コマンドで作成を行います。

-- データベース作成
CREATE DATABASE test_db;

-- ユーザ作成（ここではパスワードを「User!1234」と定義）
CREATE USER 'test_user' IDENTIFIED BY 'User!1234';

-- 作成したユーザにDB操作の権限付与
GRANT ALL PRIVILEGES ON test_db.* TO 'test_user'@'%' WITH GRANT OPTION;

以上でDB側の設定はすべて完了となります。

ソースコードの修正

これでWebサーバの準備とDBサーバのセットアップまで完了したので、ソースコードをWebサーバに取り込んでデプロイしていきます。

まずWebサーバへ移動したらgitをインストールの上、今回のアプリのソースコードをgitより取得します。

# gitをインストール
sudo dnf install -y git

# ソースコードを取得
git clone https://github.com/yoshidasyoki/weblog.git

無事に取得できたらソースコードを/var/www/内に配置してapacheの設定を変更していくのですが先にここでやりたいことを紹介しておこうと思います。

まずソースコードについて簡単に説明すると、srcディレクトリ内のweb/index.phpを窓口としてそこから各処理が呼び出されて動作する形となっています。なのでブラウザからのアクセスは最初にweb/index.phpへ向かうようにする必要があります。

またアプリを設計するにあたっては、htmlファイルやcssファイルといった外部から直接アクセスされても問題ないファイル群はwebディレクトリへ、内部処理について記述しているphpファイルや.envファイルといったセキュリティ上リスクがあるファイル群はappディレクトリへそれぞれ配置しています。
つまりwebディレクトリは公開用、appディレクトリは非公開用のファイルを格納する作りとしています。

# src下ディレクトリ図（一部抜粋）
src
├── app    # 公開用ディレクトリ
│   ├── Application.php
│   # ...（ロジックファイル群）
└── web    # 非公開用ディレクトリ
    ├── css
    └── index.php

一方でapacheの設定はインストール時にはルートパス/アクセスでは/var/www/html内のindex.htmlが呼び出される形となっています。

なのでまずはアクセス制御がアプリの設計通りになるようapacheの設定を変更する必要があります。アプリのソースコードを以下のような位置に一部移したのち、apacheの設定を変更してアクセスがデフォルトで/var/www/web/indexへ向かうようにします。

/var/www
├── app  # 非公開ディレクトリ
│   ├── ...
└── web  # 公開ディレクトリ
    ├── css
    └── index.php

前置きが長くなりましたが、ここから実際に設定を行っていきます。
まずソースコードを/var/www/へ移動させてきます。以下コマンドでソースコードをコピーしてきます。

# ホームディレクトリへ移動してから実行
sudo cp -r weblog/src/* /var/www/

次にapacheの設定を行っていきます。以下コマンドで設定ファイルへ編集モードでアクセスします。

sudo vim /etc/httpd/conf/httpd.conf

そして以下の箇所を変更していきます。

# 公開ルートの設定
DocumentRoot "/var/www/web"    # 「/var/www/html」を「/var/www/web」へ変更
<Directory "/var/www/web">     # 「/var/www」を「/var/www/web」へ変更
    AllowOverride All          # NoneからAllへ変更
    Require all granted
</Directory>

# 初期アクセスパスの設定
<Directory "/var/www/web/index.php">  # 「/var/www/html」を「/var/www/web/index.php」へ変更
    Options Indexes FollowSymLinks
    Require all granted
</Directory>

変更を保存して編集モードを閉じたらapacheを再起動して設定を反映させます。

sudo systemctl restart httpd

再度WEBサーバ用EC2インスタンスへブラウザからアクセスし、以下のようなweb/index.phpファイルのコードが文字列で表示されれば設定が反映されています（PHPをまだEC2WEBサーバへインストールしていないので文字列表記となる）。

<?php

require_once __DIR__ . '/../vendor/autoload.php';

use App\Application;

$app = new Application();
$app->run();

ここまでできたら今度はPHPを以下コマンドでインストールしていきます。

# PHPインストール
sudo dnf install -y php8.4

# PDOインストール（DB接続時に必要）
sudo dnf install -y php-mysqlnd

# apache再起動で反映
sudo systemctl restart httpd

ここで一度、PHPがちゃんと動いているかを確認してみます。以下コマンドでweb/index.phpファイルを変更してみます。

sudo vim /var/www/web/index.php

現在のコードをコメントアウトして仮コードを打ってみます。

<?php
// require_once __DIR__ . '/../vendor/autoload.php';
// use App\Application;
// $app = new Application();
// $app->run();
echo "PHP is running!";

これでブラウザからアクセスしてPHP is running!と表示されればPHPのインストールもうまくいっています。

確認できたらweb/index.phpをもとの状態に戻し、アプリを動かすのに必要なライブライブ群のインストールを行っていきます。
今回はソースコードのcompose.jsonに必要なライブラリの情報をまとめているのでこれを用いてセットアップしていきます。そのためにcomposerが必要になるのでインストールを行っていきます。

sudo dnf install -y composer

完了したら/var/www/ディレクトリへ移動してcomposer.jsonがあるかを確認します。

cd /var/www/ && ls composer.json
composer.json    # composer.jsonと表示されればOK

composer.jsonと同階層にいることを確認したらライブラリのインストールを行っていきます。以下コマンドで実行できます。

sudo composer install
# Continue as root/super user [yes]? と出たら「yes」と入力してEnter

実行が完了してcomposer.jsonと同階層にvendorディレクトリが生成されていればOKです。

次にアプリの利用に必要なDBテーブルの作成を行います。/var/www/ディレクトリ内にあるDatabaseSetup.phpファイルの編集を行っていきます。以下コマンドで編集モードに入ります。

sudo vim DatabaseSetup.php

そしてソースコードのうちDB接続時に必要となるパラメータを以下のように変更します。

class DatabaseSetup
{
    public function run()
    {
        $hostname = '10.0.101.20'  // DBインスタンスのプライベートIP
        $database = 'test_db';
        $username = 'test_user';
        $password = 'User!1234';   // test_user作成時のパスワード

        // 以下の処理は省略
    }
}

変更できたら実際にファイルを実行してテーブル作成を行います。

php DatabaseSetup.php
# 「データベースの構築が完了しました」と表示されればOK

これでDBテーブルの作成は完了です。

最後にアプリ側の環境変数の設定を行います。以下コマンドで.envファイルを編集モードで開きます。

sudo vim app/Core/.env

そして以下のように変更して保存します。

HOST='10.0.101.201'  # DBインスタンスのIPアドレス
DB_USER='test_user'
DB_PASS='User!1234'  # test_user作成時のパスワード
DB_NAME='test_db'

これでアプリ側からDBへアクセスできるようになりデプロイは完了です。
ブラウザからアクセスするとweblogアプリのトップ画面が表示されることが分かると思います。

通信のHTTPS化

ここまでで一通りWeblogアプリのデプロイは行えましたが、現状ではHTTP通信となっているのでセキュリティ上のリスクが残っています。

現代のブラウザではHTTP通信でアクセスすると警告文が出てしまいユーザーに不安を与えてしまいます。また今回のアプリではログイン認証を行うのでHTTPではそもそもセキュリティリスクが大きいと言えます。そのためHTTPS化について扱うことにしました。

通信のHTTPS化には認証局の証明書が必要になります。証明書を自前で用意して実装する方法もあるのですが、今回は「AWS Certificate Manager（通称ACM）」というAWSのサービスを利用していきます。Certificate Managerを使うと簡単にHTTPS化ができ、なおかつ証明書の更新も自動で行ってくれるのでこちらを今回は扱います。

▸AWS構成について
構築方法ですが、外部からの通信をまずALB（Application Load Balancer）で受け取りCertificate Managerで処理したのちWEBサーバへ流すような形で実装していきます。

ALBの作成と設定

まずはALBの作成から行っていきます。

▸サブネットの準備（前準備）
ALBの使用には2つ以上のaz（アベイラビリティゾーン）が必要となるのですが、現在は単一azなのでazをまずは追加していきます。

azの1a、1c用のサブネットをまずは作成していきます。VPCページのサブネット一覧ページを開き、1aのazにいることを示すべく現在のサブネット名にそれぞれ「1a」とつけます。

そしてazが1cのパブリック・プライベートサブネットをそれぞれ作成します。
ここまでで1aと1cのそれぞれにパブリック・プライベートサブネットが存在する状態となります。

続けてルートテーブルの修正も行います。VPCのルートテーブル一覧からパブリックサブネットのルートテーブルを選択してサブネットの関連付けを編集していきます。

編集ページへ移ったら1a、1cのパブリックサブネットをチェックして「関連付けを保存」を押します。これでパブリックサブネットの変更は完了になります。

同様の手順でプライベートサブネットのルートテーブルも1a、1cのプライベートサブネットを追加します。
ここまでの操作でazが1aと1cでそれぞれパブリックサブネットとプライベートサブネットを用意することができたので前準備は完了です。

▸ALBの作成
ここからALBを実際に作成していきます。
EC2ページのロードバランサーから「ロードバランサーの作成」をクリックします。

ロードバランサーの種類選択が出てくるので「Application load Balancer」の作成ボタンをクリックします。

詳細の設定ページが出てくるので名前をweblog-alb、スキームは「インターネット向け」とします。

ネットワークマッピングの設定は、VPCは作成したものを選択します。
アベイラビリティゾーンとサブネットは1aと1cの作成したパブリックサブネットを選択します。

セキュリティグループは「Create cecurity group」をクリックして新規に作成していきます。

セキュリティグループ名はalb-sgとして作成したVPCを選択します。

インバウンドルールはHTTP通信のみ、ソースをAnywhereIPv4としてすべてのユーザーからのアクセスを許可します。

他の設定はデフォルトで「セキュリティグループを作成」をクリックします。
無事作成が完了したらALB設定ページに戻り、作成したalb-sgを選択します。

下にスクロールして、VPCは作成したweblog-vpcを選択、アベイラビリティゾーンにチェックを入れて作成したパブリックサブネットを選択します。

リスナーとルーティングではリスナーはデフォルトのHTTP：80としておき、ターゲットグループの新規作成を行います。

設定ページが出てくるので、ターゲットの種類はインスタンスを、ターゲットグループ名はweblog-tgとしてプロトコルはデフォルトのHTTP：80とします。

IPアドレスタイプはデフォルトのIPv4としてVPCは作成したものを選択します。その他はデフォルトのままで「次へ」をクリックします。

インスタンスの選択画面が出てくるので、インスタンス名がweb-serverのものをチェックして「保留中として以下を含める」をクリックします。

「ターゲットを確認」の部分にweb-serverが出てこれば「次へ」をクリックして「ターゲットグループを作成」をクリックします。

作成完了の画面が出てきたらALB設定ページへ戻り、先ほど作成したターゲットグループを選択します。

他はデフォルトのままで「ロードバランサーを作成」をクリックし、ステータスが「アクティブ」となればALBの設定は完了です。

ここで一度ALBが正常に動いているか確認してみましょう。ロードバランサーの一覧ページから作成したロードバランサーをクリックしてDNS名をコピーします。

そのうえでブラウザのURLに貼り付けて実行し、アプリへアクセスできれば正常に動作しています（プロトコルはhttpsではなくhttpで実行するようにしてください）。

ドメインの設定

次にドメインの設定を行っていきます。ドメインの登録が必要になるのでまずそちらを行い、その後名前解決の設定を行いドメイン名でアクセスできるようにしていきます。

▸ドメイン登録
最初にドメインの登録を行っていきます。今回はRoute53でドメインを発行しますが（ムームードメインのようなAWS外部サービスにて発行してもOK）。

Route53ページ「登録済みドメイン」から「ドメインを登録」をクリックして作成を行っていきます。

入力欄が出てくるので取得したいドメイン名を入れて「検索」を押します。

すると取得可能なドメインが一覧で出てくるので選択して「チェックアウトに進む」をクリックして決済に進みます。無事に決済が終わると発行処理が行われるので完了するまで待ちます（20分程度と少し時間がかかります）。

以下のように登録ドメインに作成したドメインが表示されていればドメインの作成は完了です。

▸名前解決の設定
Aレコードを追加して名前解決を行えるようにする、すなわちドメイン名でアプリへアクセスできるようにしていきます。

Route53ページのホストゾーンから使用したいドメイン名を選択してAレコードがない場合は「レコードを作成」をクリックします。
※ Aレコードがある場合は編集ページへアクセスします。

設定画面が出てくるので以下のように入力を行い「レコードを作成」をクリックします。

完了画面が表示されたら少し待ち、ステータスが「INSYNC」になればOKです。

この状態でhttp://reserveapp.orgのように取得したドメインでULRを打つとアプリにアクセスできることがわかります。

これでドメイン名からアクセスできるようになりました。

ACMを用いた証明書の発行

HTTPS通信に必要となる認証局の証明書発行を行っていきます。

▸証明書の発行
最初にCertificate Managerを使用してHTTPS通信に必要となる証明書の発行を行っていきます。

Certificate Managerページの「証明書をリクエスト」をクリックします。

するとまず証明書のタイプが出てくるのでデフォルトの「パブリック証明書をリクエスト」を選択して次へを押します。

続いてドメインの入力を求められるのでアプリのドメイン名を入力します。その他はデフォルトのままとして「リクエスト」をクリックします。

一覧ページへ戻り「発行済み」となれば証明書の発行は完了です。

証明書のアタッチ

発行された証明書をALBにアタッチしてHTTPS通信を使えるようにします。
EC2ページのロードバランサーから作成したALBを選択して、「リスナーとルール」から「リスナーの追加」をクリックします。

リスナーの設定画面が出てくるので、リスナーの部分はプロトコルを「HTTPS」としてターゲットグループを作成したものにします。他はデフォルトのままでOKです。

スクロールして、セキュアリスナーの設定の部分は証明書の取得先を「ACMから」として証明書（ACMから）でACMの証明書発行で設定したドメインを指定します。

他の部分はデフォルトのままで「リスナーを作成」をクリックします。
これで変更は反映されますが、セキュリティグループの方はHTTP通信の設定のままなのでHTTPSは到達不可能と出てしまいます。

なのでALBのセキュリティグループを一部変更していきます。
EC2ページのセキュリティグループから一覧を表示し、ALBのセキュリティグループを選択してインバウンドルールを編集していきます。

インバウンドルールの編集画面に移動したら、「ルールを追加」からHTTPSを追加します。HTTPと同様にすべてのユーザアクセスを許可するのでソースを「Anywhere-IPv4」として「ルールを保存」をクリックします。

これでHTTPSでのアクセスが可能となります。ブラウザ上でプロトコルをhttps://としてアクセスすると確かにHTTPSで通信できており、ブラウザ上でもセキュアに行われいることが分かります。

HTTPSへのリダイレクト処理

ここまででHTTPS通信でアプリへの接続が行えるようになりましたが、今のままではhttp://<ドメイン名>で検索するとHTTP通信でアプリへアクセスできてしまいます。

そこで最後に、HTTP通信でアクセスが来たら自動でHTTPSにリダイレクトしてHTTP通信では直接アプリの操作を行えないようにしていきます。

EC2のロードバランサー一覧ページから現在使用中のALBをチェックして「リスナーとルール」をクリックします。今回はHTTP通信の設定を変えたいのでHTTPにチェックを入れてリスナーの管理から編集をクリックします。

編集画面に移ったら「リスナーの詳細」の部分を一部変えていきます。
まずアクションのルーティングを「ターゲットグループへ転送」から「URLにリダイレクト」に変更します。「URLにリダイレクト」はHTTPSがデフォルトで選択されるのでポート番号を443と入力します。
そしてステータスコードはデフォルトの301のままでOKです。他の設定は変更せず、「変更内容の保存」をクリックすればリダイレクト設定は完了です。

curlコマンドを使うとわかりやすいのでターミナルで確認してみます。

curl -I -L http://reserveapp.org

# リダイレクトされていることを確認
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Content-Type: text/html
Location: https://reserveapp.org:443/

# リダイレクト先の情報を表示
HTTP/2 200
content-type: text/html; charset=utf-8
server: Apache/2.4.66 (Amazon Linux)

しっかりとHTTPのアクセスがHTTPSに一度リダイレクトされて、その後ステータス200となっていることからアプリへ正常にアクセスできていることが分かります。

まとめ

改めて今回のデプロイについて簡単にまとめます。
今回はWEBサーバとDBサーバ用として2台のEC2インスタンス用意しました。そしてサーバ内で環境構築を行い、ソースコードの環境変数の調整を行いデプロイを行いました。
また、ALBとACMを用いて通信のHTTPS化も行いました。

構成図にまとめると以下のようになります。