【キャプチャ付解説】無料で本格的WordPressブログを構築・運営【6】:WordPressのメディア(画像など)をGCSと連動させる

WordPress
この記事は約13分で読めます。

GCP, GCS, Cloudflare, mailgunを使って無料で本格的なWordPressブログを構築・運営するための解説記事Step7です。

全体の流れや構成の概要は下記を参照ください。

メディアをGCSと連動するメリット

メディアをGCSと連動させると何が嬉しいのかしら。

まずは容量かの。連動させない場合、画像ファイルなどのメディアもWordPressが動いているCompute Engine上に保存することになる。Compute EngineのディスクサイズはAlways Freeの範囲だと30GBが最大じゃ。しかも、メディア以外、それこそOSなど全て込み込みで30GBまでじゃ。メディア以外の容量も考えると、実質的にメディアに割けるのはせいぜい25GB程度じゃろう。

一方、GCSは5GBまでだがAlways Freeが適用されるし、5GBまるごとメディアに使えるから、Compute Engineとは別途メディア専用の容量を確保できるぞ。また、GCSの方が容量あたりの値段もCompute Engineの6割程度で済むんじゃ。

たしかにそれはメリットだわね。

あとはパフォーマンスかの。連動しない場合、メディアもCompute Engineから配信するから、その分Compute Engineのリソース(CPUやメモリ)を消費してしまうんじゃ。しかも、Compute Engineはリソースを増やすとAlways Freeの範囲外になったりとお金にも絡んでくる。

一方、GCSから配信すればCompute Engineのリソースを消費しないし、GCSはリソースで課金されるわけじゃないし、Always FreeのCompute Engineより性能もいい(速くメディアを配信できる)はずじゃ。

いいことづくめだわね。

ただし、容量に関しては、WordPress(Compute Engine)とGCSの両方にファイルを残すCDNモードを選択する場合は、Compute Engine側のディスク容量が上限となってくる。(詳細は本記事後半のWP-Statelessプラグインの説明の中で触れます。)

それでも、本格的にGCPでWordPressを運営するならGCSとの連動は必須だと考えてほしい。

GCSのバケットを作成する

それでは説明していくぞ。

まずは、GCSのバケットを作成するため、GCSの画面にアクセスじゃ。

GCP上では単純に「Storage」と表現されているのね。

「バケットを作成」ボタンをクリックじゃ。

まずはバケットに名前をつけるんじゃ。

独自ドメインでアクセスできるようにするには、「media.norio.io」のように「サブドメイン+ルートドメイン」となるように名前を付ける必要があるんじゃ。(この例では「media」がサブドメイン)

ちなみに、キャッシュにもあるように、バケットの名前をドメインにするには、そのドメインの所有権が確認済みである必要があるんじゃ。ただ、Google Domainsでドメインを取得した場合は、所有権の確認は不要(自動)だから、特に気にする必要はないんじゃ。

Google Domainsにしておけばよかったわ。

Google Domains以外でドメインを取得した場合、バケットにドメイン名をつけるには下記ページを参照するといいじゃろう。

Domain-named bucket verification  |  Cloud Storage  |  Google Cloud

次はロケーションじゃ。ロケーションタイプはAlways Freeの対象である「Region」を選択するんじゃ。それ以外はAlways Freeではないから課金されてしまうぞ。

ロケーションについてもAlways Freeはus-east1、us-west1、us-central1だけだから、WordPress(Compute Engine)同様、us-west1にしておこうそれ以外のロケーションは課金されるぞ。

念のためAlways Freeの最新条件は下記オフィシャルで確認しておくとよいじゃろう。Cloud Storageの項じゃ。

Google Cloud の無料プログラム

ストレージクラスは「Standard」じゃ。他の2つはキャプチャの説明の通り、Webに掲載するための用途には向いておらん。

この辺りはよく分からなければデフォルトでいいじゃろう。

ここもデフォルトじゃな。

バケットができたわね。

Cloudflareの設定変更

GCSに独自ドメインのURLでアクセスするためのDNSを設定する

GCSのバケットにドメイン名を付けただけではそのドメインのURLでGCSのメディアにアクセスすることはできない。

独自ドメインのURLでアクセスするにはDNSの設定が必要なんじゃ。

オフィシャルな説明としては下記じゃな。

