⚙️

AWSでWordPressブログを立ち上げる

2021/01/25に公開

背景

業務でAWSを触っていることはあるが、実際にインフラを一から構築することがほとんどないので、勉強も兼ねて構築してみることにした。

ゴール

AWSを使って環境を構築し、インターネットからHTTPでWordPressサイトにアクセスできるようになることがゴールである。

構成


今回作成を目指す構成

今回作成を目指す構成は上記の図の通り。

簡単なAWSの構成で、WordPressをインストールしたEC2, RDS, Internet Gateway, Application Load Balancer (ALB) からなる。

設定を行うため、EC2へはインターネットからSSHで接続できるようにしておき、実際のブログへのアクセスはALB経由でHTTPで通信する。
※EC2へインターネットからSSH接続できることに関してセキュリティ面で問題はあるが今回は目を瞑ることにする。

ALBは実際なくても良いが、今後Multi-AZ構成を取ることを想定した場合に必要となるため利用する。

実際に構築してみる

1. VPCの作成

まず、VPCを作成する。

  • AWSのマネージメントコンソールにログインし、サービス > VPCを選択する。
    下図のように左ペインから「VPC」を選択し、「VPCを作成」を押下。
  • 設定画面で以下を設定し、「VPCを作成」を押下
項目 設定値
名前タグ MyVPC1
IPv4 CIDRブロック 10.0.0.0/16
タグ Name: MyVPC1

2. Subnetの作成

次にサブネットを作成する。

  • 下図のように左ペインから「サブネット」を選択し、「サブネットを作成」を押下。
  • 設定画面で以下を設定し、「サブネットを作成」を押下
項目 設定値
VPC MyVPC
サブネット名 PublicSubnetA
アベイラビリティゾーン ap-northeast-1a
IPv4 CIDRブロック 10.0.1.0/24
タグ Name: PublicSubnetA

同様に、以下の設定でPublicSubnetC, PrivateSubnetA, PrivateSubnetCを作成する。

項目 設定値
VPC MyVPC
サブネット名 PublicSubnetC
アベイラビリティゾーン ap-northeast-1c
IPv4 CIDRブロック 10.0.3.0/24
タグ Name: PublicSubnetC
項目 設定値
VPC MyVPC
サブネット名 PrivateSubnetA
アベイラビリティゾーン ap-northeast-1a
IPv4 CIDRブロック 10.0.2.0/24
タグ Name: PrivateSubnetA
項目 設定値
VPC MyVPC
サブネット名 PrivateSubnetC
アベイラビリティゾーン ap-northeast-1c
IPv4 CIDRブロック 10.0.4.0/24
タグ Name: PrivateSubnetC

すると、一覧画面に以下のように、作成したサブネットが表示される。
※検索ボックスに「My」と入力するとMyVPC内に作成したサブネットが表示される。

これにより、以下のようなVPCとサブネットが作成された。

3. EC2の作成

ここから実際にWordPressをインストールするEC2インスタンスを作成し、PublicSubnetAに配置する。

  • サービス > EC2を選択する。

  • 下図のように左ペインから「インスタンス」を選択し、「インスタンスを作成」を押下。
     

  • ステップ1: AMIの選択
     以下のAMIを選択
      Amazon Linux 2 AMI (HVM), SSD Volume Type

  • ステップ2: インスタンスタイプの選択
    下図の通り、t2.microを選択し、「インスタンスの詳細の設定」を押下
      

  • ステップ3: インスタンスの詳細の設定
     下図の通り設定し、「ストレージの追加」を押下
     

項目 設定値
ネットワーク MyVPC
サブネット PublicSubnetA
自動割り当てパブリックIP 有効

なお、自動割り当てPublic IPを設定しておくことで、インターネットからアクセスするためのPublic IPが払い出される。

  • ステップ4: ストレージの追加
     デフォルトの設定のまま、「タグの追加」を押下
     

  • ステップ5: タグの追加
     Nameタグ「WebServer」を設定

  • ステップ6: セキュリティグループの設定
     下図のように設定

