【AWS】シングル構成でWordPressのブログサービスを構築してみた

「AWSでWordPressのブログサービスを構築してみたいので、手順が知りたい」

このような疑問に対し、筆者がハンズオンで検証した手順をご紹介します。

本記事は、先日筆者が自己学習のために入会した AWS CloudTechという技術コミュニティの課題カリキュラムに沿って作成しております。

カリキュラムなどにご興味のあるかたは、以下リンクより公式ページにリンクできますので、内容をご覧になってみてはいかがでしょうか。
>> AWS CloudTech

この記事で分かること

• このハンズオンで目指す構成
• このハンズオン作業のゴール
• 筆者の環境
• 筆者が検証したハンズオンの手順
• 筆者がつまずいた箇所
• おわりに

このハンズオンで目指す構成

シングル構成とは

このハンズオン作業のゴール

構成図にある青い矢印の「HTTP」で、ローカルPCからインターネットを経由し、EC2にインストールしたWordPressのブログサイトにアクセスできるところまでをゴールとします。

今回は、個人的にとても気になっていたAWS上でブログサービスを構築について、AWS Cloud Techの学習カリキュラムで紹介されていたため、良いタイミングでハンズオンすることができました。

今回はWordPressをEC2にデプロイし、Webアプリサーバーとして外部公開する手順にトライしてみましたが、ほかのWebサービスについても、WordPressをご自身のサービスに置き換えることで、同様の構成で対応する事が可能です。

例えば、Redmineなどのプロジェクト管理ツールなども対応可能です。(筆者にて検証済)

筆者の環境

AWSでシングル構成でワードプレスのブログサービスを構築する手順の概要

1. step01 VPCを作成する
2. step02 サブネットを作成する
3. step03 インターネットゲートウェイを作成する
4. step04 ルートテーブルを作成する
5. step05 EC2を作成する
6. step06 RDSを作成する
7. step07 セキュリティグループを作成する
8. step08 WordPressをインストールする
9. step09 ローカルPCから疎通確認をする

はじめに、step01・step02・step03・step04でAWS上にネットワーク接続するためのベースを作成します。

つづいて、step05・step06・step07でEC2とRDSを用いて、WordPressをインストールするためのwebサーバーと、データベースを提供するためのRDSを作成します。

最後に、step08でWordPressをインストールし、step09でインターネット経由でブログサービスに接続できるか確認していきます。

step01 VPCを作成する

step01-02では以下の構成を作成します。

VPCを作成する手順

step02 サブネットを作成する

つづいて、サブネットを作成します。

今回の作業で作成するサブネット４つ

シングル構成にも関わらず、サブネットを4つ作る理由

VPC内にサブネットを作成する手順

step03 インターネットゲートウェイを作成する

step03とstep04では、以下のようにインターネットゲートウェイとルートテーブルを作成します。

インターネットゲートウェイとルートテーブルを作成して設定することにより、VPCに作成したインスタンスが外部と通信可能になります。

まずは、インターネットゲートウェイを作成していきます。

インターネットゲートウェイを作成する手順

step04 ルートテーブルを作成する

step04ではルートテーブルを作成します。今回は、Public Subnetに適用するルートテーブルとPrivate Subnetに適用するルートテーブルを計２つ作成します。

xcdfxsz

ルートテーブル作成の手順

Route Table Publicの作成

この設定により、Router Table Publicのルートテーブルについて以下が実現されます。

Route Table Privateの作成

この設定により、Router Table Privateのルートテーブルでは以下が実現されます。

step05 EC2を作成する

今回はPublic Subnet 1a にEC2を作成し、WordPressをインストールしたWebサーバーとして外部公開し、インターネット経由で閲覧可能にします。

EC2の作成

step06 Private Subnet 01 にRDSを作成する

RDSを作成する手順

サブネットグループを作成する

データベースを作成する

step07 セキュリティグループを作成する

セキュリティグループを作成し、EC2に適用する

RDS用セキュリティグループを編集する

次に、今回作成したセキュリティグループ：we-sgをRDSが所属するセキュリティグループのrds-sgに適用します。この操作により、RDSはEC2からの操作だけを受け付けるようになります。

step08 WordPressをインストールする

EC2にWordPressをインストールする手順

はじめに、Step05で作成したEC2にSSH接続します。筆者はWindows環境なので、TeraTermを利用して接続します。

EC2への接続

図A

図B

図C

図D

図E

WordPressのインストール

つづいて、EC2にWordPressをインストールします。

rootにスイッチ

$ sudo su -

yum（やむ）のパッケージをアップデート

# yum -y update

「Complete!」と表示されることを確認

PHPをインストール

# amazon-linux-extras install php7.2 -y

プロンプトがかえればOK

MySQL・Apache・PHPのモジュールをインストール

# yum -y install mysql httpd php-mbstring php-xml gd php-gd

「Complete!」と表示されることを確認

apacheの自動起動設定

# systemctl enable httpd.service

apacheのスタート

# systemctl start httpd.service

apacheのステータス確認

# systemctl status httpd.service

WordPressのインストールコマンド

# ll
# wget https://ja.wordpress.org/latest-ja.tar.gz ~/

※「ll」で現在のディレクトリに何もないことを確認します。
※コマンドの意味
「https://ja.wordpress.org/latest-ja.tar.gz」を「~/(現在のディレクトリ)」にダウンロードします。

「latest-ja.tar.gz」ファイルがダウンロードされたことを確認

# ll
-rw-r--r-- 1 root root 16304330 Feb 12 08:00 latest-ja.tar.gz