オフィシャルついでにひとつだけ重要な注意点があるんじゃが、今回説明する方法ではCloudflareとGCSの間の通信はSSL非対応で、httpでアクセスされるんじゃ。そのため、公開されては困るようなものはメディアにアップロードしないことが前提となるんじゃ。一般公開するブログ用のメディアであれば問題ないじゃろう。一般公開できないような機密性のあるメディアをアップロードするようなケースにおいては、オフィシャルでも触れられているようにGCPにロードバランサを用意するなどの必要があるようじゃ。

静的ウェブサイトをホストする  |  Cloud Storage  |  Google Cloud
トラブルシューティング  |  Cloud Storage  |  Google Cloud

DNS設定をするためには、CloudflareのDNSの画面に行くんじゃ。そして、上記オフィシャルの説明通り、CNAMEレコードを追加するんじゃ。

この画面の入力項目について
  • TypeはCNAMEを選択します。
  • Nameはバケットにつけたサブドメインを入力します。(media.norio.ioなら「media」)
  • Targetは「c.storage.googleapis.com.」と入力します。(オフィシャルの説明通り、末尾のドットも含めます)(保存後、末尾のドットは取り除かれますが、念のため)

追加したわ。DNSのレコードもずいぶん増えたわね。

CloudflareとGCSの間はhttpで通信するようにする

先ほど重要な点としてCloudflareとGCSの間はSSL非対応となることを伝えたふが、そのための設定じゃ。

重要だから再掲するわ。

トラブルシューティング  |  Cloud Storage  |  Google Cloud

ブラウザとCloudflareの間はhttpsのまま、CloudflareとGCSの間だけhttpにするには、SSLのモードをFlexibleにするんじゃ。

ただ、メディア以外はセキュリティ的に引き続きStrictにしておきたいから、メディアのサブドメインにだけFlexibleが適用されるようにするぞ。

器用なことするわね。

特定のURLのみSSLモードを変更するには、Page Ruleを追加するんじゃ。まずは、CloudflareのPage Ruleの画面に行き、ルールを追加するじゃ。

また、次の項でついでにキャッシュの設定もするから、キャプチャの通りまだ「Save and Deploy」はクリックしないように。

