GCEでWordPressがほぼ無料運用できるようになったので改めてまとめる

ある企業の採用試験に実技があったので、練習がてら(多少のコストアップは覚悟の上で)Google Cloud Platformに趣味のサイトを移転したのですが、まさかここまでコストダウンする結果になるとは思いませんでした。 私のサイトはテキストコンテンツメインかつアクセス数が少ないため、メディアサイトや大規模サイトの場合はそれなりに費用はかかってくるかもしれません。 小規模な個人サイトを立ち上げる場所としては、費用もスペックも国内の格安サーバーよりずっと良くなります

おさらい

かつて、Google Cloud PlatformにWordPressを載せる方法は2つありました。
  • PaaSであるGoogle App EngineとCloud SQLを併用する方法
  • IaaSであるGoogle Compute Engineを利用する方法
WordPressはデータベースを必要とするので、いずれも今年の2月頃までは無料枠では運用できませんでした。

Google App Engine + Cloud SQL

  • GAEは無料枠が大きく、個人サイトなら無料枠で大丈夫
  • Cloud SQLが有料
    • GAEと連携したい場合は第1世代しか選択できない(私は第2世代でインスタンスを作成していてここでかなり詰まっていた)→今はできる(コメント参照)
    • 月額$10は下らない→当時の価格なので今は知らない
  • .htaccessが使えないので、専用にカスタマイズされたWordPressを用いる必要がある
というわけで、予算と実装の関係でこちらは諦めていました。 やり方自体は色々と先人が書き記してくださっているので以下の記事等を参考にどうぞ。

Google Compute Engine上にLAMP環境またはLEMP環境を構築

IaaSなので、基本的には自分が選択したOS等へのインストール方法と全く同じです。私は初心者だったので無難にDebian上にLAMP環境で構築しました。 GCPからクリックでインストールも出来るようですので、あまり知識が無い人でもGCEを使ってWPサイトを運用する事は可能でしょう。 しかし、Googleのヘルプは素人向けではなく、セキュリティ対策やメモリ周りのチューニングも必要です。これからプログラミングやサーバーについて覚えよう、というつもりならおすすめしません。格安サーバーで自動インストール出来る所もあるのでそちらを利用しましょう。

新料金体系(Always Free)での運用コスト

新無料枠についてはAlways Freeを参照。 私はGCEを昨年末から利用し、試用期間後は700円/月程度の費用を予想していました。 3月の途中でGCEの無料枠が拡大され、4月いっぱい新料金体系で運用した所、GCEの費用はアメリカから中国へのデータ通信費1円のみでした。 一応、他にはCloud DNS及びCloud Storageも利用しており、画像等の通信費がかさみそうなものはストレージから配信する等の工夫をしています。 Storageの方は十分無料枠に収まり、DNSの方は請求がありましたが、多少アクセス数が増えたり為替が変動したりしても月100円を超える事は当分なさそうです。 米国リージョンなので、どうしてもアジア方面への通信費が課題でしたが、APACへの通信費が1GBまで無料となり大変助かっています。 一方私のサイトでは、中国への通信費は、今後更に増大する可能性があります。コンテンツの違法コピー問題で、長年中国からのアクセスは(全面的にではないにせよ)締め出す方針を取っていました。しかし、近年は身を置くジャンルでも中国での発展・中国への参入が著しく、中国語翻訳をサイトに追加し、アクセス制限を緩めたためです。 いずれにせよ、WordPressでブログを運用する程度では全く問題無いでしょう。

Google Compute Engine上にWordPressをインストールする

下準備

本当はgcloudコマンドでファイルをコピーするのが良いのでしょうが、私はGoogleの(現時点では)無料の非公開リモートリポジトリを利用しているので、必ずそちらを経由してサーバーとファイルをやり取りすることにします。とりあえず、 をローカルマシンにインストールしておきます。

VMインスタンスの作成とApacheのセットアップ

公式にマニュアルがあります。 注意点としては、
  • 静的IPアドレスをVMインスタンス作成時に予約しておく(詳細設定を開いてネットワークから)
  • sudo /etc/init.d/apache2 startでApacheを起動しておく
  • HTTPS接続を許可してあっても、https://~~ではエラーが出るので注意。ブラウザからクリックで移動すると自動的にSSL接続になってエラーが出ますが、sを消して起動を確認できます
