public memo

エンジニア向け小ネタ書き溜め用。公開日記だけど親切な文章とは程遠いかもしれない。

WordPressの画像をAWS S3にあげる

2017-07-31 by MasakiMisawa
Tweet
このエントリーをはてなブックマークに追加
Pocket
LINEで送る

サーバのディスクサイズ圧迫主原因となる画像。
別の場所にアップしてサイト上からは参照するだけにするのがお決まりですが、ワードプレスではサーバ上にあがってしまうので、S3に避難させてサーバ上には残さないようにしてみました。

と言ってもプラグイン使うだけなんですがw
設定方法などは最低限に留めて、サーバ上からS3に避難させるメリット、デメリットと、設定時にハマった点を書いてみます。

メリット

・サーバ上のディスクサイズ削減
今回の目的。
サーバのディスクサイズ上限がいくつかにもよりますが、EBSを10GBにしている(サイズアップもなるべくやりたくないw)当ブログの環境では結構馬鹿にならなさそうだったので、外部に避難させることにしました。

・CloudFrontを使用する場合など、画像のキャッシュ表示対応がやり易い
サーバ上にアップした画像でもワードプレスのプラグインで画像のキャッシュ表示はできますが、あまりプラグインは入れたくないのもあり。

デメリット

・保存料金(S3の利用料金)が別にかかる
よほどの大容量を使ったりしなければ大した額にはなりませんが(そもそもそんな大容量使おうとしたらサーバに置ききれないんですがw)、やっぱり料金が別に発生するのはちょっと嫌ですよね。
サーバ上のディスクサイズが残り少なくなってきた段階でS3に移行するのもありですが、今回使用したプラグインが新しくアップした画像のみS3に避難させるというものだった(プラグイン導入前に使用していた画像はサーバ上に残り続ける)ので早めにS3に避難させる方を選択しました。

・一部プラグインでサーバ上に画像がある事前提の動作依存があるらしい
当ブログでは依存のあるプラグインは使っていなかったので問題ありませんでしたが、一部プラグインで画像がサーバ上に置かれていないと正しく動作しない場合があるそうです。

・サーバインスタンスのスナップショットから復元時に画像が復元されない
保存場所が別に分かれる都合上の問題。
と言っても、画像アップロード後にサーバインスタンスをアップロード前の過去の状態に復元して、アップロードした画像が残ってしまったとしても特別困ることは多分ない気がします。
唯一困りそうな場面としては、画像削除後にサーバインスタンスを削除前の状態に復元した場合に削除した画像が戻らない事ぐらいでしょうか(相当レアケース)

使用したプラグインと、その設定方法

1. 以下の二つのプラグインをインストール & 有効化

【Amazon Web Services】
https://ja.wordpress.org/plugins/amazon-web-services/

【WP Offload S3 Lite】
https://ja.wordpress.org/plugins/amazon-s3-and-cloudfront/

2. S3へのフルアクセスロールを付けたAWSのIAMユーザを用意

S3の画像を参照、書き込みするのでフルアクセスロールを持ったIAMユーザをAWS上で作成し、同ユーザのaccess keyとsecret keyを用意する必要があります。
IAMユーザのクレデンシャルを使用してS3にアクセスする方式は変更できないようなので、あまりやりたくないですがS3へのアクセスロールのみをアタッチしたユーザを用意します。
また、後述しますがプラグインの初期設定時のみ全バケットへのアクセスロールが必要になるようなので、IAMユーザを作る段階ではアクセス可能対象バケットの絞り込みをせずに全バケットへのアクセスを許可しておきます。

3. 作成したIAMユーザのクレデンシャルをワードプレスに紐付け

管理画面上からクレデンシャルを入力してDBのレコード内に保存する事もできるようですが、セキュリティ上あまりよろしくないのでwp-config.phpに以下の2行を加える形で紐付けるのが良いかと思います。

AWS IAM CREDENTIAL
ZSH
1
2
define( 'DBI_AWS_ACCESS_KEY_ID', '********************' );
define( 'DBI_AWS_SECRET_ACCESS_KEY', '********************************' );

4. 画像アップロード先のS3バケットを指定

WordPress管理画面左部メニューに「AWS」が追加されているので選択し、「S3 and CloudFront」を選択します。

