【第6回】GCPの無料枠でdev.toなみの爆速WordPress環境を構築する（WordPress設定編）

1 はじめに
- 1.1 WordPressインストール
2 「KUSANAGI Runs on Docker」での不具合を回避
3 まとめ

はじめに

前回【第5回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する（KUSANAGI Runs on Docker編）では「KUSANAGI Runs on Docker」を動かし、WordpressのWelcome画面が無事に表示されるところまで進んだ。今回【第6回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する（Wordpress設定編）では、Wordpressのインストールから「KUSANAGI Runs on Docker」での特有な設定などについて紹介していく。

WordPressインストール

前回の【第5回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する（KUSANAGI Runs on Docker編）で、上記のWelcome画面が表示されるところまで進んだので、次はWordpressのインストールをしていこう。

とりあえず「さあ、始めましょう！」ボタンをクリックし、インストール画面へ。

上記のような設定画面が表示されるので前回の投稿で設定した「データベースサーバー」の情報を入力していこう。

注意点としては「データベースのホスト名」は「mysql」とすること。また、マルチサイト運用をする場合は必ず「テーブル接頭辞」をそれぞれ異なるものを入力すること。「テーブル接頭辞」を同一にしていますと同じデータベースを読みにいくことになってしまう。

そして入力後、送信ボタンをクリックすれば上記のように「インストール実行」のページが表示される。

「インストール実行」をクリックしよう。

そうするとお馴染みのWordpressのインストール画面が表示される。以降は通常のWordpressのインストール作業を進めていけば良い。

「KUSANAGI Runs on Docker」での不具合を回避

「KUSANAGI Runs on Docker」では、通常のWordpressの環境とは異なり運用するにあたって多々問題がある。特殊な設定が必要となってくるので、それらの問題を解決する方法を紹介していく。

Let’s Encrypt（SSL）

通常の「KUSANAGI Runs on Docker」ではLet’s Encrypt（SSL）に未対応だが、今回紹介している構築方法では対応済み。（ただし、Let’s Encryptの定期更新に対応しているかは未確認。ただ、確証はないが「Cloudflare」の「Crypto」にある「SSL」の設定を「Full」にしておけば、オレオレ証明書でも運用できるのでLet’s Encrypt（SSL）の更新がされていなくても動作するんじゃないかなと。）

プラグイン・テーマを新規登録の不具合を回避

初期状態だと下記のようなダイアログが表示されプラグインやテーマが新規登録できない。

下記のコマンドでwp-config.phpの最終行に「define(‘FS_METHOD’,’direct’);」を追加する。これでプラグイン・テーマを新規登録の不具合を回避することができる。

sudo sed -i '$ a define('FS_METHOD','direct');' /home/wordpress/kusanagi-1/data/{ドメイン名}/DocumentRoot/wp-config.php

上記のコマンドのwp-config.phpのパス部分は、あくまでも今回インストールした「kusanagi-1」のコンテナに対しての修正方法なので、マルチサイトや他の名前でコンテナを起動させている場合はパス部分を変更すること。もちろん{ドメイン名}部分も。

テーマを新規登録の不具合を回避

上記の問題を解決してもテーマは階層の権限が原因で以前としてインストールできない状態なので下記のコマンドで権限を変更し不具合を回避する。

sudo chmod 707 /home/wordpress/kusanagi-1/data/{ドメイン名}/DocumentRoot/wp-content/themes/

こちらもパス部分は実行環境に合わせて変更すること。

アップロードファイルの容量制限を回避

「KUSANAGI Runs on Docker」をインストールした場合、本来であればアップロードファイルに対して１MBの容量制限がかかっているが、無料でdev.toなみの爆速Wordpress環境を構築（KUSANAGI Runs on Docker編）の記事中にある環境構築用のファイルを使用した場合は、こちらの問題は対策済み。

下記のファイルで環境変数を変更し回避している。

uploads.ini

memory_limit = 256M
upload_max_filesize =20M
post_max_size = 20M

nginx.conf

client_max_body_size 20m;

WordPressの本体更新などでの権限問題を回避

まだ遭遇していないがWordpress本体やプラグインの更新時にパーミッション起因によるエラーが発生する。今回の環境でWordpressのデータは

cd /home/wordpress/kusanagi-1/data/{ドメイン名}/DocumentRoot/

に格納されているので、「cd」コマンドでこの階層に移動し、下記のコマンドを実行すればパーミッション起因によるエラーを回避できる。

sudo chmod 707 wp-settings.php
sudo chmod 707 wp-cron.php
sudo chmod 707 wp-activate.php
sudo chmod 707 wp-load.php
sudo chmod 707 wp-login.php
sudo chmod 707 wp-signup.php
sudo chmod 707 wp-trackback.php
sudo chmod 707 wp-config-sample.php
sudo chmod 707 license.txt
sudo chmod 707 readme.html
sudo chmod 707 wp-includes/version.php
sudo chmod 707 wp-admin/includes/update-core.php
sudo chmod -R 707 wp-includes/
sudo chmod -R 707 wp-admin/
sudo chmod 707 wp-comments-post.php

※追記（2018年6月5日)
Wordpress 4.9.6へのバージョンアップ時に他のファイルのパーミッションも変更しなければならなかったので下記のコマンドを追記しました。
sudo chmod -R 707 wp-includes/
sudo chmod -R 707 wp-admin/
sudo chmod 707 wp-comments-post.php

運用後にもそのほかのパーミッションのエラーが発生する可能性もあるので上記の手法で回避していこう。

まとめ

これでひとまず実用に耐えうるWordpressの環境が整った。次回【第7回】GCPの無料枠でdev.toなみの爆速Wordpress環境を構築する（爆速設定編）ではWordpressのプラグインとCloudflareの設定でdev.toなみの爆速を実現していこう。