Caddy で WordPress をホストする Docker Compose

Docker Compose を練習するのに WordPress サイトをローカルに立ててみるのはだれでもやったことあるんじゃないだろうか。これはリバースプロキシとなるウェブサーバー、PHPのCGI(WordPress)、データベースと複数のコンテナが連携するので Docker Compose の練習にはうってつけだと思う。

ちょっと前まではリバースプロキシに Nginx を使うのが定石だったが、さいきんは Caddy というさらに簡単に使える万能ウェブサーバーが出てきて、これを使いたいという人も多いと思う。

Caddy は公開で立てると TLS 証明書の更新まで自動でやってくれるらしいので実用でもなかなかよさそう。Nginx では Let’s Encrypt の更新をスクリプトでなんとか自動化するみたいなことをしていたが、そんなこと人間が手動でがんばることなかったのだ。

そんなわけで私も練習に Caddy + WordPress (+ MariaDB) で立ちあがる Docker Compose ファイルを作ってみました。FastCGI で動かすとかするとけっこう頭使うところもあったので覚え書きも兼ねている。また、localhost で TLS 証明書を使いたいときの参考にもなるかもしれない。

emptypage / wordpress-compose — Bitbucket

ウェブアプリ開発をローカルでやるかコンテナでやるか

VSCode で Python ウェブアプリケーションを開発するとき、コンテナの活用という視点で見るとつぎのように分類できる。

ローカルで開発、デバッグ

古典的なやりかた。プロジェクトをチェックアウトして、venv を作ってコードを書く。デバッグ(実行)するときもローカルのマシンで venv の Python で動かして確認する。いちばんなじみがある。

ローカルで開発、コンテナでデバッグ

VSCode ではデバッグ時にコンテナでプロジェクトを走らせることができる。ウェブアプリなんて作ったらどうせ(?) Dockerfile 書いてコンテナで動かすんだからはじめからコンテナで動作確認したほうがいい。後述の Dev Container が出るまでは有力な選択肢だった。

コンテナで開発、デバッグ

Dev Container ができて、最初から実行環境に近いコンテナでぜんぶ開発できるようになった。コンテナの中でローカルのように開発、デバッグできる。VSCode すごい。

Dev Container 開発の利点は、“What’s a devContainer and what is it good for?” (2023) という記事で次のような点が挙げられている。

  • 必要な開発環境をすぐに用意できる(依存ライブラリのインストールなどをあらかじめ揃えておける)。
  • 開発環境のバージョンを固定化できる。手元のマシンでは最新版にアップデートしたランタイムが後方互換性を失っているときなどでも以前のバージョンで開発を再開できる。
  • データベースなど連携するコンポーネントもコンテナに含めてしまうことで、実環境の変更の影響が開発環境に及ばないようにできる。開発者は各自自分のコンテナでの DB との接続性を保ったまま開発に集中できる。

で、ここではじつは開発環境が実行環境に近いということはとくに謳っていないのだが、たとえばプロジェクトで利用しているあるライブラリが Linux のみ対応だったり、Windows / macOS では挙動が違ったり、ディレクトリ構成が異なることで面倒な対応が必要だったりというのはありがちな話なので、そういうことから解放されるのはけっこう大きいメリットではないかと思う。