個人で行うAWSインフラ構築日記3日目
前回までは、一つのインスタンスにWordPressとDBを相乗りさせた構成のサーバーを構築していましたので、今回はWordPressとDBを別々に分けてよりセキュアな構成になったサーバーを構成していきたいと思います。
２層クライアント構成について
基本的にDBサーバーなど個人情報や社外秘の情報を含んだサーバーを外部インターネットに接続されている状態にしておくのはセキュリティ的に好ましいことではありません。
そのため、DBサーバーはインターネットからの通信を許可せずWebサーバーとの通信のみを許可する設定にすることが基本的なインフラ構築の考えになります。
（注：Webサーバーも直接インターネットに接続させたくない場合はVPNやLBなど色々とやり方がありますので、そのうち試して日記に残していきます)
AWSの公式ユーザーガイドに今回の構築にピッタリのチュートリアルがありましたので、基本的にそれを参照しながら気づいた点や学んだ点を日記に残していきたいと思います。
ネットワーク構成図
今回構築するネットワーク構成図はこちらとなります。
出典元：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Scenario2.html
AWS公式ユーザーガイドから持ってきたものですが、上記図ですと複数のWebサーバーとDBサーバーを立てていますがコストの都合上それぞれ１つずつ立てて構築していきます。早速構築した結果を構成図に表したいと思います。
WordPress画面
前回まではルートテーブルをアイコンで記載しましたが、他のネットワーク構成図を見てみると図表で表すことが一般的みたいですので、私もそちらに合わせるようにしました。
新しく出てきたDBSubnet1ですが、これはインターネットに繋がらないようにしています。AWSではこのサブネットをプライベートサブネットと呼びます。
（注：書き忘れていましたが、インターネットにつながり外部から公開されいるサブネットのことはパブリックサブネットと言います。）
プライベートサブネットに配置されたDBはAWSで提供されているRDSを使用しています。冒頭に記したとおり、DBはセキュリティリスクによりインターネットに繋げないようにするのが鉄則です。そのため、宛先ルートもインターネットゲートウェイではなくNATゲートウェイに向かうように設定しています。このためDBに接続するにはパブリックサブネット上に存在するEC2インスタンスから接続しなければならないようにしてあります。
つまずいた箇所
今回いくつかのサイトやAWSのリファレンスを参考に構築しましたが、何度かうまくできずに躓いた箇所がありましたので、そこを振り返っていきます。
①PHPのバージョンが古い
今回使用したOSはAWSの標準LinuxのAmazon Linux2を使用しましたが、使用されているyumリポジトリ内のPHPのバージョンが古く、現行のWordPressではバージョンコンフリクトを起こしてしまいました。
[ec2-user@ip-10-0-0-45 ~]$ php -v
PHP 5.4.16 (cli) (built: Oct 31 2019 18:34:05)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologiesそのため手動でバージョンを上げなければならない事態となりました。
Amzon Linux2ではExtras Library と呼ばれる専用のパッケージ群からphpのバージョン7.2をインストールすることができましたので、以下のコマンドでPHPのバージョンを更新しました。
[root@ip-10-0-0-45 ~]# amazon-linux-extras install php7.2
(中略)
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : php-json-7.2.24-1.amzn2.0.1.x86_64
Updating : php-common-7.2.24-1.amzn2.0.1.x86_64
Updating : php-pdo-7.2.24-1.amzn2.0.1.x86_64
Updating : php-mysqlnd-7.2.24-1.amzn2.0.1.x86_64
Installing : php-fpm-7.2.24-1.amzn2.0.1.x86_64
Installing : php-cli-7.2.24-1.amzn2.0.1.x86_64
Cleanup : php-mysqlnd-5.4.16-46.amzn2.0.2.x86_64
Cleanup : php-pdo-5.4.16-46.amzn2.0.2.x86_64
Cleanup : php-common-5.4.16-46.amzn2.0.2.x86_64
Verifying : php-common-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-fpm-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-cli-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-pdo-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-json-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-mysqlnd-7.2.24-1.amzn2.0.1.x86_64
Verifying : php-common-5.4.16-46.amzn2.0.2.x86_64
Verifying : php-pdo-5.4.16-46.amzn2.0.2.x86_64
Verifying : php-mysqlnd-5.4.16-46.amzn2.0.2.x86_64
(中略)
[root@ip-10-0-0-45 ~]#
[root@ip-10-0-0-45 ~]# php -v
PHP 7.2.24 (cli) (built: Oct 31 2019 18:27:08) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
②接続先のDB名を間違えた
PHPのバージョンを更新して、WordPressへアクセスしようと試みましたが上記の画面が出てアクセスできませんでした。
これですが、設定に誤りがありました。
~/var/www/html/wordpress/wp-config.php~
// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/* WordPress のためのデータベース名 */
define( 'DB_NAME', 'yuta-db1' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'admin' );
/** MySQL データベースのパスワード */
WordPressを起動するためのconfigファイルですが、ファイル内で設定したDB名をRDS作成時に決めたDB識別子で記載したのですが、正しくはRDS作成後のDB名を記載する必要がありました。なのでEC2からMySQLへ接続し、新たにDBを作成する必要がありました。
MySQL [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| innodb |
| mysql |
| performance_schema |
| sys |
| yutaDB1 |
+--------------------+
6 rows in set (0.00 sec)
~/var/www/html/wordpress/wp-config.php~
// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'yutaDB1' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'admin' );
DBを作成後、configファイル内の修正し、WordPressのインストール画面へアクセスすることを確認できました。
構築感想
今回ですが、上記２つのトラブルにつまずき中々思い通りのインフラ構築ができませんでした。特に２番めのトラブルはPHP周りの知識不足からくるミスでしたので、原因特定するのに時間がかかりました。
パブリックサブネット、プライベートサブネットで分けて構築する考えは試験でも学びましたが実際に構築することで思わぬトラブルも経験できて、いい学びになったと思います。
次回予告
次回ですが、高可用性を高めるためにロードバランサーを導入してより実践に近い構築を行っていこうと思います。