ハンズオン

ハンズオンはフェーズ1から3、オプションまで段階を踏んで環境構築を進めていきます。
フェーズ1ではWordPressをEC2インスタンス1台構成で構築（WordPress、nginx、MySQLインストール済みAMIを使用）し、
オプションまで完了すると、LB＋Webサーバ2台＋DBサーバ2台（Multi-AZ）構成ができます。
※フェーズ3までは無料枠で構築できる

ハンズオンではVPCウィザードを使用しますが、今回は理解のため使わずに進めていきます。
（なので、フェーズ１の範囲は作業が変わります）

図はハンズオン資料を元にdraw.ioで作成。

フェーズ1：サーバ1台構成（EC2インスタンス１台）

やること

VPC作成
- ハンズオンではVPC作成ウィザードを使用しますが、理解のためここでは使いません。
- VPCウィザードを使用すると、サブネット・ルートテーブルやインターネットゲートウェイ等のVPCコンポーネントも一緒に作成される。
コミュニティAMIからEC2作成
ElasticIPを割り当て、EC２インスタンスに割当
WordPress設定

やっていき

VPC作成〜VPCコンポーネント設定

VPC作成

サービスから「VPC」を選択
VPC > VPCの作成
- 名前タグ … 自分が認識できるもの。ここでは「vpc-handson」にした
- IPv4 CIDR ブロック … ハンズオン資料と同じく10.0.0.0/16
- IPv6 CIDR ブロック … IPv6 CIDR ブロックなしを選択

サブネット作成

サブネット > サブネットの作成
- ここでは、AZ 1a、1cにそれぞれパブリックサブネット、プライベートサブネットを作成
- フェーズ1ではAZ 1aに作成したパブリックサブネットのみ使用。残りはフェーズ2、3、オプションで使用
- サブネットの作成
  - 名前タグ … 自分が認識できるもの。ここでは「sb-handson-public-1a」「sb-handson-private-1a」といった名前タグを指定
  - VPC … 作成したvpc-handsonを指定
  - IPv4 CIDR ブロック … 資料と同じく 10.0.0.0/24、10.0.1.0/24、10.0.2.0/24、10.0.3.0/24 をそれぞれ指定

インターネットゲートウェイ作成

インターネットゲートウェイ > インターネットゲートウェイ作成
- 名前タグ … 自分が認識できるもの。ここでは「igw-handson」
インターネットゲートウェイ > アクション > VPCにアタッチ
- 作成したインターネットゲートウェイを選択、VPCにアタッチする

ルートテーブル作成＆編集

作成したインターネットゲートウェイを送信先に追加する
ひとまず既に作成されているルートテーブルは識別できる名前（ここではrtb-handson-private）に変更
- 作成されたサブネットに関連付け済み。送信先は作成したVPCになっている
ルートテーブル > ルートテーブルを作成
- インターネットゲートウェイに向けるルートテーブル
- 名前タグ … 自分が認識できるもの。ここでは「rtb-handson-public」
インターネットゲートウェイを送信先に追加
- 新しく作成したルートテーブルを選択 > ルートの編集
- ルートの追加
  - 送信先を0.0.0.0/0（デフォルトルート）、ターゲットをインターネットゲートウェイを選択
サブネットの関連付け
- サブネットの関連付けの編集
- パブリックサブネット用に作成したサブネットを選択

セキュリティグループ設定

後の作業でセキュリティグループを新しく追加するので、既に作成されているセキュリティグループのNameを認識しやすい名称（ここではsg-handson-default）に変更する

EC2インスタンスの作成〜WordPressの構成

コミュニティAMIからEC2インタンスを起動、WordPressの設定をしていきます。

EC2インスタンスの作成

サービスから「EC2」を選択
EC2を作成する
- EC2インタンスの起動 > コミュニティAMIを選択
- 資料にあるAMI-IDを検索し、選択
  - wordpress, nginx, mysqlが既に設定済みのイメージ
