自己啓発の発表用として建てたこのWordpressが、もうすぐ1年経つそうです。
しかし当初は自宅サーバで動かしていたものが、安定性を求めVPSに移行してしまい
その分の料金が毎月かかってしまうという負担になっていました。
なので今あるコンテンツを全て静的ファイルに変換して
S3上でホスティングできる様にいじってしまおうというのが今回の目的です。
1.概要
・EC2上にWordpressを構築。記事の更新は基本こちらで行う
・WordPressは記事を更新するだけなので、サーバスペックは最低限でOK
・「StaticPress」というプラグインを使うと、Wordpressを静的コンテンツに変換してくれます
更に「StaticPress S3」を使うと、変換した静的コンテンツをS3上にアップロードしてくれます
・S3はホスティング機能を有効にして、Route53でドメインをS3に向ければWEBに公開できちゃう
てな具合でかんたーんなんです。
いいところ
・サーバーのメンテナンスが不要。脆弱性の心配とかいらない
・抜群の安定性と堅牢性を誇るS3。Yahoo砲が来ても落ちない
・料金が激安
・容量無制限
わるいところ
・配信できるのは静的HTMLコンテンツのみ。PHPやCGIが使えない
⇒コメントやサイト内検索は使用不可(外部プラグインで使用可)
・更新毎に同期をかける必要があるので、頻繁な更新には向かない
とまぁメリットもあればデメリットもありというところなので
全員が使える方法ではないということをご了承願いたい。
前提条件
・EC2上に立てるWordpressサーバは、マーケットプレイスにあるbitnamiをベースに作成します。
インスタンス立ち上げた段階でWordpress使えるので、かなり楽ちん。
・既に稼働しているWordpressのデータは、All-in-One WP Migrationを使って移行させます。
管理画面からインポート/エクスポートができるので、かなり楽ちん。(2回目)
・WordPressサーバにSSHでアクセスできること
・独自ドメインは「hdserver.info」を使用します
プラグインをインストールする
StaticPress プラグイン
- WordPressダッシュボードを開く
- [プラグイン] -> [新規追加]
- 「staticpress」で検索し、[今すぐインストール]をクリックする
StaticPress S3プラグイン
WordPressダッシュボードからはインストールが行えないので、githubからダウンロードします。
- githubへアクセス
- [Clone or download] -> [Download ZIP]
- [プラグイン] -> [新規追加] -> [プラグインのアップロード]
- [ファイルを選択]より先程ダウンロードしたZIPファイルをアップロードします。
Disable Responsive Imagesプラグイン
StaticPressプラグインは、画像リンクの生成において
Responsive Imageへの対応が充分ではないためsrcsetタグを無効にするプラグインを使用します。
- [プラグイン] -> [新規追加]
- 「Disable Responsive Images」で検索し、[今すぐインストール]をクリックする
プラグインの有効化/停止
[プラグイン]をクリックし、以下のプラグインを有効化する
- Disable Responsive Images
- StaticPress
- StaticPress S3
- All-in-One WP Migration
コード修正
WordPressサーバにSSHでログイン
class-S3_helper.phpの修正
$magic_file
のパスをbitnami環境に合わせて修正します。
cd /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/staticpress-s3-master/includes/ cp -ip class-S3_helper.php{,.org} vi class-S3_helper.php
//class-S3_helper.php の 188行目辺り
$magic_file = '/usr/share/misc/magic';
↓
$magic_file = '/opt/bitnami/apache2/conf/magic';
デフォルトで設定されている$magic_file
だと、プラグインを動かしたときにエラーになってしまったので
apacheで使用されているmagicファイルを指定しました。
ちなみにmagicファイルはサーバ内でfindやらlocateやらでゴリ押しで探しました・・・w
class-static_press.phpの修正
画像つきの投稿を新規作成するとうまく動かない事象への対処です。
# cd /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/staticpress/includes/ # cp -ip class-static_press.php{,.org} # vi class-static_press.php
/*730行目あたり if (is_wp_error($permalink)) continue; の後に追記する*/ if (preg_match('/.*\.html\/.*/', $permalink, $m)) { continue; }
パーマリンクの設定
- [設定] -> [パーマリンク設定]
- カスタム構造を選択し、
/%postname%.html
を入力する - [変更を保存]をクリックする
S3上では静的ファイルとして読み込ませる為に、拡張子に.htmlをつける必要があります。
この設定では「http://[Wordpressサイト名]/記事名.html」として表示される様になります。
S3でバケットを作成
AWS管理画面へログインし、S3を選択
バケットを作成
バケット名の箇所に、wordpressで公開しているドメインを指定し、作成をクリックします。
新しいバケットが作成されたことを確認します。
バケットを選択後、「プロパティ」タブをクリックして
“Static website hosting”をクリックします。
以下の通りにドキュメントを設定して保存します。
なお、「エンドポイント」がS3バケットで公開されるURLになりますので控えておきます。
StaticPress S3の設定
- StaticPress設定を開く
- 静的サイトURLにS3バケットのEndpointを入力する
- 出力先ディレクトリの最後尾に
static/
を追加する - [設定を保存]をクリックする
S3バケットのIAM Access Keyを入力し、リージョンを選択する
※ 東京リージョンはAP_NORTHEAST_1
- [変更を保存]をクリックする
S3 Bucketが選択できるようになっているので、同期先のバケットを選択する
[変更を保存]をクリックする
コンテンツを同期する
[StaticPress] -> [再構築]
[終了]と表示されたら同期完了
■「エラー!」と表示された場合のトラブルシューティング
・class-S3_helper.phpの修正部分を見直す
・StaticPress S3の設定を見直す
・S3バケットのIAM Access Keyを作りなおす
・サーバのstaticディレクトリを削除する(次項参照)
- S3バケットのWeb公開URLにアクセスしてブログサイトが表示されることを確認する
http://hdserver.info.s3-website-ap-northeast-1.amazonaws.com/
コンテンツを更新する
記事の投稿など、コンテンツを更新した際は都度「再構築」を実行する必要があります。
ただし、テーマの変更など大きくコンテンツが変更された場合など、同期がうまくいかず「エラー!」と表示されることがあります。
その時は、下記コマンドでサーバのstaticディレクトリを削除してから「再構築」を実行してみましょう。
$ sudo rm -rf /opt/bitnami/apps/wordpress/htdocs/static/
Route53での設定
1.Route53にて、「CreateHostedZone」でドメイン名を入力してゾーンを作成。
2.私はレジストラはムームードメインを使っています。
ムームードメインにて、ネームサーバを弊社サービス以外 のネームサーバに変更しましょう。
3.ネームサーバ1〜4に先ほどのDelegation Setを入力して保存。(下記「Name Servers」の箇所)
4.Route53に戻って、「Go To Record Set」
5.「Create Record Set」
– Typeを「A – IPv4 Address」を選択
– AliasをYesにする
– AliasTargetの欄にフォーカスを当てると、S3のEndpointが出てくるので選択
– Createする
↓こんな感じ
これで、しばらくすると独自ドメインでサイトが見れるようになります。
すぐには反映されないが、自分の場合1時間くらいで反映されてました。(もっと早いかも)
WordPressサーバを停止する
更新用のWordpressサーバはEC2ですので、必要ない時は停止しておきます。
ただし、EBSインスタンスだと停止時も課金されてしまうので、更新毎にAMI取得してterminateしてます。
ここらは手間ですが、Jenkinsとか使えば自動化できるかも…?
あとがき
実際は不具合のある箇所がちょこちょこあって完全ではないのですが
月額料金がグッと下げられ且つ高速・超安定とメリットがいっぱいです。
ちなみにCroudFrontをかませてSSL化・レスポンス高速化を図っておりますので
そのあたりも次回移行ぼちぼちご紹介できたらなぁと思います。
参考サイト
https://qiita.com/tomsig/items/f106fe94ab7e20490938
https://qiita.com/Ichiro_Tsuji/items/c6a52ec0ee95ead42f68