Fargate＋WordPress構築 S3と連携 ③

はじめに

・Fargate＋WordPress構築 WordPressが表示されるまで ①
・Fargate＋WordPress構築　HTTPS化 ②
の続きです。

現在の状態では、画像を保存しても、コンテナが停止するとなくなってしまいます。
WordPressのプラグインであるWP Offload Media Liteを使用し、S3に画像を保存することで、コンテナが停止しても画像が表示されるようになります。
また、CloudFrontで画像をキャッシュする仕組みをつくります。

完成構築図

流れ

• ALBを設置
• Route53を作成
• Dockerfileを作成
• ECRを作成
• クラスターを作成
• タスク定義を作成
• サービスの作成
• ACM証明書を作成
• ELBに証明書を設置
• 証明書を設置したCloudFrontを作成
• Route53でCloudFrontへのルーティング設定
  ↓ここから
• IAMロール作成
• S3を作成し、Wordpressのプラグインで連携
• CloudFrontで画像等のキャッシュ設定
• キャッシュの確認

IAMロール作成

S3FullAccessポリシーを持ったIAMロールを作成し、タスク定義のタスクロールにアタッチします。
これによってFargateは、S3へのアクセス権限を持つことができます。

タスク定義を更新しましたので、必ずサービスのタスク定義を最新にし、タスクを再起動しましょう

S3を作成し、Wordpressのプラグインで連携

S3を作成し、プラグインでメディアファイルをS3に保存します。

まず、S3バケットを作成します。名前を記述し、パブリックアクセスをすべてブロックのチェックを外し、ACL有効にし、他はデフォルトで作成します。

そして、URL:https://xxxx.work/wp-admin/install.phpにアクセスして、言語やサイト名を適当に入力し、WordPressインストールをクリックします。

WordPressのプラグインに移動後、WP Offload Media Liteのバージョンを更新し、有効化します。

use IAM Polesを選択します。
先程、IAMロールをアタッチしましたので、OKです。

先ほど作成したバケット名を記入し、保存します。

Pathはwp-content/uploads/になっております。
DELIVERYのAmazon S3のChangeをクリックします。

CloudFrontを選択し、保存します。

Custom Domain (CNAME)にドメインxxxx.workを入力し、保存します。

画像のURLは、`https://ドメイン/wp-content/uploads/s3保存先/`になっていることを確認します。

画像を添付した記事を投稿し、コンテナを停止、起動しても画像が表示されていることを確認します。
また、S3にも保存されていることを確認します。

エラー①

WP Offload Media Liteをインストール後以下のエラー分が発生

サイトで技術的な問題が発生しています。サイト管理者のメールを確認して指示に従ってください。

CloudFrontをキャッシュを削除、chromeのキャッシュ削除すると、コンテナを再起動すると解決しました。

エラー②

投稿するため、画像を添付すると、この画像にはalt属性が指定されておらず、ファイル名はx.jpgですと表示される。

コンテナを再起動すると、解決しました

CloudFrontで、画像等のキャッシュ設定

・オリジンを1つ作成
・ビヘイビアの3つ作成します。

オリジンの作成

現在1つオリジンがあり、ALB経由でコンテナ内にアクセスしますが、画像はS3にありますので、S3用のオリジンを作成します。

オリジンの作成

　・オリジンドメイン：[S3で作成したバケットを選択]
　・オリジンパス：なし
　・S3バケットアクセス：はい、OAIを使用します。
　・オリジンアクセスアイデンティティ：新しいOAIを作成
　・バケットポリシー：はい、自動で更新します。

S3のバケットポリシーにOAIが反映

新しいOAIを作成を選択してオリジン作成しました。
作成後、S3バケットポリシーを確認すると、以下の通り、S3のオブジェクトは、CloudFrontのみが取得することができることがが分かります。

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1JRJRKHE5P02C"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::wordpress-s3-20211006/*"
        }
    ]
}

オリジンが2つになりました。

ビヘイビア作成

WordPressでは、　phpファイルとwp-adminディレクトリ配下の2つは、キャッシュしません。
キャッシュするものは静的な画像やhtmlファイルであり、動的なファイルをキャッシュすると不具合が出てしまいます。

ALB経由でコンテナ内にアクセスするオリジンに対して、phpファイルとwp-adminディレクトリ配下をキャッシュしないようにします。
また、S3経由でS3の画像にアクセスオリジンに対して、画像などの/wp-contet/uploads配下全てキャッシュするようにします。

