KUSANAGI+Wordpressの開発兼ステージング環境の作り方!維持費を安くするにはどうするべきか?

KUSANAGIで運用しているWordpressの開発兼ステージング環境の作り方についてそこそこ速くて安い、そして何よりもただのWordpressではなく、KUSANAGIで使える環境を調査、構築したので紹介します。

読了までの目安約5分

目次

現在、wordpress を conoha VPS の KUSANAGI 上で動かしています。テスト環境はアプリ単体で環境が整う Local by Flywheel を使用していますが、メインの開発環境が Macbook 12(2017)ということもあり、何しろ重い。。テーマが重めということもあって、ページを開くのに長いと 30秒かかるときもあり、困っていました。

重いだけでなく、KUSANAGI 自体のアップデートのテストができないというような問題もあります。実運用を考える上ではミドルウェア側のアップデートテストができないのは致命的です。

構築に時間がかからず、本番環境と同じくKUSANAGIが使えて、リーズナブル(月100円程度)な環境を作るべく、いろいろと調べ、試した結果、この目的では GCE が最適であることが分かったので、ほぼ備忘のようなものですが紹介したいと思います。

本番環境に近い環境から考える

まずは現状の conoha の VPS 関係から考えてみます。

本番環境にテスト用のKUSANAGIを構築する

一番簡単なのは現在本番が動いている環境に構築する方法ですが、KUSANAGI自体のアップデートが本番にも影響するため、致命的な状況には変わりありません。

そのため、この方法は却下となりました。

新たにconohaでVPSを借りる

これは確実にできる方法ですが、一番安いプランでも月630円かかります。テーマの変更等は毎日のように行う作業ではなく、conoha は VPS を停止してもイメージを削除しない限り料金がかかり続ける仕様のため、これも却下となりました。

KUSANAGIが簡易に構築できるクラウドサービスを検討する

KUSANAGIが使用可能なパブリッククラウドが公開されているため、この中で使用できそうなものを探します。

Amazon Web Services (AWS)

このサイトを含め、Wordpress以外の環境は AWS で構築することが多いため、まずは AWS を検討します。KUSANAGI for AWSは EC2 のインスタンス作成時にマーケットプレイスを選択すると使用可能になります。

はじめはこれで試しましたが、コピー元のスナップショットが 30GB 以上あるため、30GB以上のボリュームを確保しなくてはならないことが判明しました。EBS は、1月・1GB あたり、最安のマグネティックを使用しても 0.08USD かかるため、ディスク維持費のみで 2.4USD(約300円程度)かかる計算となりました。

しかも、インスタンスを使用するときのみ起動する予定のため、IP アドレスが変わる面倒くささなどを考えると、まだ conoha の最安プランの方がマシということが分かり、却下となりました。

Google Compute Engine (GCE)

まず、Always Free の f1.micro を使用していないのであれば、それを使用して構築するのが最安かつ一番面倒ではありません。 私の場合、すでに開発環境兼顧客向け確認環境として使用しているため、さらにここに乗せるのは面倒だったので諦めて新規でインスタンスを作成しましたが、もし使用していないのであればこれが最良です。

インストール方法は、公式のKUSANAGI for GCPに従って進めるのみです。5-10分程度で環境が出来上がります。

作成時には f1.micro で作成することはできません。まずはデフォルト設定で進めてあとで変更します。

ちなみに、GCE の場合、ディスク容量を10GBと小さくしても問題なく作成できます。この点が AWS とは大きく違いますね。10GB の永続ディスクだと月0.44USD(約60円程度)とかなり安く維持が可能です。あとはインスタンス利用料のみで済むため、使用しないときに停止させておけばテスト環境兼ステージング環境としては完璧です。

デプロイ後に変更しなくてはならない点

まず、VMを停止させ、インスタンスの詳細から「マシンタイプの変更」を行います。VMが起動していると変更できません。ここで f1.micro に変更すれば作業は完了です。

また、初回の接続は SSH ボタンから「ブラウザウィンドウで開く」から接続できるので、接続後、任意のユーザーを作成し、sshd_config を適宜の設定にし、以後はすきなクライアントから接続できるようになります。なお、このイメージでは、kusanagi ユーザーがすでに存在しているため、特に問題なければ kusanagi ユーザーのまま進めると楽だと思います。ちなみに、kusanagiユーザーとブラウザからのadminユーザーはともにパス無しでsudo実行が可能です。

GCEで構築してみた感想

ん いつも AWS を使用してばかりだったので、GCE で構築してみるのも経験として良かったと思います。金額的には微々たる差ですが、ディスクの料金等も GCE の方が分かりやすいように思いました。

それ以外に今回の環境を作ってみた感想です。

構築が5分程度で終わるのは素晴らしい

Docker や Ansible で Wordpress を構築するより全然楽です。構築後の状態で ansible を実行させれば一瞬で環境を作り直すこともできそうです。

また、今回あわせて wordmove の設定を見直し、すべて wordmove 経由で環境を作ることができたので、本番クローンがいつでも簡単に作れる状態にできたのはありがたいです。

KUSANAGI のアップデートとプラグインアップデートのテストが気軽にできる

地味に今まで怖くて KUSANAGI 自体のアップデートはできてきませんでしたが、テスト環境で試せたのと、いつでも別環境に作り直せる状態が作れたため、気分的には安心して更新ができました。

専用の環境は気にすることが少なくて良い

他の開発環境等と共存した環境だとどうしてもダーティになってしまったり、他への影響を考えてしまいますが、そういったことを気にせず気軽に実行できるので嬉しいです。このあたりは Docker を使っても同じようにできますが、本番では Docker を使用していないため、本番により近い環境で行えるという意味でも、このような構成は十分意味があると思います。