Browse existing buckets のテキストリンクを押すと上で紐付けたIAMユーザからアクセス可能な全S3バケットが表示されるので、画像をアップロードする対象バケットを選択します。
* この段階でIAMユーザでアクセス可能なS3バケットを絞り込んでいるとアクセス可能なバケットが表示されなくなる不具合があるようです。
気持ち悪いですが、ここで選択するまでの間は全バケットにアクセス可能なロールをアタッチしておくことで対象バケットが表示されない状態を回避可能です。
一度選択してしまえば後はアクセス可能なバケットを絞り込んでも問題ないようなので、対象バケットを選択後にIAMユーザへのS3フルアクセスロールの対象を紐付けたバケットだけに絞り込む対応をとりました。

5. アップロード画像をサーバ上に残さないよう変更

上記手順まででアップロード画像をS3にあげられるようにはなりましたが、今回のそもそもの目的はアップロードした画像でサーバ上のディスク容量を圧迫しないようにすることだったのでアップロードした画像をサーバ上に残さないようにする設定をしないと意味がありません。
設定は上記手順の時と同じく、管理画面左部メニュー「AWS」 → 「S3 and CloudFront」 と選択し、ADVANCED OPTIONSから「Remove Files From Server」をONに変更します。

ということで、新規にアップロードする画像をサーバ上に残さずS3にアップロードできるようになったところで今回はおしまい。
次回は今回導入したプラグインを入れる前にアップロードしていた画像をサーバ上からS3に移行する手順について書いてみます。

Tweet
このエントリーをはてなブックマークに追加
Pocket
LINEで送る

カテゴリー: S3 タグ: S3

profile

profile_img Web系のソフトウェアエンジニアです。
野球観戦(横浜DeNAベイスターズ)、格闘ゲーム、カメラ、ランニング、愛犬、インテリア、美味しいものの食べ歩き、などなどが好き。

  • twitter MasakiMisawa
  • facebook MisawaMasaki
  • github MasakiMisawa
  • instagram masakimisawa
  • follow us in feedly

search

recent entry

  • M1 MacでAppleシリコンとIntelプロセッサのバイナリ管理を分離して共存させる
  • M1 MacでtfenvからTerraform1.0.2未満のダウンロードに失敗する問題を無理矢理解決する
  • GitHub ActionsからAWS利用時に永続的クレデンシャル情報を渡さないようにする
  • TerraformでAuroraのエンジンバージョンアップグレードをする時は、対象リソースをクラスターだけに絞る
  • CloudWatch Logsに出力されたエラーログ本文のSlackへの転送

category

  • AWS (17)
    • ACM (1)
    • AWS CLI (1)
    • Chatbot (2)
    • CloudWatchAlarm (1)
    • CloudWatchLogs (1)
    • CodeBuild (3)
    • DynamoDB (1)
    • IAM (1)
    • Kinesis (2)
    • Lambda (5)
    • OpenId Connect (1)
    • RDS (1)
    • S3 (2)
    • SNS (2)
    • SSM (2)
    • STS (1)
  • CI (2)
  • GCP (1)
    • PageSpeedInsights (1)
  • Git (3)
    • GitHub (2)
      • GitHub Actions (1)
  • M1 Mac (2)
  • Python (2)
  • Redis (1)
  • selenium (1)
  • Slack (3)
  • Terraform (3)
  • その他 (1)

archive

  • 2022年2月 (3)
  • 2021年1月 (1)
  • 2020年12月 (1)
  • 2020年11月 (1)
  • 2020年9月 (2)
  • 2020年8月 (1)
  • 2020年7月 (1)
  • 2020年6月 (1)
  • 2020年5月 (2)
  • 2020年4月 (1)
  • 2020年3月 (1)
  • 2020年1月 (1)
  • 2019年1月 (1)
  • 2017年12月 (1)
  • 2017年9月 (1)
  • 2017年8月 (1)
  • 2017年7月 (1)
  • 2017年2月 (1)
  • 2016年10月 (1)

tag cloud

ACM Aurora AWS AWS CLI Billing CI CloudWatchAlarm CloudWatch Logs CodeBuild Code Format Docker DynamoDB EC2 env find firehose Git GitHub GitHub Actions Homebrew husky IAM Role Java kinesis KinesisFirehose Lambda lint-staged M1 Mac Node.js OpenId Connect PHP Python RDS Redis RI S3 Selenium Slack SNS SSM Terraform tfenv セッションマネジャー リモートワーク 生産性

Copyright © 2025 public memo.