- インスタンスタイプ … t2.microを選択
- インスタンスの詳細 … VPCは作成したVPC、サブネットはパブリックサブネット(AZ az）を選択、自動割当パブリックIPは有効にする
- 高度な詳細 … ユーザーデータに #!/bin/bash chown apache:apache /var/www/html/ を指定
- ストレージ … 特に設定せず
- タグの追加 … キーに「Name」を追加。認識しやすい名前を指定（ここではweb-user-1）
- セキュリティグループの設定
  - セキュリティグループの割り当て … 新しいセキュリティグループを作成する
  - ルールに「SSH」追加 … プロトコルがTCP、ポート範囲が22、ソースは任意の場所（0.0.0.0/0, ::/0）
  - ルールに「HTTP」追加 … プロトコルがHTTP、ポート範囲が80、ソースは任意の場所（0.0.0.0/0, ::/0）
- キーペアの作成
  - 新規作成した場合はpemファイルを保存する

ElasticIPの割り当て

Elastic IP > Elastic IPアドレスの割り当てよりElasticIPを作成
Elastic IP > アクション > Elastic IPの関連付け
- 先程作成したEC2インスタンスを関連付け

WordPressの構成

ターミナルからssh接続を確認
- ssh -i [EC2インスタンス起動時に保存したpemファイル] ec2-user@[作成したElasticIP]
- MySQLとnginxが起動していることを確認
  - sudo service mysqld status
  - sudo service nginx status
http://[作成したElasticIP]/にアクセス、資料通りにWordPressの設定をする

フェーズ2：Web＋DB（サーバ２台構成）（EC2インスタンス1台＋RDS1台）

やること

DB用セキュリティグループ作成
DBサブネットグループを作成（フェーズ1で作成したプライベートサブネットを割り当てる）
RDSインタンス作成（作成したサブネットグループを割り当てる）
フェーズ1のEC2インスタンス上のMySQLを停止＆RDSに接続設定を変更

やっていき

DB用セキュリティグループ作成

セキュリティグループを作成
- セキュリティグループ名 … db-user1
- 説明 … RDS for MySQL
- VPC … 作成したVPC
- インバウンドルール
  - タイプ … MySQL/Aurora
  - ソース … カスタムを選択、webserver用に作成セキュリティグループを選択

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

サービスから「RDS」を選択
サブネットグループ > DBサブネットグループを作成
- 名前 … db subnet user1
- 説明 … RDS for MySQL
- VPC … 作成したVPC
- アベイラビリティゾーン … 1a、1c
- サブネット … AZ 1a、1cに作成したプライベートサブネットを選択

RDSインタンス作成

データベース > データベースの作成
- データベースの作成方法 … 標準作成
- エンジンのタイプ … MySQL
- テンプレート … 開発/テスト
- DBインスタンスサイズ … バースト可能クラスでdb.t2.microを選択
- VPC … 作成したVPC
- サブネットグループ … 先程作成したサブネットグループを選択
データベース作成、起動までには数分かかる

wordpressの接続先DBを変更

作成したEC2からRDSに接続できることを確認
- $ mysql -u admin -p -h [作成したRDSのエンドポイント]
EC2インスタンス上にインストールされているMySQLのデータをエクスポート
- mysqldump -u root -p wordpress > export.sql
EC2インスタンス上のMySQLは今後使わないため停止
- sudo service mysqld stop
- sudo chkconfig --level 345 mysqld off
エクスポートしたデータをRDSにインポート
- mysql -u admin -p -h [作成したRDSのエンドポイント] wordpress < export.sql
再設定をWebから行うため、DB接続設定を初期化する
- sudo mv /var/www/html/wp-config.php ~/
- http://[EIP]/ に接続、WordPressを再設定
- データベースのホスト名をlocalhostからRDSのエンドポイントに変更
http://[EIP]/ にアクセスして表示されることを確認

フェーズ3：LB + Webx2 + DB構成 (サーバ３台構成)

やること

フェーズ2までに作成したwebserverを元にAMIを作成する
２つ目のEC2インスタンスを作成
ELBのセキュリティグループを作成
ELBを作成
- パブリックサブネットに配置
- セキュリティグループを新規に作成
WordPressが生成するHTMLのホスト名をELBのDNSに変更
Webサーバ用のセキュリティグループ変更
- WebサーバにELBからのみ許可するよう変更

やっていき

2台目のWebサーバーを作成

WebサーバのAMIを作成
- インスタンス > アクション > イメージ > イメージを作成
AMI > 作成したAMIを選択、起動
- ネットワーク … 作成したVPCを選択
- サブネット … AZ 1cに作成したパブリックサブネットを選択
- 自動割り当てパブリックIP … 有効
- タグ … キー「Name」を追加。認識できる名称（ここではwebserver-handson-2）を指定
- セキュリティグループ … 既存のセキュリティグループ（1台目のWebサーバと同じ）を選択

ELBを作成

ロードバランサー > ロードバランサーの作成
- Application Load Balancer（HTTP、HTTPS）を作成
  - 名前 … 認識できる名前（ここではelb-handson）
- アベイラビリティーゾーン … 1a、1cのパブリックサブネットを選択
- セキュリティグループ
  - 新しいセキュリティグループを作成
  - セキュリティグループ名 … 認識できる名称（elb-user1）
  - ルール … HTTP、TCP、80
- ルーティングの設定
  - 各ターゲットグループは 1 つのロードバランサーのみに関連付けることができることに注意
  - 名前 … 認識できる名前（target-user1）
- ターゲットの登録
  - 作成済みのインスタンス２台を登録済みに追加
作成したらターゲットグループのStatusがhealthyに変わるのを確認
WordPressの設定変更
- WordPressの生成するHTML内のホスト名は初期セットアップ時のEIPが指定されているので、ELBのDNSに変更
  - $ mysql -u admin -p -h [RDSのエンドポイント] wordpress;
  - update wp_options set option_value='[ELBのDNS名]' where option_name='siteurl' or option_name='home';
- http://[ELBのDNS名]/ でWordPressが表示されることを確認

ELBのセキュリティグループ設定変更

WebサーバにはELBからのみアクセスを許可するよう、セキュリティグループを変更
セキュリティグループでWebサーバーに指定しているものを選択
インバウンドルールのHTTPのソースを0.0.0.0からELBに変更
http://[EIP] にアクセスできなくなることを確認

オプション：LB + Webx2 + DBx2構成(サーバ4台構成)

やること

RDSのMulti-AZを有効にする
RDSインタンスのフェイルオーバーを選択、再起動する

やっていき

データベース > 変更
- 可用性と耐久性の「マルチAZ配置」に変更
データベース > アクション > 再起動
- フェイルオーバーし再起動する

さらに拡張性、安全性を高める

ハンズオン資料より引用

さらに拡張性を高める
- Webサーバ
  - AutoScalingで負荷調整を自動に
  - 静的コンテンツにS3のWebサイト機能を使用する
  - CloudFrontでコンテンツキャッシュする
- DBサーバ
  - DBのリードレプリカを作成し、読み込み負荷を分散 • DBをシャーディングで分散
  - ElastiCacheでセッション情報の保持
  - ElastiCacheでデータをキャッシュ
さらに安全性を高める
- IAMを利用する
- SSH等の管理接続を制限する
  - Security Groupで接続元を制限
  - VPCのVPN経由のみに限定
- System Manager Run Commandを利用し、SSHを使用しない
- 監視を行う
  - CloudWatchで監視
  - サードパーティ製品・サービスで監視
- CloudTrailで監査ログを残す
- AWS WAFを利用する
- 前段にELBを配置した場合は、EC2をプライベートサブネットに置く

最後にリソースの削除をする

削除するまでがハンズオン。