Web メディアの開発と WordPress

KODANSHAtech が行っている中心的な業務は Web メディアの開発です。携わっている Web メディアは多様なジャンルに及び、中には KODANSHAtech よりもずっと歴史が長いものもあるため、利用している CMS の種類もまた様々です。

ただ、その中でも WordPress は特別な存在感を放っていて、現在、二桁の WordPress CMS を常に運用しています。今後、さらにその数は増えることになるでしょう。

私たちが Web メディアを開発、そして運用していく業務において WordPress は欠かせない存在となっています。

一貫した WordPress 開発と運用のために

このように数多くの WordPress サイトを限られた人数で開発・運用する場合、サイトがすべて一貫した構成となっていて、同じ方法論で扱うことができることが極めて重要だと考えています。

それぞれ自由に構築されたサイトが何十個もあった場合、同じ WordPress で作られたものであるといっても、そのメンテナンスのコストはとんでもなく大きいものになるのは容易に想像できるでしょう。

また、保守運用だけでなく、開発面でも一貫した開発が行えることが必要です。特に KODANSHAtech のエンジニアは Web サービスの開発を専門にしているメンバーが多いため、Web サービス的なソフトウェア開発の流儀にしたがって開発できるように構成されていることが重要になります。例えば Twelve-Factor App のような構成であれば開発をスムーズに進めやすいですが、WordPress そのものはそういった構成を提供していないため、自分たちで考えて構成する必要があります。

これから、私たち KODANSHAtech がこういった課題と向き合いながら、WordPress 開発を支える基盤として考えていることや、具体的に用意している技術について、ごく簡単に紹介したいと思います。今回は本当に触りだけの紹介となりますが、また今後詳しい内容もお伝えできればと考えています。

WordPress 開発を支えているもの

KODANSHAtech の WordPress 開発を支えている代表的なものを大まかに取り上げると以下になります。

  • Bedrock
  • スターターテンプレート
  • AWS CDK

これから、このそれぞれを簡単に紹介します。

Bedrock

Bedrock は、Roots が OSS で提供している WordPress ボイラープレートです。

GitHub リポジトリの README に

Much of the philosophy behind Bedrock is inspired by the Twelve-Factor App methodology including the WordPress specific version.

とあるように、まさに Web サービスのエンジニアが開発・運用しやすい Twelve-Factor App を意識して作られているものとなっています。

Bedrock をベースにすることで、out-of-the-box の状態でこれらが可能になります。

  • composer を利用したプラグインや依存パッケージの管理
  • Dotenv を利用した環境変数による環境ごとの構成管理

言い換えると、Git を利用した WordPress サイトのバージョン管理やコードレビュー、そして、開発環境やステージング環境などを含んだ複数環境での CI/CD の構成が非常にやりやすくなります。

また、Bedrock ではディレクトリ構成も WordPress のデフォルトインストールの状態とは異なり、WordPress のコアファイルが開発対象のファイル (テーマなど) や設定ファイルから分離して格納されます。WordPress はそのシェアからどうしても攻撃対象になりやすいのですが、そのほとんどはデフォルトの URL を対象とするため、このディレクトリ構成によって攻撃対象となるリスクを軽減する効果もあります。

もちろん、Bedrock を使わなくてもこれらを実現することは可能ですが、実際に何度かやってみて、結局突き詰めていくと Bedrock と類似の構造になってくることを実感として得たので、最初から Bedrock に依存する方がメリットが大きいと判断しました。

KODANSHAtech ではさらに、この Bedrock をベースとした WordPress サイトを高速に構築するために使える Docker のベースイメージを用意し、定期的に更新しています。

イメージのタグを immutable にできていなかったり、GitHub Actions でイメージをビルドしているために ARM64 イメージのビルドに非常に時間がかかるなどいくつかの課題もありますが、これによって、必要な OS パッケージやミドルウェアが構成済みの Bedrock 環境がすぐに用意できるようになっています。

スターターテンプレート

前項で紹介したように、Bedrock と専用の Docker ベースイメージを利用することで、開発しやすい環境を高速に構築することができるようになっています。

