本記事の前半は、以前自己学習のために入会した Cloud Techという技術コミュニティの課題カリキュラムに沿って作成しました。
また、後半は、自己学習でコード化した際のハンズオン内容です。
カリキュラムなどにご興味のあるかたは、以下リンクより公式ページにリンクできますので、内容をご覧になってみてはいかがでしょうか。
Cloud Tech
ハンズオンで目指す構成
シングル構成とは?
このハンズオン作業のゴール
構成図にある青い矢印の「HTTP」で、ローカルPCからインターネットを経由し、EC2にインストールしたWordPressのブログサイトにアクセスできることを確認します。
構築環境
ローカル開発環境 | Mac M1からブラウザよりAWSマネジメントコンソールに接続して作業 |
EC2のOS | ubuntu(画面ショットはAmazon Linuxで取得している箇所があります) |
SQLエンジン | MySQL |
SSH通信 | Macのターミナルから接続(Windowsからの接続方法も記載しています) |
作図 | dwarioのAWS19アイコンを利用 |
手動で構築する手順の概要
- VPCを作成する
- サブネットを作成する
- インターネットゲートウェイを作成する
- ルートテーブルを作成する
- EC2を作成する
- RDSを作成する
- セキュリティグループを作成する
- WordPressをインストールする
- ローカルPCから疎通確認をする
主な手順は以下の通り
- はじめに、step01・2・3・4でAWS上にネットワーク接続するためのベースを作成
- step5・6・7でEC2とRDSを用いて、WordPressをインストールするためのwebサーバーと、データベースを提供するためのRDSを作成
- 最後に、step8でWordPressをインストールし、step9でインターネット経由でブログサービスに接続できるか確認
1 VPCを作成する
VPCを作成する手順
> AWSマネジメントコンソール
> VPCダッシュボード
> 左ペイン
> 「VPC」をクリック
> 右上の「VPCを作成」をクリック
> VPC を作成 > VPC の設定 より以下を入力
名前タグ – オプション | 任意のVPC名 今回は「VPC」と記載 |
IPv4 CIDR ブロック | 任意のIPアドレスブロック※ 今回は「172.16.0.0/16」と記載 |
その他の項目 | デフォルトのまま |
IPv4 CIDRについて
VPCの中で利用するアドレスブロックはプライベートIPアドレスを利用すれば大丈夫。今回はクラスBのプライベートIPアドレスを使用しました。
プライベートアドレスに関する詳細は、以下のJPNICのページが参考になります。
2 サブネットを作成する
サブネットを作成します。
今回の作業で作成するサブネット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内にサブネットを作成する手順
> AWSマネジメントコンソール
> VPCダッシュボード
> 左ペイン > 「サブネット」をクリック
> 「サブネットを作成」をクリック
> 「サブネットを作成」画面で以下を入力
(例として、「Public Subnet 1a」の作成手順をご紹介します。)
VPC > VPC ID | step01で作成した「VPC」を選択 |
サブネットの設定 > サブネット名 | Public Subnet 1a |
サブネットの設定 > アベイラビリティゾーン | 「アジアパシフィック(東京)/ap-northeast-1a」を選択 |
サブネットの設定 > IPv4 CIDRブロック | 「172.16.1.0/24」と記載 |
> つづいて「サブネットを作成」をクリック
> 残りのサブネット3つに対しても同様に作成
> サブネット画面で今回作成した4つのサブネットが記載されていることを確認
3 インターネットゲートウェイを作成する
step03とstep04では、以下のようにインターネットゲートウェイとルートテーブルを作成します。
インターネットゲートウェイとルートテーブルを作成して設定することにより、VPCに作成したインスタンスが外部と通信可能になります。
インターネットゲートウェイを作成する手順
> AWSマネジメントコンソール
> VPCダッシュボード
> 左ペイン > 「インターネットゲートウェイ」をクリック
> 「インターネットゲートウェイの作成」をクリック
> インターネットゲートウェイの作成 > インターネットゲートウェイの設定 > 名前タグに任意の名前を記載する。今回は「IGW」とする。
> 「インターネットゲートウェイの作成」をクリック
> インターネットゲートウェイの画面に戻ったら、上記で作成した「IGW」にチェックを入れる。
> 右上のアクション > VPCにアタッチ をクリックする
> VPCにアタッチ > 使用可能なVPCにstep01で作成した「VPC」を選択する
> 「インターネットゲートウェイのアタッチ」をクリックする
> 以下のように、作成した「IGW」の状態が「Attached」になっていることを確認する
4 ルートテーブルを作成する
step04ではルートテーブルを作成します。
今回は、Public Subnetに適用するルートテーブルとPrivate Subnetに適用するルートテーブルを計2つ作成します。
ルートテーブル作成の手順
Route Table Publicの作成
> AWSマネジメントコンソール
> 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のルートテーブルについて以下が実現されます。
- 送信先:172.16.0.0/16のトラフィックについては、local(つまりVPCのみ)で処理される
- その他の送信先:0.0.0.0/0のトラフィックに関しては、IGWに転送される
Route Table Privateの作成
> AWSマネジメントコンソール
> 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のルートテーブルでは以下が実現されます。
5 EC2を作成する
Public Subnet 1a にEC2を作成し、WordPressをインストールしたWebサーバーとして外部公開し、インターネット経由で閲覧可能にします。
EC2の作成
> AWSマネジメントコンソール
> 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 インスタンス作成の確認 |
設定に問題ないか確認し、「起動」をクリック |
> > sshの「秘密鍵」を作成する(キーペア)をダウンロードする
※キーペアのダウンロードチャンスは1回限りなので、キーペアの管理は慎重しましょう。
> つづいてインスタンスの画面に戻り、インスタンスが「実行中」であることを確認
6 Private Subnet 01 にRDSを作成する
RDSを作成する手順
サブネットグループを作成する
> AWSマネジメントコンソール
> 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 |
データベースを作成する
> AWSマネジメントコンソール
> Amazon RDS ダッシュボード
> データベースをクリック
> 「データベースの作成」をクリック
> データベースの作成 の画面で以下を設定する
データベースの作成方法を選択 | 標準作成 |
エンジンのオプション | |
エンジンのタイプ | MySQL |
その他 | デフォルトのまま |
テンプレート | 開発/テスト |
設定 | |
DBクラスター識別子 | デフォルトのまま |
マスターユーザー名 | wordpress |
マスターパスワード | 任意 (今回は wordpress と設定) |
DBインスタンスサイズ | バースト可能クラス db.t3.micro |
可用性と耐久性 | デフォルトのまま |
接続 | |
Virtual Private Cloud | VPC (今回作成したVPC)を選択 |
サブネットグループ | wordpress-db-subnet group (今回作成したサブネットグループ)を選択 |
パブリックアクセス可能 | なし |
VPCセキュリティグループ | 新規作成 > Name : rds-sgを作成 ※名前以外はデフォルトのまま |
追加設定 | wordpress |
その他 | デフォルトのまま |
つづいて「データベースの作成」をクリック
7 セキュリティグループを作成する
セキュリティグループを作成し、EC2に適用する
> AWSマネジメントコンソール
> EC2 ダッシュボード
> 左ペイン
> セキュリティグループをクリック
> 「セキュリティグループを作成」をクリック
> 「セキュリティグループを作成」画面で、以下を作成
基本的な詳細 | |
セキュリティグループ名 | web-sg |
説明 | web-sg |
VPC | VPC (今回作成したVPC) |
インバウンドルール | タイプ:HTTPS/ソース:0.0.0.0/0 タイプ:SSH/ソース:0.0.0.0/0 |
その他 | デフォルトのまま |
> つづいてEC2ダッシュボード > インスタンス をクリック
> step05で作成したEC2(今回はwordpress01)を選択
> 画面右上 > アクション > セキュリティ > セキュリティグループを変更 をクリック
> セキュリティグループを変更の画面 > 関連付けされたセキュリティグループ > 「削除」をクリック
(現在関連付けされているデフォルトのセキュリティグループを削除する)
> 今回作成したセキュリティグループ(web-sg)を選択
> 「保存」をクリック
RDS用セキュリティグループを編集する
次に、今回作成したセキュリティグループ:we-sgをRDSが所属するセキュリティグループのrds-sgに適用します。
この操作により、RDSはEC2からの操作だけを受け付けるようになります。
> AWSマネジメントコンソール
> EC2 ダッシュボード
> 左ペイン
> セキュリティグループをクリック
> 今回、RDS用に作成したセキュリティグループ(rds-sg)をクリック
> 「インバウンドルールを編集」をクリック
> ソースを「×」ボダンで一旦削除する
> つづいて今回EC2に適用したセキュリティグループ:web-sgを選択しする
> 「ルールを保存」をクリックする
8 WordPressをインストールする
EC2にWordPressをインストールする手順
はじめに、Step05で作成したEC2にSSH接続します。
Windows環境からEC2へ接続する手順
以下はWindows環境からec2-userでAmazon Linuxに接続する手順です。
> AWSマネジメントコンソール
> EC2
> 実行中のインスタンス
> 今回作成したEC2:wordpress-01をクリック
> インスタンスのパブリックIPを確認 図A
※今回の例:3.113.25.2
> 上記で確認したパブリックIPに対し、TeratermでSSH接続・・・図B-C-D
※図Dのように、step05で作成したSSHの秘密鍵「***.pem」ファイルを利用して接続する。
> ログインできたことを確認 図E
MacからSSHする手順
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
9 ローカルPCから疎通確認をする
確認手順
> step08で確認したEC2のパブリックIPを、ブラウザのアドレスバーに打ち込む
> 以下の画面表示となることを確認
> つづいて、Wordpressに以下を打ち込み、「送信」をクリック
・データベース名 wordpress
・ユーザー名 wordpress
・データベースのホスト名 RDSのエンドポイント名
・その他 デフォルトのまま
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初学者を導く体系的な動画学習サービス「Cloud Tech」の課題カリキュラムで作成しました。
AWSについて、基本からしっかり学びたい方にはオススメです!
ここまでの設定を自動化してく
後半は、ここまでの設定を自動化していきます。
近日中に掲載予定です。