はじめまして、インフラチームの菊池です。
PIXTAサービスは基本的にRailsで作られていますが、一部のコンテンツはWordPressを利用して運営されています。 ただし、これらのコンテンツはPIXTAサービス本体と比較するとあまり手をかけずに運用されてきました。
今回はそのWordPressのサーバー構成・管理方法を変更し、ソースファイルをGit管理したというお話です。
経緯
ピクスタではAWS OpsWorksを使ってサーバーの管理を行っていますが、WordPressの稼働するサーバーはOpsWorksによる管理はされておらず、明確な構築手順も存在しないような状態でした。
開発やステージング環境もなく、ファイルのバージョン管理も行っていなかった為、テンプレート修正などの開発作業は非常に気を使うものでした。
※開発業務（主にテンプレート修正等）は基本的にデザイナーが行っています
インフラチームではこれらの状況を改善すべく、以下のような課題解決に取り組みました。
- インフラ視点での課題解決：
- OpsWorksによるサーバーの管理
- 開発業務視点での課題解決：
- ファイルのバージョン管理導入
- 開発・ステージング（確認）環境の設置
- リリース（デプロイ）フローの確立
検討事項
前述の課題解決について具体的な方策の検討を行った段階で、特に考慮を要する点がいくつかありました。
- 開発環境をどうするか
- ファイル管理をどうするか
- リリース作業をどうするか
開発環境について
プロダクション環境とステージング環境については、OpsWorksによってサーバーを構築・管理するというのが前提となっていましたが、開発環境をどこにどう構築するかが課題となりました。
各デザイナーは、PIXTAサービス開発の為各自のPC（Mac）に開発環境を構築していますが、構築や変更の際には開発エンジニアのサポートが必要です。 エンジニアが関与しないWordPressコンテンツの開発環境については、デザイナーが自身で構築でき、かつ安定運用できることを目標とし、WordPressの開発環境として事例も多そうなVirtualBoxとVagrantを使用することにしました。
Dockerという選択肢もありましたが、MacでのDockerはまだ安定感が足りない印象でした。
開発環境構築にあたってはvccwが大変参考になりました。
ファイル管理について
ピクスタのデザイナーはPIXTAサービスの開発作業においてGitを使っており、自然とGitでファイルのバージョン管理を行うことになりました。
ここで検討課題となったのは、どこまでのファイルを管理対象とするかでした。
プラグイン
WordPressの場合、管理画面での追加・削除操作によりプラグイン関連のファイルが生成・変更される為（同時にDBへの変更の可能性もある）、これらのファイルは管理対象外とし、管理画面上での管理に任せることにしました。
WordPress本体のシステムファイル
こちらもアップグレード時に管理画面操作によりファイルが変更されるという、プラグイン同様の問題がありますが、これらのファイルはシステムに不可欠であり、管理対象外とした場合環境構築手順が複雑になると想定された為、管理対象としています。
管理対象外のファイルについて
最終的にはプラグインディレクトリの他に、記事の添付ファイルが入るアップロードディレクトリやキャッシュ関連のディレクトリなどを管理対象外としました。
これらのディレクトリはsharedディレクトリ以下に配置して各リリース間で共有できるようにしています。
リリース作業について
PIXTAサービスのリリース作業は開発エンジニアが行っており、デザイナーはリリース作業の経験がありませんでした。 しかし、OpsWorksコンソールを利用してのリリース作業は、それほど難しくないため、デザイナーがOpsWorksコンソールからリリース作業を行うことにしました。
ただし、プラグインの追加・削除とWordPress本体のアップグレードについては、手順が通常のリリース作業とは異なる為注意が必要です。
前述の通りプラグインについてはGitの管理対象外としたので、各環境のWordPress管理画面上で追加・削除作業を行います。
本体のアップグレードについてもプラグイン同様に管理画面上でアップグレード処理を行うことになりますが、こちらは管理対象ファイルが変更されることになるので、変更されたファイルをGitリポジトリへ登録するという作業も必要になります。ちょっと複雑ですね。
以上の検討の結果、以下のような構成・フローへと移行作業が行われました。
- 環境構成
- プロダクション環境 ー AWS：OpsWorks管理
- ステージング環境 ー AWS：OpsWorks管理
- 開発環境 ー 各自PCローカル：VirtualBox + Vagrant
- ファイル管理
- Gitを利用
- プラグインディレクトリ等一部ディレクトリは管理対象外
- リリース
- デザイナーがOpsWorksコンソールで実施
- プラグイン追加・削除、本体アップグレードは各環境の管理画面で実施
工夫したところ
実際の作業の中で、開発環境の構築については開発業務を効率化できるよう工夫をしましたので、いくつか紹介させていただきます。
環境構築の半自動化
デザイナーがターミナルでの操作に不慣れな場合もあるので、極力ターミナルでの操作を減らすよう環境構築の一連の処理をスクリプト化しました。
VirtualBoxなどの必要なソフトウェアが入った状態であれば、このスクリプトを実行するコマンド一つで環境を構築できます。
一度環境を構築した後はVagrantコマンドによりいつでも開発環境を起動できるようになりますが、Vagrantの起動・停止コマンドは単純なものなので、finderからファイルのダブルクリックで実行できるよう起動と停止の為のコマンドファイルを用意しました。
開発環境へのデータ投入
ご存知の方もいらっしゃるかもしれませんが、wordmoveというgemがあります。
これはある環境に存在するWordPressのDBやファイルを別の環境に同期し、さらにサイトURLの置き換え等も行ってくれるものです。
最初に開発環境（VM）を起動する際にこのwordmoveを使って管理対象となっていないデータ（プラグイン／アップロード／DB）をステージング環境から同期するようにしました。
常にデータが入った状態でコンテンツの閲覧・開発作業を行うことができます。
※ステージング環境には今回の作業時にプロダクション環境から取得したデータが入っています。
VM１つで複数コンテンツを開発可能に
PIXTAサービス内には複数のWordPressコンテンツがありますが、前述の環境構築スクリプトでコンテンツを任意に追加できるようにしてあり、1つVMを起動すれば追加された全てのコンテンツの閲覧・開発作業を行えるようにしました。
まとめ
現在PIXTAサービス内のWordPressコンテンツは新しい構成のもとで運用されています。
プラグイン更新や本体アップグレード作業については若干課題感が残ってしまったものの、当初解決を目指した課題については想定通りに解決でき、運用環境を大きく改善できたのではないかと思います。
開発環境にVirtualBox+Vagrantを使ったり、wordmoveによるデータ同期を行ったり、WordPress界隈では特に新しいことではないかもしれませんが、似たような状況にある方、またこれからWordPressを利用しようとしている方にとって、この記事が参考になれば幸いです。
今後は機会があればDockerを使った開発環境構築などついても検討してみたいと思います。
WE ARE HIRING!