この画面の入力項目について
  • If the URL matchesには「バケット名/*」と入力します。(キャプチャの例では「media.norio.io」というバケット名(兼サブドメイン名)です)このルールにより、http://media.norio.io/およびhttps://media.norio.io/の全てのURLにがルールの適用範囲となります。なお、URLのパターンについての詳細は下記オフィシャルに記載されています。
  • Then the settings areについては、左の設定項目は「SSL」を選択し、右側の設定値には「Flexible」を選択します。
Please Wait... | Cloudflare

メディアをキャッシュできるようにする

さて、画像などのメディアについては頻繫に更新するようなケースはブログにおいては稀じゃろうから、併せてキャッシュの設定をしてしまおう。

WordPressの管理画面などまでキャッシュされては困るから、メディアだけをキャッシュするようにするため、SSLをFlexibleに設定するためのPage Ruleに相乗りで設定するぞ。

※本来は管理画面以外のWordPressのページもキャッシュさせたい。

この画面の入力項目について
ブラウザキャッシュ
  • 左側の設定項目は「Browser Cache TTL」を選択します。
  • 右側の設定値は「a day」(1日間)を選択します。(例です。鮮度とキャッシュ効率のトレードオフで、お好みで変えてください。)
エッジキャッシュ
  • 左側の設定項目は「Edge Cache TTL」を選択します。
  • 右側の設定値は「7 days」(7日間)を選択します。 (例です。鮮度とキャッシュ効率のトレードオフで、お好みで変えてください。)
キャッシュレベル
  • 左側の設定項目は「Cache Level」を選択します。
  • 右側の設定値は「Ignore Query String」を選択します。
  • 「Cache Everything」を選択すると、クエリストリング(パラメータ)が異なるものは全て別物としてキャッシュしようとする(GCSにアクセスが生じる)ため、キャッシュ効率が下がります。また、WordPressと連動したGCS上のメディアにアクセスする際はパラメータは付与しないと思うので、クエリストリングが異なっても同じメディアとしてキャッシュさせるようにします。

Cache Levelについてのオフィシャルな詳細じゃ。

Please Wait... | Cloudflare

追加するとPage Ruleは下記のようになるはずじゃ。万が一、追加したメディアに関するPage Ruleが一番上にないようなら、一番上に移動するんじゃ。

あら、どうして?

キャプチャ内の説明にも書かれているが、上にあるルールほど優先度が高く適用され、かつ、最初にURLがマッチしたルールひとつしか適用されないんじゃ。

無料で設定できるPage Ruleは3つまでだから、どう設定するかは悩ましい面もあるが、下記にオフィシャルの必須や推奨設定の説明をリンクしておく。

また、気付いたかもしれないが、Page Ruleを3つというと直感に反するかもしれないが、マッチさせるURLのパターンを1と数えるんじゃ。つまり、URLのパターンを3つまで登録でき、ひとつのURLパターンにつき、先ほどのキャッシュの例のように複数の設定をすることができる。

パズルみたいで面白いわね。工夫すれば少ないURLパターンできめ細かな制御ができそうね。

Please Wait... | Cloudflare

WordPress側の作業

GCSと連動するためWordPressにプラグインをインストール・セットアップする

さて、ここからはWordPress側の説明じゃ。

まずは、WordPressとGCSを連動させるためのプラグイン「WP-Stateless」をインストールするするんじゃ。

プラグインの新規追加の画面で「wp-stateless」と検索したら見つかるわね。

インストールしたらさっそく有効化ね。

プラグインを有効化したら、「Stateless Setup」というメニューからセットアップを開始するんじゃ。

有効化したら自動的に下記のようにセットアップの開始画面が表示されるかもしれないわね。

「Google Login」をクリックして、

GCSのバケットを作ったの際のGoogleアカウントを選択するんじゃ。

プラグインがGCSにあれこれできるようにアクセスを許可するのね。

次の画面が表示されたら、先の手順でバケットを作成したGCPのプロジェクトと、バケットを選択するんじゃ。

選択しないと、デフォルトで新しいプロジェクトを作成して、しかもRegionalより高いMulti-Regionalで新しいバケットを作成されてしまう模様じゃ。

無事セットアップできたわ。

あとは、プラグインの設定をすればGCSとの連動は完了じゃ。

ちなみに、先のセットアップが完了すると、下記のようにGCPにプラグイン用のサービスアカウントなどが作成されたことが分かるぞ。

WP-Statelessプラグインを設定する

さて、最後にWP-Statelessプラグインの設定じゃ。ボリュームがあるから、必要最低限の説明をする。詳細はググったりしてみるとよいじゃろう。

この画面の入力項目について
  • ModeはCompute Engine側の容量(メディア以外もこみこみで30GB)に収まるようなら、WordPress側にもファイルを残すCDNモードがオススメです。 (WordPress側に存在しないと、移行時やバックアップにおいて問題が生じるかもしれないため) なお、ファイルは両方に存在しますが、メディアへのアクセスはGCSの方に来て、WordPressの方には来ません。
  • Modeについて、先述の通り移行時などの懸念はありますが、Statelessを選択することで、GCSのみにメディアファイルを保存します。そのため、Compute Engine側のディスク容量の制約を受けなくなります。
  • Backetの欄はセットアップで選択したバケット名が自動的に設定されていると思います。
  • Backet Folderの欄は空白のままでも構いませんが、フォルダ名を指定することでWordPressから連携されたファイルが全てそのフォルダ配下に保存されるようになります。GCSのバケットをWordPressとの連動以外にも使用する場合は、分かりやすいように指定しておくことを推奨します。
  • Delete GCS Fileは必ずEnableにしておきます。Enableにしておくことで、WordPressのメディアから削除したファイルは、GCSからも自動的に削除されるようになります。WordPressのメディアにアップロードしたファイルをバケット内で手動で取捨選択して削除することは現実的ではありませんし、誤ったファイルを削除してしまうなどの事故も考えられます。また、削除しないと増える一方で、Always Freeの範囲を超えてしまったりと課金にも絡んできます。
  • Previewの欄でメディアのURLのイメージ(例)を確認しておきましょう。
  • Domainは「https://バケット名」としておきます。これで、メディアについて、ブラウザとCloudflareの間はhttpsで通信するようになります。
  • Cache-BustingはEnableにしておきます。これにより、メディアのアップロード時、ファイル名の先頭にランダムな文字列が付与されるようになり、同名のファイルをアップロードしても、実際にはランダム文字列が付与された名前で保存され、アップロード後は即時反映されるようになります。逆にEnableにしない場合、同名のファイルをアップロードした場合、キャッシュがリフレッシュされるまで古いメディアが表示され、混乱を招いたりするでしょう。

次回はWordPressのバックアップの仕組みを導入するぞ。

コメント

タイトルとURLをコピーしました