awsセルフハンズオン「AWSの基礎サービス ～ Amazon EC2, Amazon RDS, Amazon VPC ～」をやってみる。
https://resources.awscloud.com/aws-summit-online-japan-2020-on-demand-self-paced-hands-on-85234
ハンズオン資料はここ。
https://github.com/harunobukameda/Amazon-VPC---Amazon-EC2---Amazon-RDS-Handson
ハンズオン
ハンズオンはフェーズ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/bashchown 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 statussudo 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 stopsudo 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）
- ターゲットの登録
- 作成済みのインスタンス２台を登録済みに追加
- Application Load Balancer（HTTP、HTTPS）を作成
- 作成したらターゲットグループの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が表示されることを確認
- WordPressの生成するHTML内のホスト名は初期セットアップ時のEIPが指定されているので、ELBのDNSに変更
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でデータをキャッシュ
- Webサーバ
- さらに安全性を高める
- IAMを利用する
- SSH等の管理接続を制限する
- Security Groupで接続元を制限
- VPCのVPN経由のみに限定
- System Manager Run Commandを利用し、SSHを使用しない
- 監視を行う
- CloudWatchで監視
- サードパーティ製品・サービスで監視
- CloudTrailで監査ログを残す
- AWS WAFを利用する
- 前段にELBを配置した場合は、EC2をプライベートサブネットに置く
最後にリソースの削除をする
削除するまでがハンズオン。