3 度目の WordPress 構築 on AWS
このスクラップについて
このスクラップでは AWS 上に WordPress を構築する過程を記録していく。
1 回目
2 回目
やることリスト
- パスワード生成 → 完了
- メールアドレスの作成 → 完了
- アカウント作成 → 済
- EC2 起動 → 完了
- Elastic IP アドレスの取得・割り当て → 完了
- SSH 設定 → 完了
- HTTP サーバーインストール・設定(Override & Document Root) → 完了
- MariaDB サーバーインストール・DB 作成 → 完了
- PHP インストール・設定(タイムゾーンやアップロードサイズなど) → 完了
- WordPress インストール → 完了
- バックアップ用 S3 バケットの作成・ライフサイクル設定 → 完了
- ロールの作成 → 完了
- バックアップスクリプトの作成 → 完了
- CRON インストール・設定 → 完了
- 自動再起動設定 → 完了
- SNS トピック・サブスクリプション作成 → 完了
- CloudWatch アラーム設定 → 完了
- FTP サーバーインストール・設定 → 完了
- phpMyAdmin インストール・Basic 認証 → 完了
- WordPress 無限ループ対策 → 完了
- スワップ領域の作成 → 完了
- PHP FPM プロセス数調整 → 完了
- MariaDB の OOM スコア調整 → 完了
- プロセス監視 → 完了
- HTTPS 設定(ACM を使うケースと使わないケースがある)
設定開始
パスワード生成とメールアドレス作成が完了、アカウントは作成済みだった。
次は EC2 起動だが、インスタンスタイプはどれを選べば良いのだっけ?
確認したところ t3.small だった。
EC2 起動
インスタンスタイプを含め全く同じだった。
Elastic IP アドレスと SSH ログイン
こちらも手順通りで大丈夫だった。
HTTP + PHP インストールと設定
今回は PHP バージョン 8.1 指定がある。
sudo yum install php8.1 php8.1-gd php8.1-mbstring php8.1-mysqlnd php8.1-pdo
8.1.27 がインストールされた。
MariaDB サーバー
こちらも手順通りで大丈夫だった。
データベース作成
こちらも無事に完了した。
PHP 設定
確認はしていないが手順自体は完了した。
WordPress インストール
こちらも手順通りで大丈夫だった。
IP アドレスでアクセスできないなーと思っていたら https にアクセスしていた。
DocumentRoot 変更
WordPress をインストールしたら DocumentRoot を /var/www/html/wordpress に変更する。
変更点は 2 箇所ある。
sudo vi /etc/httpd/conf/httpd.conf
sudo systemctl restart httpd
WordPress 設定
こちらも手順通りでできた。
ここまでの作業時間
45 分間で WordPress 設定まで完了できた。
次はバックアップ用の S3 バケットを作成しよう。
S3 バケット作成
ついでにライフサイクルポリシーを設定した。
ロールの作成
ロール名は WordPressRole などにした方が良さそう。
- AmazonSSMManagedInstanceCore
- CloudWatchAgentServerPolicy
手順を変えてロールを作成してから EC2 ページへ行ってアタッチした。
念のためここで再起動しておこう。
バックアップスクリプトの作成
こちらも手順通りで大丈夫だった。
CRON インストールと設定
こちらも手順通り設定したが動作確認は翌日以降にする必要がある。
自動再起動
こちらも明日以降に last reboot
で確認する。
SNS トピックとサブスク作成
リージョンを間違えないように気をつけよう。
CloudWatch アラーム作成
こちらも手順通りで大丈夫だったが動作確認できないので若干不安だ。
FTP 設定
こちらも手順通りで大丈夫だった。
phpMyAdmin のインストールと設定
http.conf で <Directory "/var/www/htm/wordpressl">
のようになっていてロスしてしまった。
WordPress 無限ループ対策
ALB 使わないかも知れないが一応設定しておいた。
スワップ領域作成
容量は 4 GiB にしておいた。
が参考になりそう。
PHP FPM プロセス数調整
こちらも手順通りだが設定反映に reload ではなく restart を使用した。
top
コマンドを使って php-fpm のプロセス数を確認した。
OOM Score 調整
反映コマンドに sudo がないことに今気がついた。
プロセス監視
前回は好奇心のせいで失敗したので手順に従おう。
Quick Setup が Host Management である点は画像が必要かも。
またインスタンスがたくさんある場合は手動で指定する必要がある。
確認コマンドは下記が良さそうだ。
sudo systemctl status amazon-ssm-agent
sudo systemctl is-enabled amazon-ssm-agent
出力オプションで「S3 バケットへの書き込みを有効化する」のチェックを外しても良さそう。
Restart mariadbd と Restart httpd で 2 つのアラームを作成している。
動作確認するには mariadbd と httpd を止めてみる。
sudo systemctl stop httpd
sudo systemctl stop mariadb
アクションとしては EC2 再起動、条件は 1 分間の平均値が 0 以下としている。
そしてインスタンスタイプを更新したらアラームも変更する必要があるようだ。
あとは証明書
ACM を使うのか使わないのかを確認する必要がある。
ここまでの作業時間
1.25 時間追加で合計 2 時間になった。
証明書の設定があると +0.5 時間くらいになるだろうか。
ALB 構築
ACM で発行済みの証明書を使って ALB を構築する。
基本設定通りでできたがターゲットグループでステータスチェックを 200,301
と指定する必要があった。
WordPress アドレスとサイトアドレスを本番用に変更する、こうするとアクセスできなくなって焦るがしょうがない。
次は ALB の IP アドレスを調べて hosts を設定する。
nslookup wordpress-alb-xxxx.ap-northeast-1.elb.amazonaws.com
Mac の場合は /private/etc/hosts を編集すれば良いようだ。
また、ロードバランサーの HTTP:80 のルールでアクションのルーティングを「URL にリダイレクト」URL にリダイレクトを「URI 部分」プロトコルを「HTTPS」ポートを「443」に指定しないと HTTP → HTTPS に転送されなかった。
作業時間はなんだかんだで 45 分くらいかかったか。
後から hosts の IP アドレスと alb のホスト名を連絡しておこう。
なんか前は IP アドレスで HTTP アクセスしたらホスト名 + HTTPS に転送された気がしたが、なぜ今回は転送されないんだろう。
PHP のバージョンを 7 に落とす
なんとソースからインストールする必要があるようだ。
簡単なことではなさそうだ。