インスタンス一覧の「接続」から接続情報が確認できます。
mod_rewriteの有効化
以下の記事を参考に、mod_rewriteモジュールのインストールを確認。

WordPressの引越しでパーマリンクの404 Not Foundエラーが発生

現行システムをCentOS5.3からCentOS6.4に変更することにした。 CentOS6.4のサーバを構築し、そこにWordPressの引越しをした。 やっとトップページも管理画面もまともに表示されたと思ったら、今度はエントリのタイトルやカテゴリーをクリックして表示させようとすると404 Not Foundエラーが発生した。 表示されたパーマリンクが文字化けしているようなので文字コード関連のエラーかと思ったらそうではないらしい。 トップページのエントリー一覧は普通に表示される。 図1:トップページ 各記事のエントリータイトルのパーマリンクをクリックすると、以下のように404 Not Foundエラーが表示される。 しかも、URLが文字化けしているようだ。 カテゴリーをクリックしても同じようにエラーが表示される。 図2:404 Not Foundエラー パーマリンクの設定は以下のようにカスタム構造で/%category%/%postname%/としている。 カテゴリーとエントリーのタイトルがURLに設定されている。 図3:パーマリンク設定 パーマリンクをクリックして404 Not Foundエラーが出るということは、リンク切れを起こしているということだ。 WordPressのパーマリンクは、Apacheのmod_rewriteモジュールのRewrite機能を利用している。 つまり、Apacheのmod_rewriteモジュールが組み込まれていない場合、パーマリンクは有効とはならない。 そこで以下のように確認してみた。 # grep mod_rewrite /etc/httpd/conf/httpd.conf LoadModule rewrite_module modules/mod_rewrite.so #find / -name mod_rewrite.so -print /usr/lib64/httpd/modules/mod_rewrite.so   httpd.confにも設定はあるし、mod_rewrite.soもきちんとインストールされている。 WordPressでは、インストールディレクトリ直下に.htaccessを置き、この中でパーマリンクのRewrite設定を記述している。 元のサーバからごっそりコピーしてきたので、ないわけはないのだが念のために確認してみる。 # cat /var/www/html/wordpress/.htaccess # BEGIN WordPress RewriteEngine On RewriteBase /wordpress/ RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .

mod_rewrite.soは存在したので、apache2.confにてロードさせたところApacheが起動できない。 どうやら機能そのものが有効化されていなかったので、a2enmod rewriteで有効化。 すると今度はサイトの方で500エラーが出る。ともかく、以下の事をしたら500エラーはなくなった。 まず、以下をapache2.confに追記して再起動。

<Directory /var/www/html/>
LoadModule rewrite_module modules/mod_rewrite.so
Options Indexes FollowSymLinks
AllowOverride All
</Directory>
次に、WordPressのサイトURL、ホームURLを現在のIPアドレスにする(Adminerから編集)。 そして、.htaccessを初期状態にする
#BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
#END WordPress
あとsudo a2enmod expiressudo a2enmod headersもやっておく。

PHP7のインストール

PHP7は自分でコンパイルする必要があるが、GitHubから簡単に取って来れる。

Debian8(jessie)にphp7をインストールしてApache2.4で動かす

自宅サーバを新調して、旧自鯖の必要なデータは全て新鯖に移行した。 Debianもwheezyからjessieになった。 Debian jessieでもaptでphpをインストールすると5.6が入るが、php5.6のサポート期限は2017年8月となっており、あと1年も無いのは微妙。 それならいっそ、早いと巷で噂のphp7を入れてやろうじゃないか。 前提:Debian jessie , Apache2インストール済み ※ Apacheで使う前提の手順 php7のインストール方法は 謎のリポジトリ を追加する方法も知られているが、GitHubから簡単にインストールできたのでそちらでいく。 1.gitが入ってない場合はインストールしておく $ sudo apt-get install git 2.適当なディレクトリでクローンを作成 $ git clone https://github.com/kasparsd/php-7-debian.git 3.build.shを編集 マニュアルにはそのままbuild.shを実行しろとあるが、 そのまま実行するとApache用のモジュールを生成してくれない。 CONFIGURE_STRING=""の中に 「-with-apxs2=/usr/bin/apxs」 「-with-apxs2=/usr/bin/apxs2」を追加して上書きしてやる必要がある。 ※apxsがインストールされていない場合apache2-devもインストールする必要がある(と思う) 2017/05/09追記 apxs2が存在しない場合、以下をインストールする。 preforkならapache2-prefork-dev workerならapache2-threaded-dev $ cd php-7-debian $ sudo vi build.sh --with-curl \ --enable-fpm \ --with-fpm-user=www-data \ --with-apxs2=/usr/bin/apxs2

