
「AWSでWordPressのブログサービスを構築してみたいので、手順が知りたい」
このような疑問に対し、筆者がハンズオンで検証した手順をご紹介します。
本記事は、先日筆者が自己学習のために入会した AWS CloudTechという技術コミュニティの課題カリキュラムに沿って作成しております。
カリキュラムなどにご興味のあるかたは、以下リンクより公式ページにリンクできますので、内容をご覧になってみてはいかがでしょうか。
>> AWS CloudTech
この記事で分かること
- このハンズオンで目指す構成
- このハンズオン作業のゴール
- 筆者の環境
- 筆者が検証したハンズオンの手順
- 筆者がつまずいた箇所
- おわりに
このハンズオンで目指す構成
シングル構成とは
このハンズオン作業のゴール
構成図にある青い矢印の「HTTP」で、ローカルPCからインターネットを経由し、EC2にインストールしたWordPressのブログサイトにアクセスできるところまでをゴールとします。
今回は、個人的にとても気になっていたAWS上でブログサービスを構築について、AWS Cloud Techの学習カリキュラムで紹介されていたため、良いタイミングでハンズオンすることができました。
今回はWordPressをEC2にデプロイし、Webアプリサーバーとして外部公開する手順にトライしてみましたが、ほかのWebサービスについても、WordPressをご自身のサービスに置き換えることで、同様の構成で対応する事が可能です。
例えば、Redmineなどのプロジェクト管理ツールなども対応可能です。(筆者にて検証済)
筆者の環境
ローカル開発環境 | Windows10からブラウザよりAWSマネジメントコンソールに接続して作業 |
EC2のOS | Amazon Linux 2 |
SQLエンジン | MySQL |
SSH通信 | TeraTermを利用 |
作図 | dwarioのAWS19アイコンを利用 |
AWSでシングル構成でワードプレスのブログサービスを構築する手順の概要
- step01 VPCを作成する
- step02 サブネットを作成する
- step03 インターネットゲートウェイを作成する
- step04 ルートテーブルを作成する
- step05 EC2を作成する
- step06 RDSを作成する
- step07 セキュリティグループを作成する
- step08 WordPressをインストールする
- step09 ローカルPCから疎通確認をする
はじめに、step01・step02・step03・step04でAWS上にネットワーク接続するためのベースを作成します。
つづいて、step05・step06・step07でEC2とRDSを用いて、WordPressをインストールするためのwebサーバーと、データベースを提供するためのRDSを作成します。
最後に、step08でWordPressをインストールし、step09でインターネット経由でブログサービスに接続できるか確認していきます。
step01 VPCを作成する
VPCを作成する手順
> VPCダッシュボード
> 左ペイン
> 「VPC」をクリック
> 右上の「VPCを作成」をクリック
> VPC を作成 > VPC の設定 より以下を入力
名前タグ – オプション | 任意のVPC名 今回は「VPC」と記載 |
IPv4 CIDR ブロック | 任意のIPアドレスブロック※ 今回は「172.16.0.0/16」と記載 |
その他の項目 | デフォルトのまま |
IPv4 CIDRについて
VPCの中で利用するアドレスブロックはプライベートIPアドレスを利用すれば大丈夫。今回はクラスBのプライベートIPアドレスを使用しました。
プライベートアドレスに関する詳細は、以下のJPNICのページが参考になります。
>> 【JPNIC公式ページ】閉じたインターネットの為のアドレス割り振り
step02 サブネットを作成する
つづいて、サブネットを作成します。
今回の作業で作成するサブネット4つ
AZ ap-northeast-1a |
・Public Subnet 1a (172.16.1.0/24) ・Private Subnet 1a (172.16.2.0/24) |
AZ ap-northeast-1c |
・Public Subnet 1c (172.16.3.0/24) ・Private Subnet 1c (172.16.4.0/24) |
シングル構成にも関わらず、サブネットを4つ作る理由
理由その1
SubnetをPublicとPrivateに分けた理由は以下の構成にするためです。
・WebサーバーをPublicSubnetに配置してインターネット公開する。
・RDSで作成したDBをPrivateSubnetに配置してインターネット非公開にする。
理由その2
AZを「ap-northeast-1a」「ap-northeast-1c」の2つに分けた理由は、RDSはAWSの仕様上、マルチAZに登録する必要があるためです。
理由その3
PublicSubnetを「ap-northeast-1a」「ap-northeast-1c」にそれぞれひとつづつ作成した理由は、将来的にEC2をマルチAZに配置して、冗長構成にも対応可能な設計にするためです。
VPC内にサブネットを作成する手順
> VPCダッシュボード
> 左ペイン > 「サブネット」をクリック
> 「サブネットを作成」をクリック
> 「サブネットを作成」画面で以下を入力
(例として、「Public Subnet 1a」の作成手順をご紹介します。)
VPC > VPC ID | step01で作成した「VPC」を選択 |
サブネットの設定 > サブネット名 | Public Subnet 1a |
サブネットの設定 > アベイラビリティゾーン | 「アジアパシフィック(東京)/ap-northeast-1a」を選択 |
サブネットの設定 > IPv4 CIDRブロック | 「172.16.1.0/24」と記載 |
> 残りのサブネット3つに対しても同様に作成
> サブネット画面で今回作成した4つのサブネットが記載されていることを確認
step03 インターネットゲートウェイを作成する
step03とstep04では、以下のようにインターネットゲートウェイとルートテーブルを作成します。
インターネットゲートウェイとルートテーブルを作成して設定することにより、VPCに作成したインスタンスが外部と通信可能になります。
インターネットゲートウェイを作成する手順
> VPCダッシュボード
> 左ペイン > 「インターネットゲートウェイ」をクリック
> 「インターネットゲートウェイの作成」をクリック
> インターネットゲートウェイの作成 > インターネットゲートウェイの設定 > 名前タグに任意の名前を記載する。今回は「IGW」とする。
> 「インターネットゲートウェイの作成」をクリック
> インターネットゲートウェイの画面に戻ったら、上記で作成した「IGW」にチェックを入れる。
> 右上のアクション > VPCにアタッチ をクリックする
> VPCにアタッチ > 使用可能なVPCにstep01で作成した「VPC」を選択する
> 「インターネットゲートウェイのアタッチ」をクリックする
> 以下のように、作成した「IGW」の状態が「Attached」になっていることを確認する
step04 ルートテーブルを作成する
step04ではルートテーブルを作成します。今回は、Public Subnetに適用するルートテーブルとPrivate Subnetに適用するルートテーブルを計2つ作成します。
xcdfxsz
ルートテーブル作成の手順
Route Table Publicの作成
> VPCダッシュボード
> 左ペイン > 「ルートテーブル」をクリック
> 画面右上のルートテーブルの作成をクリック
> ルートテーブルの作成で以下を入力
名前タグ | Route Table Public |
VPC | step01で作成した「VPC」を選択 |
> 作成した「Route Table Public」の左側にチェックを入れる
> 画面下側でルート > ルートの編集をクリック
> ルートの編集 > ルートの追加をクリック
> 以下のテーブルを記載
送信先 | 0.0.0.0/0 |
ターゲット | step03で作成したインターネットゲートウェイ(今回は「IGW」)を選択 |
> ルートテーブルの作成の画面に戻り、以下の表示になっていることを確認
> 今回 Route Table Publicに関連付けをする「Public Subnet 1a (172.16.1.0/24)」と「Public Subnet 1C (172.16.3.0/24)」を選択し、「保存」をクリック
この設定により、Router Table Publicのルートテーブルについて以下が実現されます。
・その他の送信先:0.0.0.0/0のトラフィックに関しては、IGWに転送される。
Route Table Privateの作成
> VPCダッシュボード
> 左ペイン > 「ルートテーブル」をクリック
> 画面右上のルートテーブルの作成をクリック
> ルートテーブルの作成で以下を入力
名前タグ | Route Table Private |
VPC | step01で作成した「VPC」を選択 |
※作成した「Route Table Private」では、ルートの追加はしません。理由はローカル以外と通信しないためです。
> ルートテーブルの作成の画面にもどる
> つづいて画面下側のタブ > サブネットの関連付け > 「サブネットの関連付けの編集」をクリック
> 今回 Route Table Privateに関連付けをする「Private Subnet 1a (172.16.2.0/24)」と「Private Subnet 1C (172.16.4.0/24)」を選択し、「保存」をクリック
この設定により、Router Table Privateのルートテーブルでは以下が実現されます。
step05 EC2を作成する
今回はPublic Subnet 1a にEC2を作成し、WordPressをインストールしたWebサーバーとして外部公開し、インターネット経由で閲覧可能にします。
EC2の作成
> EC2ダッシュボード
> 「インスタンスを起動」をクリック
> 以下のように選択し、作成をクリック
ステップ1 Amazon マシンイメージ (AMI) |
「Amazon Linux 2 AMI (HVM), SSD Volume Type」を選択 |
ステップ2 インスタンスタイプの選択 |
t2.micro(無料利用枠の対象)を選択 |
ステップ3 インスタンスの詳細の設定 |
以下の3カ所を選択/それ以外はデフォルトでOK (1)ネットワーク :VPC (今回作成したVPC) (2)サブネット :Public Subnet 1a (今回作成したEC2を設置するサブネット) (3)自動割り当てパブリック IP :有効 ※後ほど、TeraTermでSSH接続ため有効にします |
ステップ4 ストレージの追加 |
デフォルトのままでOK |
ステップ5 タグの追加 |
Name :wordpress-01 |
ステップ6 セキュリティグループの設定 |
いったんデフォルトのまま |
ステップ7 インスタンス作成の確認 |
設定に問題ないか確認し、「起動」をクリック |
※キーペアのダウンロードチャンスは1回限りなので、キーペアの管理は慎重しましょう。
step06 Private Subnet 01 にRDSを作成する
RDSを作成する手順
サブネットグループを作成する
> Amazon RDS ダッシュボード
> サブネットグループをクリック
> 「DBサブネットグループを作成」をクリック
> DBサブネットグループを作成 の画面で以下を入力
サブネットグループの詳細 | |
名前 | wordpress-db-subnet group |
説明 | wordpress-db-subnet group |
VPC | VPC(今回)作成したVPC |
サブネットを追加 | |
アベイラビリティゾーン |
ap-northeast-1a ap-northeast-1c |
サブネット |
172.16.2.0/24 172.16.4.0/24 |
データベースを作成する
> Amazon RDS ダッシュボード
> データベースをクリック
> 「データベースの作成」をクリック
> データベースの作成 の画面で以下を設定する
データベースの作成方法を選択 | 標準作成 |
エンジンのオプション | |
エンジンのタイプ | MySQL |
その他 | デフォルトのまま |
テンプレート | 開発/テスト |
設定 | |
DBクラスター識別子 | デフォルトのまま |
マスターユーザー名 | wordpress |
マスターパスワード | 任意 (今回は wordpress と設定) |
DBインスタンスサイズ | バースト可能クラス db.t3.micro |
可用性と耐久性 | デフォルトのまま |
接続 | |
Virtual Private Cloud | VPC (今回作成したVPC)を選択 |
サブネットグループ | wordpress-db-subnet group (今回作成したサブネットグループ)を選択 |
パブリックアクセス可能 | なし |
VPCセキュリティグループ |
新規作成 > Name : rds-sgを作成 ※名前以外はデフォルトのまま |
追加設定 | wordpress |
その他 | デフォルトのまま |
step07 セキュリティグループを作成する
セキュリティグループを作成し、EC2に適用する
> EC2 ダッシュボード
> 左ペイン
> セキュリティグループをクリック
> 「セキュリティグループを作成」をクリック
> 「セキュリティグループを作成」画面で、以下を作成
基本的な詳細 | |
セキュリティグループ名 | web-sg |
説明 | web-sg |
VPC | VPC (今回作成したVPC) |
インバウンドルール |
タイプ:HTTPS/ソース:0.0.0.0/0 タイプ:SSH/ソース:0.0.0.0/0 |
その他 | デフォルトのまま |
> step05で作成したEC2(今回はwordpress01)を選択
> 画面右上 > アクション > セキュリティ > セキュリティグループを変更 をクリック
> セキュリティグループを変更の画面 > 関連付けされたセキュリティグループ > 「削除」をクリック
(現在関連付けされているデフォルトのセキュリティグループを削除する)
> 今回作成したセキュリティグループ(web-sg)を選択
> 「保存」をクリック
RDS用セキュリティグループを編集する
次に、今回作成したセキュリティグループ:we-sgをRDSが所属するセキュリティグループのrds-sgに適用します。この操作により、RDSはEC2からの操作だけを受け付けるようになります。
> EC2 ダッシュボード
> 左ペイン
> セキュリティグループをクリック
> 今回、RDS用に作成したセキュリティグループ(rds-sg)をクリック
> 「インバウンドルールを編集」をクリック
> ソースを「×」ボダンで一旦削除する
> つづいて今回EC2に適用したセキュリティグループ:web-sgを選択しする
> 「ルールを保存」をクリックする
step08 WordPressをインストールする