項目 設定値
セキュリティグループの割り当て 新しいセキュリティーグループを作成する
セキュリティグループ名 Web-SG-1
説明 Web-SG-1

デフォルトで22番ポートのSSHが0.0.0.0/0(インターネット)からアクセス可能になっているため、追加では設定しない。
HTTPの設定は後ほど追加する。

  • ステップ7: インスタンス作成の確認
     問題なければ、「起動」を押下
     
     
     

    ここで、キーペアの作成画面が表示されるので、新しいキーペアの作成を選択し、キーペア名「MyKeyPair」とし、キーペアをダウンロードしておく。

    その後、「インスタンスの作成」を押下

これでインスタンス作成が完了した。

一覧から、作成した「WebServer」が確認できる。

ここまでで以下の構成ができた。

4. Internet Gatewayの作成と設定

このままではEC2はインターネット経由でアクセスできないため、Internet Gatewayの配置と、ルーティングの設定を行う。

① Internet Gatewayの作成

  • サービス > VPC を選択する。

  • 下図のように左ペインから「インターネットゲートウェイ」を選択し、「インターネットゲートウェイの作成」を押下。
     この時、存在しているInternet GatewayはデフォルトVPCにアタッチされているものである。
     

  • 下図のように設定し、「インターネットゲートウェイの作成」を押下。
     

項目 設定値
名前タグ My-InternetGateway
タグ Name: My-InternetGateway

これでInternet Gatewayの作成が完了したが、これではまだMyVPCにアタッチされていない状態であり、「Detached」となっている。

② Internet Gatewayのアタッチ

  • 「My-InternetGateway」を選択し、「アクション」から「アタッチ」を押下する。
  • そこで表示される画面で「MyVPC」を選択し、「インターネットゲートウェイのアタッチ」を選択

上記手順で、Internet Gateway一覧画面で、「Attached」になっていることが確認できる。
※画像がなくてすみません。

③ ルーティングの設定

ここまでで、Internet Gatewayの作成と、アタッチをした。

このままだとWebServerが配置されているPublicSubnetAがインターネットに通信するルートがないため、ルーティングの設定を行う。

  • 左ペインから「サブネット」を押下し、PublicSubnetAの詳細を確認する。
  • 「ルートテーブル」のタブを選択すると、下図のようにルーティングの設定が確認できる。

    現在はデフォルトのルーティングのみが設定されている。
    これは、1.0.0.0/16へのアクセスはlocalにルーティングされること意味し、この設定によりVPC 内のインスタンスが相互に通信できるようになる。
  • ルートテーブルを編集するために、ルートテーブルのIDを押下する。
  • 以下のようにルートテーブル一覧画面が表示される。
  • 「ルート」タブから「ルートの編集」を押下する。
  • 「ルートの追加」を押し、下図のようにルートを追加する。 
項目 設定値
送信先 0.0.0.0/0
ターゲット My-InternetGatewayを選択

これでルーティングの設定が完了し、以下の構成となった。

④ EC2への接続確認

この状態になるとSSHでインターネットから接続できるようになるため、EC2作成時にダウンロードしたキーペアを利用してSSHでログインしてみる。

利用しているクライアントはRLogin
http://nanno.dip.jp/softlib/man/rlogin/

画像がないが、接続できることを確認した。

5. ALBの作成

ここまでの設定だと、SSHはインターネット経由で接続できるが、HTTPは通信できないため、ALBを立ててそれを経由でHTTP通信ができるようにする。

  • サービス > EC2を選択する。
  • 下図のように左ペインから「ロードバランサー」を選択し、「ロードバランサーの作成」を押下。
  • ロードバランサーの種類の選択において、今回はHTTPでアクセスするため、「Application Load Balancer」を選択。
  • ロードバランサーの設定で下図のように設定をする。
項目 設定値
名前 My-ALB-1
スキーム インターネット向け
VPC MyVPC
アベイラビリティゾーン PublicSubnetA, PublicSubnetC
タグ Name: My-ALB-1

