/* */

WordPress on GAE Standard 構築(済)

時事ネタ(ブログ),更新情報

前回のKusanagi on GKEギブアップからまだ懲りてません(笑)
今度はGoogle App Engine(GAE)を使ってWordPressを構築します。

ちなみにStandardの方で構築するので、CloudSQL以外は、使った分だけお金を支払えばよいというスグレモノ。しかもスケーリングも証明書も、何もかもやってくれるオマケ付き。

間違えてフレキシブルで構築すると、自由度が高い代わりにGCEインスタンス代がコンスタントにかかってしまうので注意です。比較表はこちら(外部サイト) https://www.serversus.work/topics/5jbu7y90jk81kcdqfzf0/

進捗状況

今回のは実はもうサイトできてます。既存のサイトからの移行方法も検証済。
サイトはこちら。 ※2020/09/29追記 移行しちゃったのでもうありません。

ハハッ。
田中(゜p゜)の技術者としての能力も捨てたもんじゃないね！

というか、田中(゜p゜)は昔この構成でWordPressやったことあるんですけどね！
最近チュートリアルがアップデートされて、画像ファイルとかの扱いがさらに容易くなりました。

GKEであれだけ苦戦してたのがウソのよう。
GAEサイコー!

運用上の注意点

ただし、そんなに上手い話は世にはなかなかないのです。
カンタンにできるから真似してみよう！ と思われる方のために注意点。

この構成の一番の問題は、GAEに上げちゃったが最後、WPのGUIから更新できないものが発生することです。

更新できないものを以下に並べます。

  • プラグイン(設定は除く)
  • テーマ(設定は除く)
  • 投稿・固定ページへの直接画像貼り付け(メディアライブラリからはOK)

3つともかなり致命的だと思います。
これに関連してWP側でエラーが出ることがありますが、そもそもGAEはディスクに書き込めないものだというのを知っておかないと混乱します。

回避方法

カンタンにいうと、ローカルにサーバを立てて、そこで管理します。
GAEはCloudSQL Proxyってのを使わないとCloudSQLには接続できないので、ローカルにも同じプロキシを入れてDBにアクセスできるようにします。
図中の①です。

また、ローカルのWordPressは、環境構築した後、yaml書いてGAEにデプロイします。
図中②の部分です。

じゃあ更新はどうするのかというと、ローカルにPHPサーバ構築して、WordPressのGUIを動かして更新します。

記事はDBに書かれるので特にアクションは必要ないですが、画像、テーマ、プラグインを更新した場合は②のデプロイが必要になります。

デプロイはワンライナーですけどめんどくせえ・・・。
けど、WordPressをクラスタ化したら、どのみち更新用の端末とか必要になってきそうだしなー。

構築方法

それでもやりたい方のために、構築を方法を書きます。

つ Googleのチュートリアル。
https://cloud.google.com/community/tutorials/run-wordpress-on-appengine-standard?hl=ja

…というだけでは投稿の意味がないので、注意点を少し。

  • チュートリアルにミス。
    ×php vendor/bin/wp-gae
    ○php vendor/bin/wp-gae create
  • WP CLIのインストールは、チュートリアルじゃなくて公式のほうが良い。
    https://wp-cli.org/ja/
  • サーバの作り方が書いてないが、php、php-mysqlインストールして、以下で行ける。
    cd <WordPressのフォルダ>
    php -S 127.0.0.1:9000
    ブラウザでhttp://127.0.0.1:9000/にアクセス。
  • ただし遅いので、レスポンス気になるならきちんとサーバ立てたほうが良い。

更新の早い世の中ですから、公式と最新版のギャップは大きくなっていくものと思われます。もちろんこのブログもです。

以下、既存のWordPressサイトからの移行方法ですので、新規の方は見なくて良いと思います。

移行方法1： 移行用プラグイン利用

要は移行用プラグインを移行元と移行先に入れて、エクスポート→インポートするだけのはずですが、ローカルのホスト名が127.0.0.1なので、サイト内でのURL整合性が取れなくなります。

賢い移行ツールは、インポート先のホスト名を見て、DBなり設定ファイルなりを書き換えてしまうのです。そのおかげで、見た目キレイに移行できるんですけどね…。

田中(゜p゜)がこれを解決するためにやったのは、以下のような感じです。

  • 念の為、移行元サイトの絶対パスを相対パスに書き換えておく。このあたり参照(外部サイト)
    スタティックに書いてるやつは修正が必要かもしれない。
  • ツールで移行元からおもむろにエクスポート
  • host等で移行先サイトのFQDNを、127.0.0.1で解決できるようにしておく。
  • php -S <移行先のFQDN>:80
    コマンドでサーバを起動し、ブラウザでhttp://<移行先のFQDN>/にアクセス。
    ※移行先と混乱しないよう、PING等で事前に宛先確認。あとCloudSQL Proxyの起動を忘れないこと。
  • ツールでおもむろにローカルにインポート
  • GAEにデプロイ
  • 外部確認の際は、hostsは元に戻す

こうすると賢いツールさんも、自分が移行先にいるのだと勘違いして、正しくない設定を入れてくれます。※デプロイ先では正しい。

それでもテーマ設定等、一部の設定は反映されないので、サイト全体に渡って確認必要です。それと、一部のプラグインは入れ直しが必要かもしれません。

デプロイした後にファイルを勝手に書くような、お行儀の悪いプラグインは削除ですね。

移行方法2： 力こそパワー

すみません。
要するに、多くのサイトがやっているWordPressの標準機能を使うやり方です。田中(゜p゜)も念の為やってみました。

  • 移行元WPの管理画面のツール→エクスポートでDBをエクスポート
  • 移行元のwp-contentフォルダをダンロードし、ローカルのwp-contentにコピー
  • 移行元のエクスポートファイルを移行先にインポート

で、キレイに行くはずなんですが、全然見た目が反映されません。おそらく以下はDBのどこかに保存されていて、エクスポートでは出ないものと思われます。

  • プラグインの設定
  • テーマ設定

プラグインの設定はともかく、テーマ設定は非常にしんどいです。

この方法はDBや設定ファイルに余計なことしないので、わかりやすくはありますが、移行後の作業量がエグいです。

田中(゜p゜)の既存サイトはどうするのか

結局、ローカルにコンテンツ置いとかなきゃいけないのがリスキーな気がしていましたが、コンテンツはクラウドにあってなくなるわけじゃないですし、この後Gitなどでの運用の学習も考えると、デプロイ前提でどこかに置いておく、というのは悪くない気がしてきました。

大規模な運用を鑑みると、結局更新用端末と、閲覧用のサーバー分けなきゃいけないような気がしますしね。

何より、GAEのコスパと性能がダントツだし、面倒だったHTTPS化と証明書のインポートをごくサラッとやってくれたので、ちょっと移行しちゃおうかなー、なんて考えています。

(終)