このラボでは、Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Relational Database Service (Amazon RDS) のバックアップを取得し、別リージョンで AWS CloudFormation を利用してアプリケーション環境全体をリストアします。
このラボを修了すると、次のことが出来るようになります。
このラボの前提条件を次に示します。
このラボは、終了までに 40 分かかります。
このセクションでは、DB サーバーのスナップショットを別リージョンへコピーします。
AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。
左側のナビゲーションペインで [スナップショット] をクリックします。
Lab3 で作成したスナップショット (wpdbbackup-lab3) を選択し、[アクション] から [スナップショットをコピー] をクリックします。
[スナップショットをコピー] ページで以下のように指定します。
送信先リージョン | Asia Pacific (Singapore) |
新しい DB スナップショット ID | chapter5 |
ターゲットオプショングループ (オプション) | 指定なし(デフォルトのまま) |
暗号化 | [レ]暗号を有効化(デフォルトのまま) |
[スナップショットをコピー] をクリックします。
AWS マネジメントコンソール右上の 東京▼ をクリックして、アジアパシフィック(シンガポール) をクリックします。
コピーした DB スナップショット chapter5 の [ステータス] が [pending] もしくは [作成中] になっていることを確認します。
※時間が経過すると、[利用可能]になります。それまでの間に次の Task を進めます。
このセクションでは、WordPress サーバーの AMI を別リージョンへコピーします。
AWS マネジメントコンソール右上のリージョンを [シンガポール] から [東京] へ変更します。
AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。
左側のナビゲーションペインで、[AMI] をクリックします。
Lab3 で作成した AMI (myAMI-Lab3) を右クリックして [AMI をコピー] を選択します。
[AMI をコピー] ウィンドウで以下のように指定します。
送信先リージョン | Asia Pacific (Singapore) |
名前 | myAMI-Lab3 |
説明 | myAMI-Lab3 copy from ap-northeast-1 |
暗号化 | [ ] ターゲット EBS スナップショットの暗号化(デフォルトのまま) |
[AMI をコピー] をクリックします。
[完了] をクリックします。
AWS マネジメントコンソール右上のリージョンコードを [東京] から [シンガポール] に変更し、コピーしたスナップショットの [状態] が [pending] になっていることを確認します。
数分程時間が経過すると、[available]になります。それまでの間に次のTaskに進みます。
このセクションでは WordPress が稼働するためのインフラストラクチャを、CloudFormation を使用してシンガポールリージョンにリストアします。
AWS マネジメントコンソールで、右上のリージョンを 東京 から シンガポール に変更します。
[サービス] から [CloudFormation] をクリックします。
[スタックの作成] をクリックします。
ステップ 1. 以下の値を入力します。
・テンプレートの準備 : テンプレートの準備完了 を選択
・テンプレートソース : Amazon S3 URL を選択
・Amazon S3 URL : https://awsj-tc-training-public.s3.ap-northeast-1.amazonaws.com/psw-v1-1/cfn/psw_lab5_restore_infrastracture.cfn.yml
ヒント : Amazon S3 URL が画面から見切れていることがあります。先頭の “https://” から末尾の “.yml” まですべてコピーしてください
[次へ] をクリックします。
ステップ 2. 以下の値を入力します。
スタックの名前 | |
---|---|
スタックの名前 | Infra-Stack |
パラメータ | |
---|---|
EnvironmentName | psw-lab5 |
S3bucketName | *自分の名前(フルネーム)yyyymmdd-lab5 を入力例:awstaro20200101-lab5 |
[次へ] をクリックします。
ステップ 3. すべてデフォルトのままにします。[次へ] をクリックします。
ステップ 4. 設定値を確認して、[スタックの作成] をクリックします。
以上の操作で CloudFormation によって WordPress が稼働するためのインフラストラクチャの構築が開始されました。 通常、3~5 分程度でリストアが完了します。 リストア完了を待たずに次の Task に進んで、リストア中にシンガポールリージョンで何が起こっているのか確認してみましょう。
このセクションでは、CloudFormation によってどのようにリストアが行われたのか確認していきます。
Infra-Stack のイベント一覧が表示されているはずです。
更新ボタンを押してください。 イベント一覧が表示されていない方は [サービス] > [CloudFormation] > 画面左側のナビゲーションペインの [スタック] > [Infra-Stack] > [イベント] タブの順にクリックしてください。
イベント一覧を参照すると、様々な AWS リソース(VPC、ALB、Security Group)が次々に作成されている様子が表示されています。
これらの AWS リソースは Lab4 終了時点の東京リージョンの WordPress 環境とほぼ同一です。 つまり、Lab1 ~4 で行ってきた手動操作を、CloudFormation がシンガポールリージョンで みなさんに代わって、自動的に実行 していることになります。
[テンプレート] タブをクリックしてください
CloudFormation Template が表示されます。
これは、Task3 で CloudFormation の作成時に指定した URL からダウンロードされたファイルに記載されている内容です。 CloudFormation Template には"各種 AWS リソースが、最終的にどのような設定になっているか" という状態 (設定値) が記載されています。CloudFormation は、このテンプレートに従って AWS リソースを作成しています。
[デザイナーで表示] をクリックします。
CloudFormation Template に記載されている AWS リソース群の論理的な関係性が図として表示されています。 AWS リソースのアイコンをクリックすると、CloudFormation Template でどのような設定になっているのか参照できます。
[閉じる] をクリックします。
“このサイトを離れますか?” というポップアップが表示される場合は このページを離れる をクリックしてください。
このセクションでは Task1、2 でコピーした WordPress サーバー の AMI と DB サーバーのスナップショットを使用し、CloudFormation によってアプリケーション環境をリストアします。
AWS マネジメントコンソールで、右上のリージョンを 東京 から シンガポール に変更します。
AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。
左側のナビゲーションペインで、[AMI] をクリックします。
Lab3 で作成した AMI (myAMI-Lab3) を選択します。
[詳細] タブの AMI ID をコピーして、エディタにメモしておきます。
AMI ID は ami-070a7dce069154321
のような文字列です。
[サービス] から [CloudFormation] をクリックします。
左側のナビゲーションペインで、[スタック] をクリックします。
[Infra-Stack] が CREATE_COMPLETE になっていることを確認してください。 “CREATE_COMPLETE” になっていない場合は、1-2 分ほど待ってからリロードボタンをクリックしてください。
[スタックの作成] > [新しいリソースを使用] をクリックします。
ステップ 1. 以下の値を入力します。
・テンプレートの準備 : テンプレートの準備完了 を選択
・テンプレートソース : Amazon S3 URL を選択
・Amazon S3 URL : https://awsj-tc-training-public.s3.ap-northeast-1.amazonaws.com/psw-v1-1/cfn/psw_lab5_restore_app-db.cfn.yml
ヒント : Amazon S3 URL が画面から見切れていることがあります。先頭の “https://” から末尾の “.yml” まですべてコピーしてください
[次へ] をクリックします。
ステップ 2. 以下の値を入力します。
スタックの名前 | |
---|---|
– スタックの名前 | AppDB-Stack |
パラメータ | |
---|---|
– EnvironmentName | psw-lab5 (デフォルトのまま) |
– InfrastructureStackName | Infra-Stack (デフォルトのまま) |
– WordPressAmiID | Task2 でコピーした AMI ID を入力 例:ami-0ee439d98f6612345 |
– DBSnapshotID | chapter5 (デフォルトのまま) |
[次へ] をクリックします。
ステップ 3. すべてデフォルトのままにします。[次へ] をクリックします。
ステップ 4. 設定値を確認して、[スタックの作成] をクリックします。
以上の操作で CloudFormation による WordPress サーバー(Auto Scaling で稼働する EC2 インスタンス)とデータベース(RDS DB インスタンス)のリストアが開始されました。
通常、20~30 分程度でリストアが完了します(RDS の Multi-AZ 配置に 20~25 分を要します) CloudFormation の実行完了を待たずに、次の手順に進んでください。
AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。
左側のナビゲーションペインで [インスタンス] をクリックします。 EC2 Auto Scaling によって、EC2 インスタンスが起動するまで、更新ボタンをクリックしながら待ちます。 AppDB-Stack 作成開始から 4 ~ 5 分程度で EC2 インスタンスが起動してくるでしょう。
[サービス] から [CloudFormation] をクリックします。
左側のナビゲーションペインで、[スタック] をクリックします。
[Infra-Stack] をクリックします。
[出力] タブをクリックします。
[キー] 列で WordPressReadme
を探し、右側の [値] 列に記載れている URL をクリックします。
以下は URL の例になります。
http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/readme.html/
ヒント : WordPressのReadme ページが表示されない場合は、CloudFormation > AppDB-Stack > イベント にて 論理 ID “AutoScalingGroup” のステータスが “CREATE_COMPLETE” になっているか確認してください。確認できない場合は数分お待ち下さい。
【考えてみよう!】 現在の状態で、シンガポールリージョンの WordPress 環境にアクセスすると、ブログは参照できますか? ブログを参照するには、CloudFormation > Infra-Stack > 出力 > WordPressToppage の URL をクリックしてくださいヒント:WordPress は データベースにブログのデータを格納しています。そして、Lab1 の WordPress の初期設定時に、接続先のデータベース情報 (DB サーバーのホスト名、ポート番号、データベース名など) を WordPress サーバーのローカルファイルに保持しています。
このセクションでは、WordPress がアクセスするデータベースを変更します。
AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。
左側のナビゲーションペインで、[データベース] をクリックします。
chapter5 をクリックします。
[接続とセキュリティ] の エンドポイント をエディタにメモします。
DB エンドポイントの例: chapter5.coj06nchnabc.ap-southeast-1.rds.amazonaws.com
AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。
左側のナビゲーションペインで、[インスタンス] をクリックします。 EC2 インスタンスが 1 台起動しています
起動しているインスタンスの、左のチェックボックスをクリックします。
画面上部の [接続] をクリックします。
接続方法 [セッションマネージャー] を選択します。
[接続] をクリックします。
新しいブラウザのタブで、コマンドプロンプトが表示されます
次のコマンドを実行し、ec2-user として操作を行います。 Session Manager 上でのペーストは “Ctrl” + “Shift” + “v” の 3 つのキーを同時に押します。
sudo su ec2-user
cd
pwd
WordPress の設定ファイル “wp-config.php” を、ファイル名 “wp-config.php.old” としてバックアップします。
sudo cp /var/www/html/wp-config.php /var/www/html/wp-config.php.old
wp-config.php を nano (エディタ) で開きます。 vi など他のエディタを使い慣れている方は、適宜お好みのエディタを利用してください。
sudo nano /var/www/html/wp-config.php
nano で wp-config.php を編集します。
・データベースホスト名を、東京リージョンの DB エンドポイントからシンガポールリージョンの DB エンドポイントに書き換えます。
・F6 キー を押してから chapter1
と入力してください。東京リージョンの DB エンドポイントの記載箇所にジャンプします。
・Task6 Step4 でコピーしたシンガポールリージョンの DB エンドポイントに書き換えます。
変更前)chapter1.<ランダム文字列>.ap-northeast-1.rds.amazonaws.com
変更後)chapter5.<ランダム文字列>.ap-southeast-1.rds.amazonaws.com
・Ctrl+x キー、y キー、Enter キーの順に押して、ファイルを保存します。
wp-config.php をバックアップファイルと比較して、データベースホスト名が書き換わっていることを確認します。
sudo diff -u /var/www/html/wp-config.php.old /var/www/html/wp-config.php
設定を反映させるため、Apache httpd をリロードします。
sudo systemctl restart httpd.service
このセクションでは、リストアした ALB の DNS 名にブラウザでアクセスし、WordPress の動作を確認します。
[サービス] から [CloudFormation] をクリックします。
左側のナビゲーションペインで、[スタック] をクリックします。
[Infra-Stack] をクリックします。
[出力] タブをクリックします。
[キー] 列で WordPressToppage
を探し、右側の [値] 列に記載されている URL をクリックします。
以下は URL の例になります。
http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/
以前に投稿した記事が確認できれば、WordPress サーバーと DB サーバーのリストアは完了です。
【考えてみよう!】 ここまでの操作で、シンガポールリージョン (ap-southeast-1) の WordPress 環境のブログが参照できるように思えます。しかし、ブラウザのアドレスバーには "ap-northeast-1" と東京リージョンを示す URL が表示されているはずです。 表示されているブログのデータ (テキスト文章や画像) はどこに保存されていますか?このセクションでは、リストアしたロードバランサー (ALB) の DNS 名にブラウザでアクセスし、Blog 投稿時の動作を確認します。
これまでの設定で、シンガポールリージョンの WordPress サーバー と DB サーバーの SQL 接続はできるようになりましたが、WordPress の “WordPress アドレス” と “サイトURL” が東京リージョンのままなのでリダイレクトされてしまいます。 WordPress の設定をシンガポールリージョン用に変更しましょう。
AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。
左側のナビゲーションペインで、[インスタンス] をクリックします。 EC2 インスタンスが 1 台起動しています
起動しているインスタンスの、左のチェックボックスをクリックします。
画面上部の [接続] をクリックします。
接続方法 [セッションマネージャー] を選択します。
[接続] をクリックします。
新しいブラウザのタブで、コマンドプロンプトが表示されます
次のコマンドを実行し、ec2-user として操作を行います。
Session Manager 上でのペーストは “Ctrl” + “Shift” + “v” の 3 つのキーを同時に押します。
sudo su ec2-user
cd
pwd
次のコマンドで RDS DB インスタンスに接続する。
mysql -u wpuser -p -h RDSのDBエンドポイント
以下がコマンドの例です
mysql -u wpuser -p -h chapter5.cj4gyof9abc5.ap-southeast-1.rds.amazonaws.com
Lab1 で設定した DB ユーザ “wpuser” のパスワードを入力します。
手順通りに実施している場合は、wppassword
です。
次の SQL を実行します。
USE wordpress;
SELECT option_value
FROM wp_options
WHERE option_name = 'siteurl' or option_name = 'home';
東京リージョンの ALB の DNS 名が表示されました。
次のコマンドをテキストエディタにコピーします。 “シンガポールの ALB の DNS 名"を書き換えて、次の SQL を実行します。
UPDATE wp_options set option_value = 'http://シンガポールのALBのDNS名'
WHERE option_name = 'siteurl' or option_name = 'home';
上記 SQL コマンドを実行すると、WordPress の “WordPress アドレス” と “サイトURL” を書き換えます。
このオペレーションは、Lab2b で EC2 インスタンス単体の環境から、ALB を利用した環境に変更する際にも実施しました。 先程、シンガポールリージョンの WordPress へアクセスするとリダイレクトされたのは、 WordPress アドレス、サイト URL が東京リージョンの ALB を指していたためです。
次の SQL を実行し、WordPress アドレス、サイト URL が変更されていることを確認します。
SELECT option_value
FROM wp_options
WHERE option_name = 'siteurl' or option_name = 'home';
[サービス] から [CloudFormation] をクリックします。
左側のナビゲーションペインで、[スタック] をクリックします。
[Infra-Stack] をクリックします。
[出力] タブをクリックします。
[キー] 列で WordPressAdmin を探し、右側の [値] 列に記載れている URL をクリックします。
サイトの URL は、http://<シンガポールリージョンの WordPressLB の DNS名>/wp-admin
となっています。
以下は URL の例になります。
http://WordPressLB-55192789.ap-southeast-1.elb.amazonaws.com/wp-admin
WordPress アドレス、サイトURL を変更したので、東京リージョンにはリダイレクトされません。
Lab1 で設定した WordPress 管理者ユーザ名とパスワードを入力して管理者ページにログインしてください。 WordPress 管理者 ID・パスワードは、手順通りに進めている場合 ユーザ名:admin パスワード:(名前) + (今日の日付) + !(例: Suzuki20210115!) です。
WordPress の管理者 (admin) パスワードを忘れてしまった場合は こちらをクリック して復旧させましょう。
このセクションでは、リストアした WordPress がブログ画像をシンガポールリージョンの S3 Bucket へ格納するようにします。
管理者画面の左下の [設定] > [Offload Media Lite] > [Bucket] > [Change] を選択します。
[Browse existing buckets] をクリックします。
Task3 で入力した S3 バケットを選択します。 S3 バケット名の末尾が”-lab5"になっているはずです。
[Save Selected Bucket] をクリックします。
ブログを新規投稿して、画像の保存先を確認します。
【考えてみよう 1】 CloudFormation によってネットワーク、サーバー、ミドルウェア、アプリケーションのリストアは自動化できました。 しかし、Task6~9 で実施したように各種 Configuration の一部は、手動での修正が必要になりました。 何が要因となって、手動での修正が必要になってしまったのでしょうか? 手動での修正を最小化する工夫はできないでしょうか?ヒント:Lab3 で ”値” そのものと、“値” を利用した設定を分離していませんでしたか? そのようなアプローチの適用範囲を広げられませんか?
【考えてみよう 2】 ここまでの設定で新規ブログ投稿はシンガポールリージョンに保存されることになりました。 リストアをより完全な形にするためには、どのような変更が必要ですか?ヒント:可用性の向上、”シンガポールリージョン以外に存在しているデータ” 等を考慮してみましょう!
このタスクでは、シンガポールリージョンで稼働している WordPress サーバーの可用性を向上させます。 これまでのタスクと異なり、詳細な手順はありません。Lab1 ~ Lab5 で学んだ知識と経験を使って解決してみましょう。
以下の条件を満たすように、WordPress サーバーを 1 台から 2 台に増やして高可用性構成にしてください。
このラボでは、Amazon EC2 と Amazon RDS のバックアップを取得し、別リージョンで CloudFormation を利用してアプリケーション環境全体をリストアしました。
お疲れさまでした。これで Lab5 は終了です。
Web Server01 に Session Manager でログインする。
次のコマンドで RDS に接続する。
mysql -u wpuser -p -h RDSのエンドポイント
DB エンドポイントはお手元のメモを参照してください
DB の password は手順通りに設定してある場合はwppassword
です。
次の SQL コマンドを実行する。
show databases;
use wordpress;
select user_login, user_pass from wp_users;
update wp_users set user_pass = md5('NEWPASSWORD') where user_login = 'admin';
NEWPASSWORD
の箇所を、任意の文字列に置き換えて下さい。
こちらをクリック して、もとの Task に戻る