S3とCloudFrontでの配信
やること
・S3に画像を置けて配信するバケットを作る →低コストのストレージ
・Offload Media Liteプラグインをインストールと設定
・CloudFrontの作成 →配信のキャッシュで高速化
Udemyの研修で学んだ通りやっているのだけど、改めて同じ内容のサイトを見つけたので貼り付ける
https://qiita.com/kono-hiroki/items/6cccf3e33cb7d844c6f7
目次
・S3にWordpressの画像を置くようにする
閲覧者→インターネット→EC2-wordpress →S3 ←…文字 ↓ ←…‥… 画像‥‥←
作業概要
-S3のバケットを作成
アクセス設定をパブリック、そしてACL設定を有効にして所有者は読み書き、その他の人を全部読み取り専用にする
-プログラムからS3へアクセスできるIAMカウントを作成
S3バケットの作成
AWS S3からバケットの作成を選んでウィーザードを進めました。ちなみに何度かやったことがありました。
バケットの名前は世界で一意になること、私の場合はサブドメイン名にする名前をハイフンでつなぎました。リージョンはいつもの東京です。「オブジェクト所有者」は詳細はよくわからないのですが、このS3画像から配信する場合はACL有効にしてACLを設定してあげないとアップロードできないようです。よくわからないから今回も試しにACL無効からスタート、やっぱりWordPressからS3に画像を書き込むことができなかったので後にここをACL有効にして設定していきました。
アクセス設定はここから配信するので、MAXユルユルにするためパブリック・アクセスをすべてブロックのチェックを外します。
すると下に「〜承認します」をチェックさせられるので従います。
後戻りになりますが、ACL有効の設定をします。
S3のバケットの「オブジェクト所有者の編集」から「ACL有効」を選択し、その下の「〜承認します」にチェック、オブジェクト所有者はよくわかりませんが、デフォルトの希望するパケット所有者のまま。そして「変更の保存」を押す。ACLというので細かく設定をします。
「ACL無効(推奨)」の方の説明に「このアカウントによって所有されます」とあるのでこれを設定しているIAMアカウントのことで、S3へプログラムからアクセスできるIAMは別なのでダメなのでしょうか?
S3のアクセス許可のタグで設定します。バケット所有者は「読み書き」、ほかは「読み込み」のみに設定しました。どの程度やればよいのかわかりませんが、記事ではもう少し先の話ですが、アクセス権に関してはこの設定でWordpressからS3に書き込めることができました。
-プログラムからS3へアクセスできるIAMカウントを作成
私は既にS3に対してプログラムからアクセスさせているので直ぐに作っているのでこれを使いました。
ユーザー:s3User ポリシー:AmazonS3FullAccess
ポリシー名通りのポリシーだったと思います。作成時にアクセスキー IDとシークレットアクセスキーを得られるのでそれが重要です。プログラム=今回の場合はOffload Meia Liteにセットします。AWS CLIからS3にアクセスするのにも使います。
-OffloadMediaLiteのプラグインをインストール
WordPressのプラグインで検索してインストールします。道路のoffroadではなくて負荷のloadです。
インストールが終わるとwp-config.phpに何かを設定してくれとのメッセージが。OffloadMediaがS3にアクセスするために先程のS3userのアクセスキーIDとシークレットアクセスキーを記述するところです。この文字列をコピーしてEC2にSSHしてWordPressの設定ファイルwp-config.phpに挿入します。
’access-key-id'=> '******'と'secret-access-key'=>'******'の***をS3userのものに書き換えてください。
ここで必要かわかりませんが、apache2の再起動をしました。sudo systemctl restart apache2ですかね。
プラグインをリロードすると、状況が変わって、私のAWSのS3が無事見えたようで、どっちか選べえだと。
無事、S3が見えるようになったようで、他の設定項目が出てきます。
この時点でメディアライブラリにアップロードしても書き込みされてなく、ACLの設定をしてようやく書き込めました。書き込めたかどうかはAWSのS3のバケットのオブジェクトを見ればファイルのリストがあるので直ぐにわかります。
書き込みのテストに使った画像がこれです。右クリックして「新しいタブで画像を開く」とかしてURLを確認します。後々、勝手にアドレスが最終のサブドメインになりましたが、この段階では確か、amazonドメインのS3のアドレスでした。
CloudFront経由で画像を配信する
CloudFrontを作成します。
こんな感じになります。より閲覧者に近いところにあるキャッシュサーバーから配信され、早くて、S3に負荷がかかりません。
閲覧者→インターネット→EC2-wordpress →S3 ←…文字 ↓ ←…CloudFront‥… 画像‥‥←
CloudFrontのところで「ディストレイビューションを作成する」とします。CNAMEに自分のドメインから配信されるようにサブドメインを記述します。何やらこれをやるのはSLL化してないとダメだそうで、でもここから簡単にできます。下の「証明書をリクエスト」をすればトントンと進みます。
-Route53でAレコードー別名を定義、static.the-world-star.comをCloudFrontのドメインに結びつける。
-OffloadMediaLiteの設定
S3のamazonのドメインでもなく、CloudFrontのドメインでもなく、オリジナルのドメインのサブドメイン"static.the-world-star.com"から配信されていることにする。そのために…
設定のDeliveryだったっけな?S3となっているところをクリック、そこをCloudFrontとすると代替えドメイン=CNAMEの設定項目が出るようになる。ここにstatic.the-world-star.comを記述する。
S3を覗くと既に全画像ファイルがS3にアップされていた。おそらく、OffloadMediaの最後の設定にてS3に既存の画像がコピーされたよう。→間違い。旧ファイルはアップされてなかった。EC2サーバーを覗くとこれまでのファイルも残っている。「消す」というオプションは新規アップしたものだけか?
旧記事を見てみると画像へのリンクは前のまま。static.なし。これから、旧記事にstaticと付けていくか、CloudFrontで旧記事の画像URLをstaticに変換してやるとS3の画像が配信されるのであろう。 → 旧画像のアップも必要