gzファイルを解凍

# tar zxvf latest-ja.tar.gz

プロンプトがもどればOK

wordpresssディレクトリが生成されたことを確認

# ll
-rw-r--r-- 1 root root 16304330 Feb 12 08:00 latest-ja.tar.gz
drwxr-xr-x 5 1006 1006     4096 Feb 12 08:00 wordpress

wordpresssディレクトリを「/var/www/html配下にコピー」

# cp -r ~/wordpress/* /var/www/html

コピーされたことを確認

# ll /var/www/html
total 216
-rw-r--r--  1 root root   405 Feb 20 11:50 index.php
-rw-r--r--  1 root root 19915 Feb 20 11:50 license.txt
-rw-r--r--  1 root root 10089 Feb 20 11:50 readme.html
-rw-r--r--  1 root root  7101 Feb 20 11:50 wp-activate.php
drwxr-xr-x  9 root root  4096 Feb 20 11:50 wp-admin
-rw-r--r--  1 root root   351 Feb 20 11:50 wp-blog-header.php
-rw-r--r--  1 root root  2328 Feb 20 11:50 wp-comments-post.php
-rw-r--r--  1 root root  3931 Feb 20 11:50 wp-config-sample.php
drwxr-xr-x  5 root root    69 Feb 20 11:50 wp-content
-rw-r--r--  1 root root  3939 Feb 20 11:50 wp-cron.php
drwxr-xr-x 25 root root  8192 Feb 20 11:50 wp-includes
-rw-r--r--  1 root root  2496 Feb 20 11:50 wp-links-opml.php
-rw-r--r--  1 root root  3300 Feb 20 11:50 wp-load.php
-rw-r--r--  1 root root 49831 Feb 20 11:50 wp-login.php
-rw-r--r--  1 root root  8509 Feb 20 11:50 wp-mail.php
-rw-r--r--  1 root root 20975 Feb 20 11:50 wp-settings.php
-rw-r--r--  1 root root 31337 Feb 20 11:50 wp-signup.php
-rw-r--r--  1 root root  4747 Feb 20 11:50 wp-trackback.php
-rw-r--r--  1 root root  3236 Feb 20 11:50 xmlrpc.php

所有者とグループをapacheに変更

# chown apache.apache -R /var/www/html

※オプション　-R　：再帰的に（配下のディレクトリも同様に）変更する

所有者とグループをapacheに変更されたことを確認

-rw-r--r--  1 apache apache   405 Feb 20 11:50 index.php
-rw-r--r--  1 apache apache 19915 Feb 20 11:50 license.txt
-rw-r--r--  1 apache apache 10089 Feb 20 11:50 readme.html
-rw-r--r--  1 apache apache  7101 Feb 20 11:50 wp-activate.php
drwxr-xr-x  9 apache apache  4096 Feb 20 11:50 wp-admin
-rw-r--r--  1 apache apache   351 Feb 20 11:50 wp-blog-header.php
-rw-r--r--  1 apache apache  2328 Feb 20 11:50 wp-comments-post.php
-rw-r--r--  1 apache apache  3931 Feb 20 11:50 wp-config-sample.php
drwxr-xr-x  5 apache apache    69 Feb 20 11:50 wp-content
-rw-r--r--  1 apache apache  3939 Feb 20 11:50 wp-cron.php
drwxr-xr-x 25 apache apache  8192 Feb 20 11:50 wp-includes
-rw-r--r--  1 apache apache  2496 Feb 20 11:50 wp-links-opml.php
-rw-r--r--  1 apache apache  3300 Feb 20 11:50 wp-load.php
-rw-r--r--  1 apache apache 49831 Feb 20 11:50 wp-login.php
-rw-r--r--  1 apache apache  8509 Feb 20 11:50 wp-mail.php
-rw-r--r--  1 apache apache 20975 Feb 20 11:50 wp-settings.php
-rw-r--r--  1 apache apache 31337 Feb 20 11:50 wp-signup.php
-rw-r--r--  1 apache apache  4747 Feb 20 11:50 wp-trackback.php
-rw-r--r--  1 apache apache  3236 Feb 20 11:50 xmlrpc.php

step09 ローカルPCから疎通確認をする

確認手順

図F

図G

以上でハンズオン作業終了です。

筆者がつまづいた箇所

セキュリティグループの設定もれが原因で、step09でWordPressにログインできず、1時間以上ハマってしまいました。

原因
デフォルトのセキュリティグループはHTTPのみ許可、本ハンズオン手順で作ったセキュリティグループ（web-sg）HTTPとSSHを許可なのですが、EC2に適用したセキュリティグループがデフォルトのままで、HTTPを許可していなかったため、WordPressにログインできませんでした。

ハマった理由
筆者としては、本ハンズオン手順のstep07でセキュリティグループ（web-sg）を作成した時点でEC2に適用したつもりになっており、SSH通信は出来ていたこともあり、セキュリティグループの設定は正しいとの思い込みでトラブル切り分け時の確認から外してしまっていたため、気づくまでに時間を要してしまいました。

つまづきからの学び
セキュリティグループにかぎらず、AWSでは何か設定を作成したら、それをアタッチしたり、適用したりする作業が多い印象なので、作業完了後は、作成した設定が正しく適用されているか見直すことで、無駄なトラブル対応時間を減らしたいと思います。

おわりに

この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。
AWSについて、基本からしっかり学びたい方にはオススメです！

https://aws-cloud-tech.com/

本記事がお役に立てれば幸いです。