WordPressは手軽にWebサイトが構築できるパワフルなツールですが、昨今その脆弱性を狙った攻撃が多様化しており、保守に関わるコストも増大しています。
そこで本サイトでは、ローカルの仮想環境に構築したWordPressからHTMLファイルを生成し、完全な静的サイトとして安全に公開・運用するフローを導入しました。
仮想環境や、WordPressの静的化というと難しく聞こえるかもしれませんが、便利なツールやプラグインを使えば、比較的簡単に実現することができるので、今回はその方法を紹介します。
目次
注意：このページの解説はMac OS X 10.9.5環境での作業を前提に動作の検証を行っています。
WordPressのセキュリティ対策について
近年、WordPressに対するアタックが増加しており、度々ニュースにもなっていますが、皆さんWordPressのセキュリティ対策はどうされていますか？例えば、よく紹介されているWordPressのセキュリティ対策として、以下のようなものがあるかと思います。
- adminユーザーを削除する
- 難しいパスワードを設定する
- 管理画面にBASIC認証をかける
これらの対策はブルートフォースアタック（総当り攻撃）等に対しては有効かもしれませんが、WordPressに対する攻撃はそういった正面玄関からやって来るものだけとは限りません。
場合によっては、テーマ関連ファイル（サムネイルを生成するTimThumb.phpなど）の脆弱性や、プラグインの脆弱性を突かれて、知らないうちにフィッシングサイトを生成されてしまうこともあります。
世の中には便利なテーマやプラグインがたくさんありますが、それら一つ一つの脆弱性を随時チェックしていくのは大変な作業だと思います。また、それらのリスクを踏まえてWordPressを安全に保守・メンテナンスするには、相応のプログラムやサーバに関する知識が必要不可欠だと言えるでしょう。
私を含め、個人で片手間でサイト運営しているような人にとって、かなりハードルが高いと思うのですが、極論を言えば、WordPressのPHPファイルをサーバに設置している以上、そういったリスクと無縁ではいられないのではないでしょうか？
ローカルの仮想環境の構築
そこで公開サーバとは切り離したローカルのマシン上に、WordPressの作業環境を構築することにしました。
ローカルでWordPressのテスト環境を構築する方法としては、XAMPPやMAMPPのようなツールを使う方法や、Mac OS XであればローカルのApacheに直接インストールする方法などもあるかと思います。
今回は、より簡単にWordPress環境を導入する方法として、VagrantとVCCWを使った方法を採用しました。Vagrantは、コマンド一発で仮想環境が構築できるツール。VCCWは、WordPressのプラグインやテーマ開発に最適化されたVagrantの設定ファイルです。
VCCWを使えば、最初からWordPressがインストールされた状態でローカル環境が用意できるだけでなく、プラグインやテーマの開発に便利なツールも一緒に付いてくるので、効率的にWordPressを使ったサイトを制作を始めることができます。
VCCWのインストール
VCCWを利用するには、Virtual BoxとVagrantをインストールする必要があるので、まずはそれぞれの公式サイトからパッケージを落としてインストールしましょう。
次にプロジェクト用のディレクトリを作成し、そこにVCCWのGitリポジトリをcloneする方法でインストールしました。今回、作業ディレクトリは以下のパスとしています。
~/prj/littlebird/ターミナルで作業ディレクトリに移動して、以下のコマンドを実行してください。
$ git clone git@github.com:miya0001/vccw.gitすると、~/prj/littlebird/vccw/というサブディレクトリが作成され、VCCWのインストールが完了します。
設定ファイルの編集
~/prj/littlebird/vccw/へ移動すると、中に色々なファイルが入っているのですが、まずは仮想環境を立ち上げるための設定ファイルを編集します。
Vagrantfile.sampleというファイルをコピー＆リネームし、Vagrantfileという名前でファイルを新規作成。そして、必要な箇所を編集していきます。今回は、主に以下の記述だけ変更を行いました。
WP_LANG = ENV["wp_lang"] || "ja" # WordPress locale (e.g. ja)
WP_HOSTNAME = "littlebird.local" # e.g example.com
WP_IP = "192.168.33.10" # host ip address
WP_HOME = "" # path to WP_HOME, e.g blank or /wp or ...
WP_SITEURL = "" # path to WP_SITEURL, e.g blank or /wp or ...
WP_TITLE = "littlebird" # title
WP_DB_PREFIX = 'lb_' # Database prefixサイトタイトルなどは、後で管理画面から変更することもできます。ローカルでしか利用しないものなので、データベースの設定などは特に気にせず初期設定のままにしておいて良いでしょう。
注意：2015年1月27日時点の最新バージョン2.0.0では、Vagrantfile.sampleの代わりにprovision/default.ymlをコピーし、provision/site.ymlにリネームした上で、各種設定を記述するように仕様が変更されたようです。今後も仕様が変わる可能性があるので、VCCWの公式サイトおよびGitHubリポジトリの説明をよく読んだ上で、適宜該当箇所の書き換えを行なってください。
プロビジョニングの実行
Vagrantfileの設定が終わったら、いよいよ仮想環境を立ちあげましょう。仮想マシンを起動するには、~/prj/littlebird/vccw/へ移動し、以下のコマンドを実行するだけです。
$ vagrant up初回のみ、環境構築に20分ほどかかり、ターミナルのメッセージがときどき止まりますが、処理が完了するまで気長に待ちましょう。/www/wordpress/というサブディレクトリが作成され、中にWordPress関連のファイルが入っていれば成功です。
※コマンド実行中に余計なキーを叩くと、処理が中断され、最後まで構築されない場合があるので、注意してください。構築に失敗した場合は、いったん「vagrant destroy」で環境を破棄して、再度「vagrant up」を実行すれば、最初から構築をやり直すことができます。
仮想環境の動作確認
環境構築が完了したら、先ほど設定したIPアドレス（192.168.33.10）をブラウザで叩いてアクセスしてみましょう。WordPressの画面（デフォルトテンプレートでインストールされた状態）が表示されたら、VCCWのセットアップが完了です。
ただし、このままでは管理画面にログインできないので、http://192.168.33.10/wp-login.phpにアクセスして、WordPressの利用を開始しましょう。先ほどVagrantfileで設定した通り、最初はadmin/adminでログインが可能です。
ホストネームでアクセスするには
IPではなく、Vagrantfileで設定したホストネーム（littlebird.local）でアクセスできるようにするには、vagrant-hostsupdaterというプラグインをインストールする必要があります。ターミナルで以下のコマンドを実行して、vagrant-hostsupdaterをインストールしてください。
$ vagrant plugin install vagrant-hostsupdater※ホストネームでのアクセスは、仮想環境の構築後でも適用可能です。一度「vagrant halt」で仮想マシンを停止してから、再度「vagrant up」で起動すれば、ホストネームでもアクセスできるようになります。
ローカルでのテーマ制作
ローカルの作業環境が整ったので、次にWordPressのテーマ制作を行いました。本サイトのテーマは、Automattic社が提供しているスターターテーマ「_s（Underscores）」をベースに、Bootstrapでカスタマイズを行っています。
今回は非常にシンプルなデザインということもあり、必要最低限のカスタマイズしか行いませんでした。ここでは詳しい説明は割愛したいと思いますが、制作過程やソースコードは本プロジェクトのGitHubリポジトリに掲載しているので、興味のある方はそちらを参考にしてみてください。
WordPressコンテンツの静的化
さて、Vagrantによるローカルの仮想環境でサイトの構築ができたので、WordPressのコンテンツをプラグインによって静的化しましょう。
WordPressのコンテンツを静的化するプラグインとしては、StaticPressとReally Staticが有名です。どちらもWordPressサイトのHTML化を行うことができますが、プラグインの仕様や機能に若干の違いがあるので、ご自身の運用スタイルや好みに応じて使い分けることをお勧めします。
StaticPressとReally Staticの比較
まず始めに、StaticPressとReally Static、両方のプラグインを使って、両者の違いを検証してみました。2つのプラグインから生成されたコンテンツを、ローカル上で開いて比較してみると、出力されるファイルに違いがあることが分かります。
StaticPressは、使用していないアーカイブのHTMLも出力してしまう他、テーマやプラグインのディレクトリ内にある画像やCSS、JSなども抽出して再生成してしまうようでした。これらのファイルは、静的サイトの公開には直接必要がないものなので、サーバに丸ごとアップしてしまうのは抵抗があります。
それに対して、Really Staticは、基本的に指定したアーカイブのHTMLと、アップロードしたメディア（画像）以外は生成しません。テーマ側で使用している画像やCSS、JSなどは、別途アップロードする必要がありますが、コンテンツ部分のファイルをシンプルに切り分けられるので、個人的にはアップロードの管理がしやすいように感じました。
以上の理由から、本サイトでは、Really Staticを使用して静的サイトの運用を行うことにしました。
Really Staticの使い方
WordPress管理画面の「プラグイン」→「新規追加」からプラグインを検索し、「Really Static」を見つけたらプラグイン名をクリックして、「いますぐインストール」を実行します。インストールが完了したら、プラグインのページからReally Staticを「有効化」しましょう。
Really Staticをインストールすると、「設定」メニュー内に「Really Static」の項目が追加され、ここからReally Staticの設定と再構築を行うことができます。
Really Staticの設定画面は、初期状態では全ての項目が利用できないので、まずはページ下部の「show Expertsettings」というチェックボックスにチェックを入れましょう。
「ソース」タブでは、ローカルのWordPress本体のURLと、テンプレートディレクトリへのパスを設定します。今回は、WordPressのURLをhttp:／／littlebird.local／とし、同様にテンプレートフォルダのURLを設定しました。
「設置場所」タブでは、ローカル上でファイルを生成させるパスや、実際に公開するサイトのURL、サーバ上のテンプレートディレクトリのパスなどを設定します。
今回は「ローカルのファイルシステムで作動させる」を選択した上で、『キャッシュされたファイルへの内部ファイルパス』を/var/www/wordpress/really-static/と設定しました。合わせて、公開サーバのドメインでURLとテンプレートフォルダへのパスを設定してあります。
「設定」タブでは、生成するアーカイブの種類や、生成するファイルの種類（拡張子）などを設定できます。今回は、トップページと投稿ページだけを生成したかったので、「indexページを静的にします」だけにチェックを入れて、他のアーカイブのチェックをオフにしました。
また、この画面の上部に「各 http:／／littlebird.local／ を http:／／littlebird.mobi／ にリライトする」というチェックボックスがありますが、ここにもチェックを入れておきます。
この設定をしないと、静的サイトを生成する際に、WordPressの一部のパスがローカルのドメイン（littlebird.local）のままで生成されてしまうので、注意しましょう。
「手動リフレッシュ」タブでは、ページ単位、またはサイト全体を手動で再構築することができます。
Really Staticでは、記事の投稿などのアクションに応じて自動的にコンテンツを生成するようになっていますが、初回の構築はこのタブから実行しましょう。「すべてのファイルを書き込む」ボタンをクリックすると、サイト全体の再構築を行うことができます。
サイトの公開
プラグインによる静的化のフローが確立したので、コンテンツをサーバへアップロードし、サイトの公開を行いましょう。アップロードするファイルは、テーマディレクトリ内に格納されている画像、CSS、JS等の共通ファイルと、プラグインによって生成される投稿ページ等のコンテンツに分かれています。
共通ファイルのアップロード
テーマディレクトリに格納されているファイルのうち、サイトの表示・動作に必要な画像、CSS、JS等だけを抜き出して、サーバへアップロードします。 あくまで一例ですが、本サイトでサーバ上にアップしているファイルの一覧は以下のものになります。
※テーマディレクトリ内には、他にもPHPファイルなど、色々なファイルが格納されていますが、静的サイトの公開には必要のないものなので、アップする必要はありません。
└── wp-content
themes
└── littlebird
├── bower_components
│ └── jbootstrap
│ └── dist
│ ├── css
│ │ ├── bootstrap-theme.min.css
│ │ ├── bootstrap.min.css
│ │ └── littlebird-site.min.css
│ ├── fonts
│ │ ├── glyphicons-halflings-regular.eot
│ │ ├── glyphicons-halflings-regular.svg
│ │ ├── glyphicons-halflings-regular.ttf
│ │ └── glyphicons-halflings-regular.woff
│ └── js
│ └── bootstrap.min.js
├── fonts
│ ├── Marck_Script
│ │ ├── MarckScript-Regular.ttf
│ │ └── OFL.txt
│ └── Source_Sans_Pro
│ ├── OFL.txt
│ ├── SourceSansPro-Black.ttf
│ ├── SourceSansPro-BlackItalic.ttf
│ ├── SourceSansPro-Bold.ttf
│ ├── SourceSansPro-BoldItalic.ttf
│ ├── SourceSansPro-ExtraLight.ttf
│ ├── SourceSansPro-ExtraLightItalic.ttf
│ ├── SourceSansPro-Italic.ttf
│ ├── SourceSansPro-Light.ttf
│ ├── SourceSansPro-LightItalic.ttf
│ ├── SourceSansPro-Regular.ttf
│ ├── SourceSansPro-Semibold.ttf
│ └── SourceSansPro-SemiboldItalic.ttf
├── img
│ ├── bt_facebook@2x.png
│ ├── bt_instagram@2x.png
│ ├── bt_twitter@2x.png
│ ├── logo@2x.png
│ ├── ogimage.png
│ ├── service01@2x.png
│ ├── service02@2x.png
│ ├── service03@2x.png
│ └── youthkee@2x.png
├── js
│ ├── customizer.js
│ ├── navigation.js
│ └── skip-link-focus-fix.js
└── style.cssコンテンツのアップロード
次に、Really Staticで生成したコンテンツ側のファイルをアップロードしました。これらのファイルは、really-staticフォルダ以下に保存されていますが、サーバ上ではドキュメントルート等、適切な階層に置き換えてアップする必要があるので、注意してください。
HTMLや画像ファイルは、コンテンツを更新する度に増えていきますが、初回以降は差分のみアップするような運用にした方がいいかもしれません。
└── really-static
├── 2014
│ └── 12
│ └── firstpost
│ └── index.html
├── index.html
└── wp-content
└── uploads
└── 2014
└── 12
├── firstpost.jpg
└── littlebird_theme.jpgAmazon S3への移行
最後に、静的サイトをさらに快適に運用するため、Amazon S3へ移行する方法を紹介します。Amazon S3は、AWS（Amazon Web Services）で提供されているクラウドストレージサービスで、サーバの運用や管理の手間を軽減できる様々なメリットがあります。
例えば、堅牢性99.999999999%、可用性99.9%という特徴がありますが、簡単に言うとデータがなくならないのでバックアップの必要もないし、サイトが落ちてアクセスできなくなるといった心配もほぼなくなります。
動的な機能のないサイトであれば、S3での運用で十分ですし、従量課金で1ヶ月辺り10円／1GB〜という低コストから利用できるので、個人のブログ程度であれば、かなり魅力的な選択肢と言えるのではないでしょうか？（※リクエスト数や転送量などに応じて別途料金が発生します）
Amazon S3での静的サイト公開
AWSのアカウント作成から、Amazon S3でコンテンツをアップするための「バケット」の作成までは、全てAWSのWebサイト上で行えるので、公式のチュートリアルなどを参考にすれば、迷わずに導入できるかと思います。
注意点としては、Amazon S3で独自ドメイン利用するには、ドメイン名と同じ名前でバケットを作る必要があります。また、「http://littlebird.mobi」のようなルートドメインで公開する場合、「www」付きのドメインも合わせてバケットを用意する必要があるので、『littlebird.mobi』と『www.littlebird.mobi』という2つのバケットを作成し、リダイレクト設定を行いました。
さらに、独自ドメインでのアクセスを可能にするには、AWSで提供しているRoute 53というDNSサービスを利用する必要があるので、各サービスのコンソールから設定を行いましょう。詳しい手順は、本プロジェクトのGitHubリポジトリにまとめてあるので、参考にしてみてください。
Really StaticとS3の連携
Amazon S3へのコンテンツのアップロードは、クライアントソフト等でも行えますが、Really Staticの連携機能を使うと、さらに快適な作業環境を実現することができます。ただし、S3との連携機能を利用するには、「Really Static Amazon S3 Plugin」というプラグインを追加でインストールする必要があります。
サポートサイトで配布されているzipファイルを解凍すると、「php-really-static-amazon-s3」というフォルダが展開されるので、このフォルダをWordPressのプラグインフォルダ（/vccw/www/wordpress/wp-content/plugins/）内に設置します。
すると、管理画面の「プラグイン」ページに『Really Static Amazon S3 Plugin』というプラグインが追加されているので、「有効化」をクリックします。
その後、Really Staticの設定画面を開くと、「設置場所」タブに『work with Amazon S3』という項目が追加されています。
ここにAWSの「Security Credentials」のページで設定した『Access Key ID』と『Secret Access Key』を入力し、バケットの欄に作成したバケット名（例：littlebird.mobi）を入力してください。
以上の設定をした上で、Really Staticによる再構築を行うと、該当のコンテンツファイルがS3上に自動アップロードされます。
S3へのアップは、サイト全体の再構築を行なった時だけでなく、記事を投稿したタイミング等でも、差分だけが自動的にアップされるので、WordPressをサーバ上で運用しているのと同じように、快適に更新できますね。
※Really Staticはdonationwareのため、追加プラグインを入手するには、寄付をするか、一定の貢献活動を行う等の条件を満たす必要があります。残念ながら、現在PayPalのポリシー上の問題で、日本のアカウントからは寄附が行えない状態になっているので、利用したい方はサポートサイトの説明をよく読んで、作者にコンタクトを取ってみてください。
まとめ
VCCWとReally Staticを使うことで、ローカル上に静的サイトを生成し、Amazon S3へ手軽に公開するフローを確立することができました。
個人的には、今まで頭を悩ませてきたWordPressサイトの保守やセキュリティ対策といった作業から開放されるので、これほど快適な運用フローはありません。MacBookさえ持ち歩いていれば、いつでも安全にWordPressが利用できるのですから・・。
デメリットと懸念事項
WordPressを静的化するデメリットや懸念点としては、リアルタイムに動的な表示や処理を行うプラグインが使えない、再構築にかかる負荷が心配、といった点が考えられると思います。
当サイトの場合、非常にシンプルな作りにしているので、動的なプラグインは使用していませんが、例えば人気記事のランキングを表示したいといったニーズが発生したら、Javascriptなど別のソリューションを検討する必要があるかもしれません。
また、再構築に関わる負荷ですが、今のところ全体構築でも瞬時にできていますし、当サイトの場合、月に1～2エントリー程度しか投稿しないでしょうから、数年運用してもほぼ気にしなくていいレベルだと考えられます。
こんな人にお勧め
複雑な機能のサイトや、更新頻度が非常に高いサイトの場合は、色々と検討事項があるかもしれませんが、個人ブログをサクッと立ちあげたい人にとっては、かなり魅力的な選択肢の一つと言えるでしょう。
最近は、JekyllやMiddlemanなどを始めとした、静的サイトジェネレータを使ってブログを構築している方も少なくないと思いますが、CMSとして洗練されたWordPressの各種機能や、ビジュアルエディタを利用できるメリットは大きいと思います。
WordPressをよく使う人や、静的にブログを構築したいけどコマンドラインはちょっと苦手という人は、ぜひこんなやり方も参考にしてみてはいかがでしょうか？
※当サイトの制作過程はGitHubリポジトリに公開しているので、より詳しい手順を知りたい方は、そちらをお読みください。