オリジンがALBのphpファイルのビヘイビアを作成

設定
　・パスパターン：*.php
　・オリジンとオリジングループ:[作成したALBを選択]
　・オブジェクトを自動的に圧縮:No
　・ビューワープロトコルポリシー:Redirect HTTP to HTTPS
　・許可されたHTTPメソッド：GET,HEAD,OPTION,PUT,POST,PATCH,DELETE
ビューワーのアクセスを制限する：No
　・Cache policy and origin request policy (recommended):
キャッシュポリシー：CachingDisabled
オリジンリクエストポリシー：AllViewer

オリジンがALBのwp-adminディレクトリ配下のビヘイビアを作成

設定
　・パスパターン：/wp-admin/*
　・オリジンとオリジングループ:[作成したALBを選択]
　・オブジェクトを自動的に圧縮:No
　・ビューワープロトコルポリシー:Redirect HTTP to HTTPS
　・許可されたHTTPメソッド：GET,HEAD,OPTION,PUT,POST,PATCH,DELETE
ビューワーのアクセスを制限する：No
　・Cache policy and origin request policy (recommended):
キャッシュポリシー：CachingDisabled
オリジンリクエストポリシー：AllViewer

オリジンがALBのwp-jsonディレクトリ配下のビヘイビアを作成

wp-adminディレクトリ配下と同じ設定で作成します。

オリジンがS3の/wp-contet/uploads配下のビヘイビアを作成

設定
　・パスパターン：//wp-content/uploads/*
　・オリジンとオリジングループ:[作成したS3を選択]
　・オブジェクトを自動的に圧縮:Yes
　・ビューワープロトコルポリシー:Redirect HTTP to HTTPS
　・許可されたHTTPメソッド：GET,HEAD
ビューワーのアクセスを制限する：No
　・Cache policy and origin request policy (recommended): キャッシュポリシー：CachingDisabled、 オリジンリクエストポリシー：なし

ビヘイビアは4つできました。優先順位は画像の通りです。

オリジンがALBのデフォルト (*)のビヘイビアについて

前回作成したデフォルト (*)のビヘイビアは、キャッシュしない設定にしています。
というのも、phpファイルとwp-adminディレクトリ配下以外にもキャッシュすると不具合が出る可能性があるためです。
（プラグインの影響やjsファイルなど）
ただし、ネットでは問題ないという記事もあるため、デフォルト (*)に対してキャッシュする設定にしてもいいかもしれません。
その場合は、デフォルト (*)に対して以下の設定をするとキャッシュできます。
設定
　・パスパターン：デフォルト (*)
　・オリジンとオリジングループ:[作成したALBを選択]
　・オブジェクトを自動的に圧縮:Yes
　・ビューワープロトコルポリシー:Redirect HTTP to HTTPS
　・許可されたHTTPメソッド：GET,HEAD
ビューワーのアクセスを制限する：No
　・Cache policy and origin request policy (recommended): キャッシュポリシー：CachingDisabled、 オリジンリクエストポリシー：AllViewer

キャッシュの確認

画像に対してキャッシュできているか確認します。
画像のリンクをコピーしアクセスします。URLはこちらのようになっているはずです。
https://xxxx.work/wp-content/uploads/2021/10/06222544/%E3%82%A2%E3%83%8F%E3%82%99%E3%82%BF%E3%83%BC%E7%94%A8.jpg

ターミナルの以下のコマンドでキャッシュできているか確認できます。

$ curl -I <http://cloudfrontのドメインネーム/>

$ curl -I https://xxxx.work/wp-content/uploads/2021/10/06222544/%E3%82%A2%E3%83%8F%E3%82%99%E3%82%BF%E3%83%BC%E7%94%A8.jpg

HTTP/2 200 
content-type: image/jpeg
content-length: 34450
date: Wed, 06 Oct 2021 14:39:45 GMT
last-modified: Wed, 06 Oct 2021 13:25:45 GMT
cache-control: max-age=31536000
expires: Thu, 06 Oct 2022 13:25:44 GMT
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront

キャッシュできていない
x-cache: Miss from cloudfront

キャッシュできている
x-cache: Hit from cloudfront

ついに完成しました!

この記事では、CodePipelineを利用したECSのローリングデプロイの方法を紹介しています。

こちらではコンテナ内にアクセスするECS Execを紹介しています。

参考