ただこの記事にも

apxsがインストールされていない場合apache2-devもインストールする必要がある
と書かれている通り、apxsの設定を追加するだけではビルド(インストールだったかも)に失敗した。/usr/lib/apache2/modules/libphp7.soはあったけど/etc/apache2/mods-available/php7.confは無かった。 apache2-devを入れてから再度ビルドしたが、Apacheを切り忘れていたのが原因か、それとも他に原因があるのか、インストールに失敗する。あとはphp.iniがコピーできないとか色々。まあとにかくPHPをちゃんと入れるのが先ですね。 途中で作業を中断し、出かけて帰ってきたら今度はApacheも起動しなくなっていた。
your PHP Module is not compiled to be threadsafe
との事なのでThread SafeなPHPをビルドし直した。 php + apache のメモリ量をおさえる(2) workerを使ってみるも参考に、build.shに以下を追加。
--with-apxs2=/usr/bin/apxs2 \
--with-tsm-pthreads \
--enable-maintainer-zts \
ただ今度はメモリが足りない。以下の記事の方法で回避。 ビルドしたら再インストール。
  • /usr/local/php7/etc/conf.d
  • /usr/local/php7/sbin/php7-fpm
が既に存在すると止まってしまうので、削除してから、
./build.sh
sudo ./install.sh
とにかくこれで無事インストールできました。 php.iniでの日本語設定などはこのページなどを参照。

MySQLのインストール

これも公式にマニュアルがあります。日本語情報少ないって言われてたけど、案外ありますね。 データ移転はAdminerを一時的に設置して行いました。 最終的に、容量が大きすぎて一部はコマンド叩いてやったんですけれども。大きいファイルは一旦ローカルのコマンドプロンプトに戻ってから
gcloud compute --project "プロジェクトID" copy-files --zone "ゾーン" hogehoge.sql インスタンス名:hogehoge.sql
でGCPにアップロードし、GCP側でsourceコマンドでインポートします。

WordPress用のユーザーの作成

WordPress用のテーブル全てに全権限を持つユーザーを作ればOK。 wp-confing.phpの方は
define('DB_HOST', 'localhost');
にするのを忘れない。

WordPress本体のアップロード

前述の通りリポジトリ経由でアップロード。 自動更新、サイトマップなどファイルの生成、キャッシュシステムの設定など、WPの管理画面側からサイトを管理するには/var/www/html/以下のディレクトリやファイルを、Apacheを起動させているユーザーの所有にしておく必要がある。 パーミッションが664とかでもユーザーが違うと上手くいかない。 (WPはパーミッションよりも所有者を優先させるらしい)今回作った環境でのコマンドは以下。
sudo chown -R www-data:www-data /var/www メモ:wp-config.phpの属性を400にすると500エラー。404なら大丈夫。サイトが落ちたらまずwp-config.phpの属性と所有者を確認すること。

独自ドメインの設定

静的IPがあるのでそれを各自登録すればOK。

Let’s Encryptの導入

[Qiita](https://qiita.com/yukari-n/items/5facc46317246ded4c05)に書き写しました。
この他のちょっとしたTIPS等はQiitaに投稿しています。メールの設定もQiitaに書きました。

Search result of " user:yukari-n tag:googlecomputeengine" - Qiita

Qiita is a technical knowledge sharing and collaboration platform for programmers. You can record and post programming tips, know-how and notes here.


本当は過去記事を再アップするつもりで書き始めたのに、肝心の過去記事データを紛失していて(しかもその事に書いている今気が付いて)何を書こうと思っていたのかよくわからなくなってしましました。見つかったので編集して再掲しました! とにかく言いたいことをまとめます。

  • サーバー運用費がほぼ無料になる(独自ドメインは必須となる)
  • Googleのインフラは速い(米国リージョンだと日本から距離があるため、原理的に越えられない速度制限は存在する)
  • SSLやメールも無料で設定できる
これらの点が国内の格安レンタルサーバーに比べてアドバンテージなので、今後サイトを立ち上げる時の候補の一つにしていただければ。 勿論WordPress以外のCMSも入れられます。