わざわざEC2でWordPress動かさなくても……
WordPress(以下WP)のマルチサイト機能は、大昔に試してみたけど、あまり使い勝手が良いと感じず、その後一度も試みたことがありませんでした。
それから時間が経ち、AWSのEC2の国産のWP特化AMI「AMIMOTO(網元)」を知り、さらにマルチサイト機能も使いやすそうに紹介されていたので、これならと思い、ためしにセルフホスティングで設定してみました。
WPのマルチサイト機能もだけど、EC2上でのWP運用に対しても僕は懐疑的で、よほど大規模サイト群で無い限り、わざわざWP動かすためにEC2+AMIマーケットプレイスで立ち上げて運用するなんて、大袈裟過ぎないかと思っていました。
だって、WP動かすだけなら、定番のさくらのレンタルサーバ
なり、エックスサーバー
なり使えば簡単かつ、十分な信頼性もあって良いじゃないと。
逆に大規模サイト群となると、WPじゃなく、CMSからスクラッチしてしまった方が良い事も多そうですしね。
そんな訳で、普通のWPサイト運営は、最低限SSH接続できるレンタルサーバくらいで必要十分な考えを持ってました。
細かくセットアップされたWPは、取り回しがらくちんだった
しかし、今回EC2でAMIMOTOを設定して触ってみると、がっつりとWP向けに整えられている環境が楽ちんに用意しできる事は、想像以上に楽だとわかりました。
そしてEC2ならではの拡張性の高さは、単純なブログサイト以上の運営をWPでしたいなら、選択肢に十分になりそうです。確かにこれはすごい。
サーバーの内部に疎い僕でも、マルチサイト機能を使った複雑なサイト運営をするなら、これがベターな選択肢に見えてきました。
たとえば、安価なランニングコストで凝ったことをWPでやりたいからと言って、知識と技術に乏しい状態で、VPSとかでAMIMOTO並に整える手間と学習コストを考えたら、この方が大分安上がりでしょう。
そんなわけで、以下は僕が設定した時のメモを元にした解説です。
取り掛かる前の僕の考えや知識に近い人には参考になるはずです。
作業前の準備、決めておくこと
サブドメイン or サブディレクトリ形式の変更はできない
WPのマルチサイトはサブドメイン or サブディレクトリの構造を一度決めると、あとで変更することができません。
運用方法をあらかじめ決めておく必要があります。
今回僕はサブドメイン形式のマルチサイトで行いましたが、あとあと工夫すれば、閲覧ユーザ側からはどちらの形式でも見えるように運用できるはずなので、そんなに重く考える必要はないかもしれません。
ドメインの用意
WPを運用するメインドメインとDNSのサブドメインに対応する設定が必要になります。
今回は仮に「s0014dummy.com」のドメインを用意しているとして話を進めます。
追加サイトのサブドメインは後で変更が効くけど、メインのドメインの変更は面倒なので、最初に決めておきましょう。
- WPメインサイト
- s0014dummy.com
- 追加サイトA
- aaa.s0014dummy.com
- 追加サイトB
- bbb.s0014dummy.com
ドメイン自体は「お名前.com 」で取得したもので、そのネームサーバを同じAWSのRoute53に向けてしまい、各レコードはそっちで設定してしまってます。
最近はRoute53で直接ドメイン取得できるから、新しくドメイン取るなら、もうそっちで統一しちゃった方が楽かもしれませんね。(僕はまだやった事ない)
AWSやEC2の基本操作
細かい操作の解説まで入れると、記事が長くなりすぎるので、はじめてAWS触りながらここまで読んでくれているかたがいるなら、まずはドットインストールのAmazon Web Services入門を見ながら、ざっくりと触っておくことをおすすめします。
ドットインストールはこの先の操作で使うvimの操作も紹介してあったりと、ほんと素晴らしすぎですね。
そんなわけで、インスタンスの立ち上げ回りの細かい操作はすっ飛ばします。
ElasticIPのひも付けは忘れないようにしましょう。
忘れてると面倒な事になるようです。
[参考]【AWS】網元で構築したWordPressをDNS切り替えしたらアクセスできなくなってしまった時の対処法 | かわたま.net
AMIMOTOインスタンスの立ち上げ
種類が色々あってややこしい
EC2のダッシュボードからAMI Marketplaceを選択し、「amimoto」で検索して出てきたAMIを選択します。 ただ、同じAMIMOTOでもPVM, HVM, HHVM, RHELと色々出てきてややこしいです。
え? これくらい常識?
うーん、AWSはクラウドでもう困らない!WordPress 快適運用術のページを用意して、いかにも簡単にEC2でWPが動くっぽく紹介してあるけど、このページの内容だけでは、仮想化方式とかに疎い僕にはわけわかめでした。
超適当だけど、こんな違いがあるようです。
- PVM
- 古い仮想化方式。これから作るサイトで利用する利点は少なそう。
- HVM
- PVMから進化した仮想化方式。現在の主流?
- HHVM
- HVMが更に進化したもの。公式記事でも紹介されているように、一番早くて安定している。ただしPHP5.6からしか動かないので、テーマやプラグインの選定、カスタムに注意。
- AMIMOTO_RHEL
- ほかのインスタンスは全てAmazon Linux上で動くけど、これだけRed Hat Enterprise Linux上で動く。RHELの機能に依存した構築をしたいなら選ぶ感じ?
ちなみに、この検索をすると「WooCommerce」という、WPをECサイト化するテーマとプラグインが予め設定された物も同時に出てきます。とりあえず今回はスルーです。
WordPress powered by AMIMOTO (HHVM)を選んだ
新しもの好きの僕は、HHVMで立ち上げる事にしました。
インスタンスが立ち上がったら、あとでインスタンスIDを参照できるように、ブラウザのタブを開きっぱなしにしておきます。
インスタンスを立ち上げたらElastic IPで「s0014dummy.com」ドメインとの紐付けしておきます。
立ち上げて設定できたら、こんな感じでSSHログインします。
$ ssh -i ~/.ssh/MY_KEY.pem [email protected]
ちなみに、DNSの設定が完了しておくとこんな感じでもログインできます。わかりやすいですね。
$ ssh -i ~/.ssh/MY_KEY.pem [email protected]
マルチサイトの下ごしらえ
EC2にsshログインして設定ファイルを書き換えます。
Nginxの設定を変更
default.backend.confを書き換えます。
$ sudo vim /etc/nginx/conf.d/default.backend.conf
この記述のある2行のコメントアウト部分を……。
include /etc/nginx/wp-singlesite;
#include /etc/nginx/wp-multisite-subdir;
こんな感じで入れ替えます。
#include /etc/nginx/wp-singlesite;
include /etc/nginx/wp-multisite-subdir;
保存したらNginxを再起動します。
$ sudo nginx -s reload
とりあえずWPにログイン
WPにログインする前にさっきから開きっぱなしにしていたブラウザからEC2のインスタンスIDをチェックしてクリップボードにコピーしておきます。
そのままs0014dummy.comを開きます。
一般のレンタルサーバーとかにインストールしたWPでは見慣れない画面が出てきます。
ここでコピーしておいたインスタンスIDを貼り付けて、次のステップに移ります。
おなじみのWP設定画面ですね。
WordPressの基本情報を入力します。 レンタルサーバーよくあるWPの簡単インストール機能的な物でWPを設定すると、最初から「admin」とかのユーザー名が作られるけど、ここではそのユーザー名から設定します。
ここで入れる「ユーザー名」は後々変更できない管理アカウントなので注意です。普段簡単インストール機能ばかり使ってると、この辺うっかり忘れてしまいます。 とりあえず、こんなユーザー名はやめておきましょうか。
- 「Oishi」とか、個人の名前は、事業用サイトの初期アカウントでは避ける。
- もちろん定番の管理者ID「admin」は乗っ取り難易度が下がるので避ける。
僕は忘れてたので、ここで間違ってインスタンスの作成からやり直しました。慣れないマシン上でDB触って修正する度胸はありません(笑)
WPのマルチサイトネットワークの設置
wp-config.phpを変更
再びSSH接続しての作業、wp-config.phpを編集します。
$ sudo vim /var/www/vhosts/インスタンスID/wp-config.php
ぱっと開いただけでも、普通のレンタルサーバにインストールしたWPのwp-config.phpとは随分中身が違うのが分かります。
AWS向けのDB設定や、セキュリティの強化やバックアップ、デバッグ回りの整備がされているようです。
その中の、マルチサイトに関する記述がされている、この行のコメントアウトを外します。
// define ('WP_ALLOW_MULTISITE', true);
こんな感じ。
直ぐにもう一回編集するから開きっぱなしにしておいても良いけど、接続が切れたら面倒なので「:wq」で閉じちゃった方が良いと思います。
define ('WP_ALLOW_MULTISITE', true);
WPのダッシュボードを開きます。 マルチサイトを有効にするために、まずはプラグインを全て停止します。 多分「インストール済みプラグイン」を開くと「Nginx Cache Controller」が有効になっていたのて、これを停止します。
そして「ツール」の中に、普段見慣れない「ネットワークの設置」が追加されています。
こんな感じの画面が表示されます。 上で書いたように、今回はサブドメイン型のマルチサイトで運用します。
wp-config.phpと.htaccessを設定するように書かれてるけど、AMIMOTOの場合、wp-config.phpの修正だけでOKです。
そもそもNginxの場合、Apacheの設定ファイル「.htaccess」ではなく、「/etc/nginx/conf.d/」にある設定ファイルを触る事になります。 たとえば、リダイレクトの設定をしたければ「/etc/nginx/conf.d/default.conf」を開き、「server」の中にこんな感じで書けばOKでした。
server {
# s0014dummy.com/index1.html を s0014dummy.com/index2.html にリダイレクト
rewrite ^/index1.html$ index2.html redirect;
}
ここで、さっき開きっぱなしにしていたWP設定ファイルの画面に移動します。
この辺の行を……
// define('MULTISITE', true);
// define('SUBDOMAIN_INSTALL', false);
// define('DOMAIN_CURRENT_SITE', 'example.com');
// define('PATH_CURRENT_SITE', '/');
// define('SITE_ID_CURRENT_SITE', 1);
// define('BLOG_ID_CURRENT_SITE', 1);
こんな感じに変えます。
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // false → trueに変更
define('DOMAIN_CURRENT_SITE', 's0014dummy.com'); // 自分のドメインに変える
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
もちろん、画面で指示されているように、元のコメントアウトされた行を放っておいて、当該行の下部に追記する形でもOKです。
「/* 編集が必要なのはここまです! WordPressでブログをお楽しみください。*/」の記述は無いので注意です。
単なるコメントアウト解除じゃなく‘SUBDOMAIN_INSTALL’ をfalseからtrueに変える事に注意します。
変更したら保存します。
これでWPのダッシュボードをもう一度開くと、 左のメニューから投稿関係の項目が無くなり、かわりに「サイト」が追加されてます。
あとはサイトを追加するだけ
DNSサービスでサブドメイン設定
さっきの「ネットワークの設定」の画面の中で「*.s0014dummy.com」の設定をしろと言われていたけど、今回、僕の場合は別のサブドメイン、「zzz.s0014dummy.com」 でWPではないサイトを運営していたので、個別に「aaa.s0014dummy.com」と「bbb.s0014dummy.com」のサブドメイン設定しました。
僕は同じAWSのRoute53でこんな感じに設定しました。 いずれも、メインの「s0014dummy.com」のAレコードに設定したElastic IPと全く同じ物を向けるだけです。
もちろん、そのドメインをWP以外のサイトに使う予定が無いのなら、面倒な事をせず「*.s0014dummy.com」のレコードを設定するだけでOKです。
追加したサブドメインをWPで追加
この辺は素直に画面の指示通り、設定していたサブドメインを入力すればOKです。
追加した後はこんな感じ。ここまで来れば、あとは適宜プラグインを有効して、その後はものすごく楽ちんにサイトを量産できます。
低品質アフィリサイトの量産が捗りますね。いや、ほんとやめて欲しい。
画像ではメインのドメインが「s0014dummy.com」に対して追加したサイトは「aaa.s0014dummy.com」ではなく、「aaa」とだけ入っているので、少し不安になるけど、問題なく「aaa.s0014dummy.com」として動作しました。
当然ながら、サブドメインのレコードを設定してしばらくはサイトが表示されにくいです。