EC2にWordPressをインストールする手順
はじめに、Step05で作成したEC2にSSH接続します。筆者はWindows環境なので、TeraTermを利用して接続します。
EC2への接続
> EC2
> 実行中のインスタンス
> 今回作成したEC2:wordpress-01をクリック
> インスタンスのパブリックIPを確認 図A
※今回の例:3.113.25.2
> 上記で確認したパブリックIPに対し、TeratermでSSH接続・・・図B-C-D
※図Dのように、step05で作成したSSHの秘密鍵「***.pem」ファイルを利用して接続する。
> ログインできたことを確認 図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から疎通確認をする
確認手順
> 以下の画面表示となることを確認
・ユーザー名 wordpress
・データベースのホスト名 RDSのエンドポイント名
・その他 デフォルトのまま
> AWSマネジメントコンソール
> RDSダッシュボード
> 左ペイン
> データベース
> 今回作成したデータベース識別子:dadavase-1 をクリック
> database-1の詳細画面で、接続とセキュリティのタブでエンドポイントを確認 図F
・ユーザー名 test user
・パスワード admin(今回step06で設定したもの)
> WordPressにログインできたことを確認 図G
以上でハンズオン作業終了です。
筆者がつまづいた箇所
セキュリティグループの設定もれが原因で、step09でWordPressにログインできず、1時間以上ハマってしまいました。
原因
デフォルトのセキュリティグループはHTTPのみ許可、本ハンズオン手順で作ったセキュリティグループ(web-sg)HTTPとSSHを許可なのですが、EC2に適用したセキュリティグループがデフォルトのままで、HTTPを許可していなかったため、WordPressにログインできませんでした。
ハマった理由
筆者としては、本ハンズオン手順のstep07でセキュリティグループ(web-sg)を作成した時点でEC2に適用したつもりになっており、SSH通信は出来ていたこともあり、セキュリティグループの設定は正しいとの思い込みでトラブル切り分け時の確認から外してしまっていたため、気づくまでに時間を要してしまいました。
つまづきからの学び
セキュリティグループにかぎらず、AWSでは何か設定を作成したら、それをアタッチしたり、適用したりする作業が多い印象なので、作業完了後は、作成した設定が正しく適用されているか見直すことで、無駄なトラブル対応時間を減らしたいと思います。
おわりに
この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。
AWSについて、基本からしっかり学びたい方にはオススメです!
本記事がお役に立てれば幸いです。