ここで、アベイラビリティゾーンが一つであるとエラーが表示される。
必ず2つ以上のアベイラビリティゾーンを選択する必要があるため、あらかじめPublicSubnetA, Cをそれぞれ作成していたのである。

  • セキュリティ設定の構成
     HTTPのみの通信であるため本設定はスキップし、「セキュリティーグループの設定」を押下。

  • セキュリティグループの設定
     下図のように新しいセキュリティグループ ALB-SG-1を追加する。

     ALBはHTTPのすべてのIPからリクエストを受け付けるため、設定はデフォルトのまま。

  • ルーティングの設定
    ロードバランサーがリクエストをルーティングするための設定をする。
     

項目 設定値
ターゲットグループ 新しいターゲットグループ
名前 My-TG-1
ターゲットの種類 インスタンス
ヘルスチェック(プロトコル) HTTP
ヘルスチェック(プロトコル) /healthcheck/check

ここで、ALBはWebServerにリクエストを送信するため、ターゲットは「インスタンス」に設定する。また、ヘルスチェックはドキュメントルートからのパスを記載する。ここでは、この後新たに作成する/healthcheck/checkなるファイルにした。

  • ターゲットの登録
    画面下部にターゲットとして登録できるインスタンス一覧が表示されるので、WebServerを選択し、「登録済みに追加」を押下する。
    すると、登録済みターゲットにWebServerが登録されるので、「確認」を押下。

  • 確認
     確認画面が表示されるので問題なければ「作成」を押下する。
     

これでALBが作成され、WebServerに接続するための準備ができた。
ただし、WebServerのセキュリティグループでは、HTTP通信を許可していないため以下の設定を追加する必要がある。

  • セキュリティグループ > Web-SG-1を選択し、インバウンドルールを編集を押下し、ルールを追加する。
項目 設定値
タイプ HTTP
ソース ALB-SG-1

ここまでの設定で、インターネットからHTTPでWebServerにアクセスできる構成となった。

6. RDSの作成

ここでは、WordPressに必要なデータベースの作成を行う。
EC2にデータベースエンジンをインストールすることもできるが、セキュリティの面や設計的に、データベースが別のサーバーに存在するほうが好ましい。何よりも、マネージドサービスであるRDSを活用したほうが運用面でかなり楽になる。

① サブネットグループの作成

サブネットグループとは、複数のサブネットをグルーピングしたものです。
RDSにおいては、冗長性の観点から、複数のAZに存在するサブネットをグルーピングしたサブネットグループ内に作成しなければならないという決まりがあるとのこと。

以下のように作成する。

  • サービス > RDS を選択する。
  • 左ペインから「サブネットグループ」を選択し、「サブネットグループの作成」を押下。
  • 下図のように設定を追加
項目 設定値
名前 My-SubnetGroup
説明 My-SubnetGroup
VPC MyVPC
アベイラビリティゾーン ap-northeast-1a, ap-northeast-1c
サブネット PrivateSubnetA, PrivateSubnetC

② データベースの作成

実際にデータベースの作成を行う。

  • 左ペインから「データベース」を選択し、「データベースの作成」を押下。

  • 以下の図のように設定する。
    キャプチャが分かれてしまって見づらいことはご了承ください。





項目 設定値
作成方法 標準作成
エンジンタイプ MySQL
テンプレート 開発/テスト
マスターユーザ名 wordpress
※wordpressの仕様とのこと
パスワード 任意
DBインスタンスサイズ db.t3.micro
デフォルトだとかなりハイスペックなのでお金がかなりかかるみたい
VPC MyVPC
サブネットグループ My-SubnetGroup
VPCセキュリティグループ RDS-SG-01
アベイラビリティゾーン PrivateSubnetA
最初のデータベース名 wordpress
※wordpressの仕様とのこと
  • 「データベース作成」を押下
     以下のようにデータベースが作成される。
     

③ データベースの設定

上記でセキュリティグループを作成したが、デフォルトのままだとWebServerからのリクエストを受け付けることができない。

