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以外でドメインを取得した場合、バケットにドメイン名をつけるには下記ページを参照するといいじゃろう。
次はロケーションじゃ。ロケーションタイプはAlways Freeの対象である「Region」を選択するんじゃ。それ以外はAlways Freeではないから課金されてしまうぞ。
ロケーションについてもAlways Freeはus-east1、us-west1、us-central1だけだから、WordPress（Compute Engine）同様、us-west1にしておこう。それ以外のロケーションは課金されるぞ。
念のためAlways Freeの最新条件は下記オフィシャルで確認しておくとよいじゃろう。Cloud Storageの項じゃ。
ストレージクラスは「Standard」じゃ。他の2つはキャプチャの説明の通り、Webに掲載するための用途には向いておらん。
この辺りはよく分からなければデフォルトでいいじゃろう。
ここもデフォルトじゃな。
バケットができたわね。
Cloudflareの設定変更
GCSに独自ドメインのURLでアクセスするためのDNSを設定する
GCSのバケットにドメイン名を付けただけではそのドメインのURLでGCSのメディアにアクセスすることはできない。
独自ドメインのURLでアクセスするにはDNSの設定が必要なんじゃ。
オフィシャルな説明としては下記じゃな。
オフィシャルついでにひとつだけ重要な注意点があるんじゃが、今回説明する方法ではCloudflareとGCSの間の通信はSSL非対応で、httpでアクセスされるんじゃ。そのため、公開されては困るようなものはメディアにアップロードしないことが前提となるんじゃ。一般公開するブログ用のメディアであれば問題ないじゃろう。一般公開できないような機密性のあるメディアをアップロードするようなケースにおいては、オフィシャルでも触れられているようにGCPにロードバランサを用意するなどの必要があるようじゃ。
DNS設定をするためには、CloudflareのDNSの画面に行くんじゃ。そして、上記オフィシャルの説明通り、CNAMEレコードを追加するんじゃ。
追加したわ。DNSのレコードもずいぶん増えたわね。
CloudflareとGCSの間はhttpで通信するようにする
先ほど重要な点としてCloudflareとGCSの間はSSL非対応となることを伝えたふが、そのための設定じゃ。
重要だから再掲するわ。
ブラウザとCloudflareの間はhttpsのまま、CloudflareとGCSの間だけhttpにするには、SSLのモードをFlexibleにするんじゃ。
ただ、メディア以外はセキュリティ的に引き続きStrictにしておきたいから、メディアのサブドメインにだけFlexibleが適用されるようにするぞ。
器用なことするわね。
特定のURLのみSSLモードを変更するには、Page Ruleを追加するんじゃ。まずは、CloudflareのPage Ruleの画面に行き、ルールを追加するじゃ。
また、次の項でついでにキャッシュの設定もするから、キャプチャの通りまだ「Save and Deploy」はクリックしないように。
メディアをキャッシュできるようにする
さて、画像などのメディアについては頻繫に更新するようなケースはブログにおいては稀じゃろうから、併せてキャッシュの設定をしてしまおう。
WordPressの管理画面などまでキャッシュされては困るから、メディアだけをキャッシュするようにするため、SSLをFlexibleに設定するためのPage Ruleに相乗りで設定するぞ。
※本来は管理画面以外のWordPressのページもキャッシュさせたい。
Cache Levelについてのオフィシャルな詳細じゃ。
追加するとPage Ruleは下記のようになるはずじゃ。万が一、追加したメディアに関するPage Ruleが一番上にないようなら、一番上に移動するんじゃ。
あら、どうして？
キャプチャ内の説明にも書かれているが、上にあるルールほど優先度が高く適用され、かつ、最初にURLがマッチしたルールひとつしか適用されないんじゃ。
無料で設定できるPage Ruleは3つまでだから、どう設定するかは悩ましい面もあるが、下記にオフィシャルの必須や推奨設定の説明をリンクしておく。
また、気付いたかもしれないが、Page Ruleを3つというと直感に反するかもしれないが、マッチさせるURLのパターンを1と数えるんじゃ。つまり、URLのパターンを3つまで登録でき、ひとつのURLパターンにつき、先ほどのキャッシュの例のように複数の設定をすることができる。
パズルみたいで面白いわね。工夫すれば少ないURLパターンできめ細かな制御ができそうね。
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プラグインの設定じゃ。ボリュームがあるから、必要最低限の説明をする。詳細はググったりしてみるとよいじゃろう。
次回はWordPressのバックアップの仕組みを導入するぞ。
コメント