AWS Practical Startup Workshop > Lab Guide > Lab 2a

Lab 2a

Lab2a：高い可用性を持つブログサイトの構築 Part1

概要

このラボでは、Amazon Simple Storage Service (Amazon S3) を使用して可用性の高いブログサイトを構築します。

目標

このラボを修了すると、次のことが出来るようになります。

静的コンテンツについては可用性の高い S3 へ配置し、エンドユーザーへ直接配信するよう構成する

最終的は、次の図で示すようなアプリケーション環境を構築する

Lab2a Architecture

前提条件

このラボの前提条件を次に示します。

Microsoft Windows、Mac OS(X以降）、または Linux（Ubuntu、SUSE、または Red Hat）が搭載されているノートパソコンで、Wi-Fi アクセスができること
Microsoft Windows ユーザーの場合は、コンピュータへの管理者アクセスができること
Chrome、Firefox、Internet Explorer 11（これより前のバージョンの Internet Explorer はサポートされていません）などのインターネットブラウザを利用できること

時間

このラボは、終了までに 20 分かかります。

Lab2a-Task1: S3 バケットの作成

ラボのこのセクションでは、WordPress の画像を格納するためのコンテンツ保管用バケットを作成します。

AWS マネジメントコンソールで [サービス] から [S3] をクリックします。
S3 コンソールのこのバージョンは一時的に復元されていますが、新しい S3 コンソールエクスペリエンスは今後も改善していきます。 とメッセージが表示されている場合、新しい S3 コンソールエクスペリエンス をクリックします。メッセージの表示がない場合は、次の手順に進んでください。
[バケットを作成] をクリックします。
[一般的な設定] は以下のように値を指定します。

バケット名 任意 (例: <自身の名前>-<今日の日付> など)
例）johndoe-20210115

リージョン アジアパシフィック（東京）

バケット名はインターネット上で一意である必要があります(重複できません) 。使用できるのは、アルファベットの小文字とピリオド「.」とハイフン「-」のみです。
[オブジェクト所有者] で [ACL 有効] を選択します。その他の値はデフォルトのままにします。

チェック無し ACL 無効（推奨）

レ ACL 有効

注意 : このハンズオンでは S3 のアクセス制御を簡易にするために ACL を利用します。しかし、本番環境ではきめ細やかなアクセス制御を実現するために Bucket Policy の利用を推奨いたします。


バケット名	任意 (例: <自身の名前>-<今日の日付> など) 例）`johndoe-20210115`
リージョン	アジアパシフィック（東京）


チェック無し	ACL 無効（推奨）
レ	ACL 有効

[このバケットのブロックパブリックアクセス設定]で、パブリックアクセスをすべてブロック のチェックを外します。


チェック無し	パブリックアクセスをすべてブロック
チェック無し	新しいアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする
チェック無し	任意のアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする
チェック無し	新規のパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする
チェック無し	あらゆるパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする
レ	現在の設定により、このバケットとバケット内のオブジェクトがパブリックになる可能性があることを承認します（“パブリックアクセスをすべてブロック"のチェックを外すと表示されます)

注意 : 本番環境ではパブリックアクセス可否について、セキュリティの観点から慎重に検討してください。

[バケットを作成]をクリックします。これで S3 バケットが作成開始されます。

Lab2a-Task2: IAM ロールに S3 への認可を追加する

このセクションでは、IAM ロールに WordPress サーバーが S3 へアクセスするための IAM policy を追加します。

AWS マネジメントコンソールで [サービス] から [IAM] をクリックします。
ナビゲーションペインで [ロール] をクリックします。
検索フォームに WP-Role と入力し、検索結果から WP-Role をクリックします
[ポリシーをアタッチします] をクリックします
検索フォームに s3full と入力し、検索結果から [AmazonS3FullAccess] のチェックボックスをチェックします
[ポリシーのアタッチ] をクリックします

以上の設定で、Web Server01 は IAM ロール “WP-Role” を介して S3 へアクセス可能になりました。

Lab2a-Task3: Web サーバーへ S3 用 Plugin の追加

このセクションでは WordPress にプラグインをインストールして、Blog 投稿時に画像ファイルを Task1 で作成した S3 バケットに自動的にアップロードする設定を行います。S3 バケットへの画像のアップロードする際に IAM による認証・認可が必要なので、Task2 で作成した IAM Role を利用します。

ブラウザで WordPress の管理者用ページにアクセスします。
管理者用ページの URL は、http://<Web Server01 のパブリック IPv4 DNS)>/wp-admin/ と指定します。 <Web Server01 のパブリック IPv4 DNS> を Web Server01 のパブリック IPv4 DNS に置き換えてください。

以下は URL の例になります。
http://ec2-52-68-107-123.ap-northeast-1.compute.amazonaws.com/wp-admin/
WordPress の管理画面にログインします。

ユーザー名 admin

パスワード Lab1 で設定した WordPress 管理者用パスワード
WordPress の管理画面で、左側のメニューで [プラグイン] をクリックします。
プラグインの設定画面で、「プラグイン」の横の [新規追加] をクリックします。
キーワードに WP Offload Media Lite for Amazon S3 と入力します。すると、検索結果が表示されます。
検索結果の中から [WP Offload Media Lite for Amazon S3, DigitalOcean Spaces, and Google Cloud Storage]を探し、 [今すぐインストール] をクリックします。
インストールが完了すると インストール ボタンが 有効化 ボタンに変わるので、[有効化]をクリックします。
プラグイン一覧画面で、 WP Offload Media Lite の Settings をクリックします。
WP Offload Media Lite の設定画面で、 STORAGE PROVIDER として Amazon S3 を選択します。

この設定で、WordPress の画像ファイルのアップロード先を S3 に指定しました。
My server is on Amazon Web Services and I’d like to use IAM Roles の左にあるラジオボタンを選択します。

この設定で、画像ファイルのアップロード時に EC2 インスタンスへアタッチされている IAM Role を利用するように、アプリケーション(WordPress プラグイン)の設定をしています。
WP Offload Media Lite の設定画面で、 Next をクリックします。
What bucket would you like to use?(どの S3 バケットを使用しますか？) と問われているため、Browse existing buckets をクリックします。

S3バケット一覧が表示されない方は、Task2 を手順に従い実施したか見直してください

【考えてみよう!】 "Browse existing buckets" をクリックすると、S3 Bucket が参照できるのはなぜですか？ Task3 では、awsstudent として AWS マネジメントコンソールから操作しているわけではありません。WordPress の admin として、WordPress というアプリケーションから S3 バケット一覧を参照しています。この時、どのような認証・認可が行われた結果、S3 バケット一覧を取得できたのでしょうか？
Web Server01 がアクセス可能な S3 バケットが一覧表示されるので、Task1 で作成した S3 バケットを選択して Save Selected Bucket をクリックします。

この設定で、画像ファイルのアップロード先となる具体的な S3 バケットを指定しています

”設定を保存しました” と表示されていれば、次の新規投稿からは画像が S3 バケットにアップロードされます
Offload Media Lite の STORAGE 設定で Object Versioning を OFF に切り替えます。
Save Changes をクリックします。プラグインの設定が保存されます。


ユーザー名	`admin`
パスワード	Lab1 で設定した WordPress 管理者用パスワード

Lab2a-Task4: WordPress の動作確認

ラボのこのセクションでは、WordPress で作成したブログサイトの動作確認を行います。
画像付きの記事を投稿し、投稿した画像が S3 にアップロードされているかを確認します。

WordPress の管理用ページで、画面左の [投稿] メニューから [新規追加] をクリックして、画像付きの記事を投稿します。

注意 : WordPress の管理者 (admin) パスワードを忘れてしまった場合は、上記設定が保存された MySQL データベース上のデータを直接修正する必要があります。
こちらをクリックすると復旧手順が記載してあります。MySQL の操作に不慣れな場合はインストラクターに連絡してください。
ブログのタイトル (英語で入力してください) と本文を入力し、 [ブロックの追加]アイコンをクリックし、 [画像]を選択します。

ヒント: WordPress のデフォルト設定では、ブログのタイトルを日本語にすると投稿が正常に表示されません。
[アップロード] をクリックし、PC のローカルにある任意の画像ファイルを選択します。
さらに、右下の [開く] をクリックします。
ブログに画像が挿入されたことを確認し、画面右側にある [公開] をクリックし、[公開] をクリックします。
投稿したブログ内容を表示するには、[投稿を表示] をクリックします。
ブログ記事内の画像を右クリックして別のタブで開き、表示された画像の URL を確認します。
画像の URL が S3 バケットの URL であることが確認できます。画像ファイルの URL をメモしてください。

ここまでの設定で、Blog に表示させるの画像データを EC2 インスタンス (Web Server01) のローカルストレージ (EBS) ではなく、99.999999999% の耐久性となるよう設計されている S3 バケットに保管できるようになりました。
【考えてみよう!】 Amazon S3 のメリットの１つは 99.999999999% の耐久性です。しかし、EC2 インスタンスのローカルストレージ (EBS) と比較して、Blog の画像保管先として他にも有用な点はありませんか？ヒント：一番最初に投稿した Blog の画像は、どこに保管されていますか？

ここまでの手順で、Web サーバーと画像データを疎結合にし、画像データの可用性と耐久性を向上できました。

Lab2a-Challenge Task1: ブログ画像へのアクセス制御

このセクションでは S3 バケットにアップロードされた画像に対して、 WordPress のプラグインがどのようなアクセス制御を行っているのか確認します。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

AWS マネジメントコンソールで [サービス] から [S3] をクリックします。
[バケット] をクリックします。
Task1 で作成した S3 バケット（Blog 画像のアップロード先）をクリックします。
[wp-content] > [uploads] > [yyyy(トレーニングを実施している西暦)] > [mm(トレーニングを実施している月)] をクリックします。
WordPress のプラグインがアップロードした画像の一覧が表示されます。 Task4 でメモした Blog 画像ファイルをクリックします。
[アクセス許可] タブで [アクセスコントロールリスト(ACL)] 設定を参照します。
[全員(パブリックアクセス)]　に対して “オブジェクト 列の 読み込み”　権限が付与されていることを確認できるはずです。

これは Amazon S3 の ACL (Access Control List) 機能の Object ACL の設定です。オブジェクト≒ファイル単位で全員 (AllUser = Internet) に対して Read (読み取り) を許可しています。パブリックアクセスを許可しているため、Internet 上のどこからでも、IAM による認証・認可なしで当該画像ファイルに読み取りアクセスができる状態です。
【考えてみよう！】 Everyone へのオブジェクトの読み取り権限を無効にすると、どのような動作になるでしょうか？
アクセスコントロールリスト (ACL)の 編集する をクリックします
全員 (パブリックアクセス) に対して オブジェクト 列の [読み込み] のチェックを外します
[変更の保存]をクリックします
ブラウザから WordPress にアクセスして、Task4 で新規作成した Blog 投稿を参照します。ブラウザによるキャッシュの影響を避ける場合は Ctrl + F5 キーを押してページを更新します。 Blog のタイトルや本文は表示されますが、画像だけ表示されない状態になっているでしょうか？
Task4 でメモした画像ファイルの URL をブラウザのアドレスバーにコピーして、画像ファイルへ直接アクセスします。 Access Denied のレスポンスが表示されていますか？
AWS マネジメントコンソールへ戻り、画像ファイルへの読み取りアクセスを再度有効化します。

以上のことから、WordPress のプラグインはブログ投稿時に S3 バケットへ画像ファイルをアップロードすると同時に、個々の画像ファイルのアクセス制御として S3 の Object ACL 機能を利用してパブリックなオブジェクトの読み取りが可能になる設定を行っていることが確認できました。

実際のアプリケーション環境では Object ACL や Bucket ACL ではなく Bucket Policy の利用が推奨されています。これは、Prefix、Object などのリソースや AWS アカウント、IAM User、IAM Role、IP アドレス、日時、MFA 有無 etc の細かな条件に応じて、きめ細やかなアクセス制御を行う必要があるためです。

Lab2a-Challenge Task2: インスタンスメタデータの参照

このセクションでは WorsPress サーバのインスタンスメタデータを参照して、WordPress のプラグインが認証情報を使用して S3 Bucket にアクセスしているのか確認します。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

作成した Web サーバー (Web Server01) へログインします。

ログインの詳細な方法については左側の 受講者向けリソース の Option_instance-Connection.md を参照してください。
以下のコマンドを実行します。
```
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/WP-Role
```
・“curl” コマンドは、指定された URL に対して HTTP リクエストを行って、データを取得します。・“169.254.169.254” という IP アドレスは、リンクローカルアドレスと呼ばれています。AWS クラウドでは、EC2 インスタンスからこのリンクローカルアドレスに HTTP リクエストを行うと、EC2 インスタンスの外部にあるインスタンスメタデータサービスが応答するように構成されています。・インスタンスメタデータには様々な情報が含まれていますが、"/iam/security-credentials/[IAM Role Name]“という Path を指定することで、IAM Role “WP-Role” と連動して WordPress サーバに付与された一時的な認証情報を参照できます。
コマンドの実行結果を参照してみましょう。

・“AccessKeyId”、“SecretAccessKey”、“Token” のセットが一時的な認証情報です。・アプリケーションから AWS へアクセスする際の認証情報のパターンの１つが、この “AccessKeyId”、“SecretAccessKey”、“Token” のセットです・みなさんが AWS マネジメントコンソールのサインインする際の認証情報が、IAM User 名 “awsstudent”、パスワード　のセットです・“Expiration” が一時的な認証情報の有効期限を示します。UTC (協定世界時) で表記されます

WordPress のプラグインは S3 Bcuket へ画像のアップロードをする際に、IAM Role 経由で生成された一時的な認証情報を利用しています
お手元の PC から、インスタンスメタデータにアクセスしてみましょう。ブラウザのアドレスバーに http://169.254.169.254/latest/meta-data/iam/security-credentials/WP-Role と入力し、Enter キーを押します。ブラウザからエラーが返ってきましたか？
【考えてみよう!】 WordPress サーバからインスタンスメタデータにアクセスできたにも関わらず、なぜブラウザからはインスタンスメタデータにアクセスできないのですか？
以下のコマンドを実行します。
S3 バケットが参照できるはずです。
```
aws s3 ls
```
AWS マネジメントコンソールで[サービス] から[EC2] をクリックします。
ナビゲーションペインで[インスタンス] をクリックし、 Web Server01 を選択します
[アクション] から [セキュリティ] を選び、 [IAM ロールを変更] をクリックします
[IAM ロール] から [IAM ロールがありません] を選び、 [保存] をクリックします。

IAM ロールがありません を選択すると、インスタンスに現在アタッチされている IAM ロールが削除されます。“選択したインスタンスからを削除してよろしいですか?” の警告がでますが、そのまま手順を実行してください
IAM ロールをデタッチ のポップアップが出るので、入力フォームに デタッチ と入力します。
[デタッチ] をクリックします。
以下のコマンドを実行します。
S3 バケットが 参照できなくなっている はずです。
```
aws s3 ls
```
以下のコマンドを実行して、IAM Role 経由で払い出されている一時的な認証情報を参照します。
404 Not Found のエラーが返ってくるはずです。
```
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/WP-Role
```
これは、IAM Role をデタッチしたため、認証情報がインスタンスメタデータから削除されたからです。
AWS マネジメントコンソールで[サービス] から[EC2] をクリックします。
ナビゲーションペインで[インスタンス] をクリックし、 Web Server01 を選択します
[アクション] から [セキュリティ] を選び、 [IAM ロールを変更] クリックします
[IAM ロール] から [WP-Role] を選び、 [保存] クリックします。

再度、IAM Role “WP-Role” が Web Server01 にアタッチされましたので、Web Server01 から S3 へのアクセスが可能になっています。

終了

この Lab では Amazon S3 を使用して EC2 インスタンスとデータを分離することで、可用性の高いブログサイトを構築しました。

Lab2a Architecture

お疲れさまでした。これで Lab2a は終了です。このラボで作成した環境は継続して利用するので、[ラボを終了] はクリックしないでください。

補足：WordPress の管理者用パスワードの復旧手順

Web Server01 に Session Manager でログインする。
次のコマンドで RDS に接続する。
```
mysql -u wpuser -p -h  [メモしてあるRDS DBインスタンスの"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 に戻る。