そこで、RDSのセキュリティグループの設定を変更する。

  • サービス > VPC を選択する。

  • 左ペインから「セキュリティグループ」を選択し、「RDS-SG-1」を押下。

  • 「インバウンドルール」のタブを選択し、「インバウンドルールの編集」を押下。

  • デフォルトで設定されている「ソース」を削除し、Web-SG-1を設定する。

  • 「ルールの保存」を押下

これで、WordPressを動かす環境は整った。

7. WordPressのインストールと設定

ここからWebServerにSSHでログインし、WordPressをインストールする。

  • EC2にSSHで接続する。
  • 管理者権限にスイッチ
sudo su - 
  • パッケージを最新化する。
yum -y update
  • WordPressが動くのに必要なphpをインストールする。
amazon-linux-extras install php7.2 -y

(参考)amazon-linux-extrasコマンドについて
https://dev.classmethod.jp/articles/how-to-work-with-amazon-linux2-amazon-linux-extras/

  • MySQLクライアント、Apacheなどインストールする。
yum -y install mysql httpd php-mbstring php-xml gd php-gd

(参考)
php-mbstring : phpでマルチバイト文字列を扱う関数を利用するのに必要なパッケージ
php-xml : phpでXMLを扱う関数を利用するのに必要なパッケージ
gd, php-gd : wordpressで使う画像処理ライブラリ

  • Apacheのサービス起動&自動起動設定ON
systemctl enable httpd.service
systemctl start httpd.service
  • Apacheサービスの稼働確認
systemctl status httpd.service

activeと文字列が表示されれば問題なし。

  • WordPressパッケージのダウンロード
wget http://ja.wordpress.org/latest-ja.tar.gz ~/
  • 解凍
tar zxvf ~/latest-ja.tar.gz
  • パッケージ一式を、Apacheのドキュメントルート配下にコピー
cp -r ~/wordpress/* /var/www/html/
  • パーミッションを変更
chown apache:apache -R /var/www/html
  • ヘルスチェック用のファイルを作成
cd /var/www/html/
mkdir healthcheck
cd healthcheck
touch check

8. 動作確認

以上で、環境構築とWordPressの設定が完了した。

実際にWordPressにログインする前に、ターゲットグループでヘルスチェックの状態を確認する。

  • サービス > EC2 を選択する。
  • 左ペインから「ターゲットグループ」を選択し、My-TG-1を選択後、「Target」タブを選択
  • Statusがhealthyになっていることを確認する。

次に実際にWordPressにログインする。

  • 作成したALBのDNS名をコピーし、ブラウザのアドレスバーに張り付ける。
  • 「さあ、始めましょう!」を押下。
  • 以下の情報を入力し、「送信」を押下。
項目 設定値
データベース名 wordpress
ユーザー名 wordpress (RDS作成時に設定したマスターユーザー名)
パスワード ******** (RDS作成時に設定したパスワード)
データベースのホスト名 作成したデータベースのエンドポイント名
テーブル接頭辞 wp_ (デフォルト)
  • 「インストールの実行」を押下。

  • サイトのタイトルやユーザー名、パスワードを設定し、「WordPressをインストール」を押下。

  • インストールに成功後、「ログイン」を押下

  • 先ほど設定したユーザー名と、パスワードを押下

  • ログインに成功し、管理画面が開く

  • 左上の名前を押下する。

  • ブログが表示される。

まとめ

AWSでWordPressサイトを構築することができた。
画面でポチポチと作業するだけで、簡単にブログサイトを構築することができる。

ただし、画面で作成すると以下のようなデメリットもある。

  • 設定が複雑になってくると、セキュリティやルーティングの設定の関連性がわからなくなってくる可能性がある。
  • 管理が面倒
  • 一度削除すると、再度構築するのが面倒
    ※私は構築後すぐ削除したため、画面キャプチャを取り忘れている場合に取り直すことができなかった。

上記のことから、今度はCloudFormationを使って一発で構築をしてみたいと思う。

以上です。

Discussion