しかし、各部署や編集部の求めるスピード感に応えるためには、より即座に環境を用意できるようになっている必要があり、また、ベースイメージに Bedrock をセットアップするのは各開発者の作業となるため、一貫した環境を構築するにはもう一工夫が必要になりました。

そこで、シンプルに clone すればすぐに使えるスターターテンプレートを用意しました。git clone してから1分とかからずローカルに立ち上げた WordPress にログインして使えるようになります。

これは現在のところパブリックに公開しているものではないので、実際のものを見ていただくことができないのですが、clone した時点からすぐに以下が使える状態になっているものです。

この中で、実際に利用していて特に価値があると感じるのが「VS Code の Visual Studio Code Remote - Containers を利用した Docker 開発環境」です。これによって、開発者がローカル開発環境を起動するための手順が VS Code の1コマンドだけになりますし、起動スクリプトを設定することができる機能を使って、WordPress のインストールから共通プラグインの有効化も含めた初期設定までをすべて自動化することができます。起動スクリプトは実際に動く形での設定情報のドキュメンテーションという役割としても利用することができています。Linter や formatter などのコードスタイルの統一についても事前の設定なく機能しますし、導入効果が一石二鳥どころか三鳥も四鳥もあると実感しています。

また、これらの機能面とは別で重要視して設計している点としては、スターターそのものが古くなってしまわないための工夫があります。ありがちなパターンとして、スターターテンプレートを作ったけどそのメンテが停止してしまっていて、スターターを使うと古いものになるため使いにくい、というものがあると思います。なので、これを回避するための工夫を仕込んでいて、例えば1コマンドを実行するだけでスターターの Bedrock と最新の Bedrock の更新差分が取得できて反映しやすくしてメンテコストを下げる、などの工夫がそれに該当します。

AWS CDK

ここまでは WordPress そのものを一貫した構成にするためのものを紹介してきました。しかし、実際に WordPress の開発・運用を統一化されたものにするためには、当然それを稼働させるインフラまで一貫したものにする必要があります。

KODANSHAtech では主に AWS を利用しているため、AWS CDK を使ってこれを実現しています。

AWS CDK の正式名称は AWS Cloud Development Kit で、宣言型 IaC によってリソースを構成することができます。これによって、ECS, RDS, EFS といった、私たちが WordPress を構築するのに欠かせないインフラリソースも、プロダクトコードと同様にバージョン管理しながら開発フローに乗せることが可能になり、また、その高い再利用性を活かしてリソース状態を一貫性のあるものにしやすくなります。

また、KODANSHAtech では AWS Security Hub を採用してリソースのベストプラクティスを志向しているのですが、そのベストプラクティスに適合する CDK のコードを使い回すことで、強く意識したり手動で個別対応しなくても、標準的な方法でベストプラクティスを実現することが可能です。

実際には、CDK を広く採用しはじめてからまだ日が浅いこともあって、すべての WordPress サイトを CDK で構築できているわけではないのですが、上記したように有効性は十分に理解できているので、新規案件を中心に少しずつ活用範囲を広げているところです。

おわりに

KODANSHAtech の WordPress 開発を支えている技術的な内容をごく簡単ですが紹介してきました。これ以外にも、共通処理をまとめてプラグイン化したものや PHPStan の導入など、他にも色々と紹介できそうなものもあります。また、WP REST API が進化してきたことによって、大きなエコシステムを持った Headless CMS として WordPress を使うことも可能になりました。実際に私たちが WordPress を利用するときは、ほとんどの場合はフロントエンドが独立した Headless CMS としての活用となっていて、日々その特有の知見を共有しながら開発しています。それらについても、またどこかで整理できたら改めて紹介できればと思います。

自分自身 Web サービスの開発を専門にしていたところから WordPress と向き合いはじめたので、どうにか Web サービスのプラクティスを持ち込めないかと試行錯誤する中で考えて作ってきたものです。私たちの開発は、純内製だけではなく外部のベンダーと協調して開発することもあるので、そのときに「オレオレスタイル」になりすぎないようにも注意を払いながら構成を考えていますが、まだ課題はいくつもあります。

これからも、関わる人間がよりハッピーになれる WordPress の開発・運用の「型」について考えて実践していきたいと思っています。