WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える

WordPress を Kubernetes 上で運用する場合、単に WordPress コンテナを起動するだけでは設計として不十分です。WordPress、Web サーバー、PHP、データベース、キャッシュ、永続化、メール、予約投稿、外部公開、WAF、バックアップを分けて考える必要があります。

この記事では、WordPress を Kubernetes で運用するときの構成要素と責務分離を整理します。細かい手順よりも、どの機能をどこに置くべきか、どこを確認すべきかを中心にします。

WordPress コンテナの責務を絞る

WordPress コンテナの主な役割は、PHP アプリケーションとして WordPress を動かすことです。ここにメール配送、DB、キャッシュ、証明書終端、WAF、バックアップまで同居させると、コンテナの責務が大きくなりすぎます。

Kubernetes で運用するなら、WordPress コンテナは CMS と PHP 実行環境に寄せ、周辺機能は別コンポーネントとして切り出す方が管理しやすいです。

永続化は wp-content と DB を分けて考える

WordPress の永続データは、大きく DB と wp-content に分かれます。DB には投稿や設定が入り、wp-content にはアップロードファイル、テーマ、プラグインなどが入ります。

Kubernetes では Pod は入れ替わる前提なので、これらをコンテナ内の一時領域に置いてはいけません。PersistentVolume、外部ストレージ、バックアップ対象を明確にします。

• wp-content/uploads を永続化する
• テーマやプラグインをどこまでイメージに含めるか決める
• DB のバックアップと wp-content のバックアップを分けて設計する
• 復元時に DB とファイルの整合性を考える
• 権限、UID、GID をコンテナとストレージで合わせる

メール送信は SMTP リレーへ分ける

WordPress からの通知メールを、WordPress コンテナ内の MTA で直接配送する構成は、運用が複雑になりがちです。Kubernetes では、SMTP リレーや外部メールサービスへ分離する方が自然です。

メール配送には、SMTP 認証、TLS、キュー、再送、DNS、SPF、DKIM、DMARC、ログ確認が関係します。これは CMS 本体の責務ではなく、メール基盤の責務として扱った方が切り分けやすくなります。

予約投稿と WP-Cron をどう扱うか

WordPress の予約投稿や一部の定期処理は WP-Cron に依存します。通常の WordPress ではアクセスを契機に WP-Cron が動くことがありますが、Kubernetes 運用ではアクセス任せにすると実行タイミングが不安定になる場合があります。

安定運用を考えるなら、WP-Cron を無効化し、Kubernetes の CronJob などから明示的に実行する構成も検討できます。

wp cron event list
wp cron event run --due-now

外部公開は Ingress だけで終わらない

Kubernetes では Ingress や Service で外部公開できますが、WordPress の公開設計はそれだけでは終わりません。TLS、リバースプロキシ、WAF、実クライアント IP、リダイレクト、パーマリンク、アップロードサイズなどを合わせて確認する必要があります。

• 外部 URL と WordPress のサイト URL が一致しているか
• TLS 終端位置がどこか
• リバースプロキシ配下で HTTPS 判定が正しいか
• WAF が REST API や投稿更新を誤検知していないか
• パーマリンクとサイトマップが正しく生成されるか
• アップロードサイズやタイムアウトが Web 層で制限されていないか

DualStack は WordPress より外側の設計問題

IPv4 / IPv6 DualStack で WordPress を公開する場合、WordPress 本体よりも、Kubernetes、Service、Ingress、リバースプロキシ、DNS、外部ネットワークの設計が重要になります。

WordPress は基本的に HTTP アプリケーションとして動きます。IPv6 対応の成否は、Pod、Service、Ingress、ロードバランサ、DNS、ファイアウォール、リバースプロキシで、IPv4 と IPv6 の経路が正しく成立しているかに依存します。

バックアップと復元を先に決める

WordPress を Kubernetes で運用する場合、バックアップは後から考えるものではありません。DB、wp-content、テーマ、プラグイン、広告 CSS、設定値、Ingress / Helm values など、復元に必要なものを分けて把握します。

特に重要なのは、バックアップを取ることではなく、復元できることです。DB だけ戻してもアップロードファイルがない、ファイルだけ戻しても DB と合わない、という状態では復元できたとは言えません。

確認コマンドの例

Kubernetes 側では、まず Pod、Service、PVC、Ingress の状態を確認します。名前空間は環境に合わせて変更します。

kubectl -n wordpress get pod
kubectl -n wordpress get svc
kubectl -n wordpress get pvc
kubectl -n wordpress get ingress

WordPress コンテナ内では、WP-CLI が使えると状態確認がかなり楽になります。

wp core version
wp option get siteurl
wp option get home
wp plugin list
wp cron event list

まとめ

WordPress を Kubernetes で運用する構成では、WordPress コンテナだけを見るのではなく、DB、永続化、キャッシュ、メール、予約投稿、外部公開、WAF、バックアップを分けて設計する必要があります。

Kubernetes は部品を分けて運用しやすい基盤ですが、責務分離を決めないまま載せると、かえって複雑になります。WordPress は CMS、MariaDB はデータ、Redis はキャッシュ、SMTP リレーはメール配送、リバースプロキシと WAF は外部公開と防御、というように役割を切ると、障害時の切り分けもしやすくなります。

関連記事

• Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
• コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
• WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する
• WordPress が wordpress.org に接続できない原因と切り分け方
• WordPress のメール送信が遅い原因 – sendmail、Postfix、名前解決を切り分ける
• WordPress で Google Analytics 4 を導入する理由 – アクセス解析を運用改善に使う

Related posts:

Kubernetes Nginx コンテナの実行 Kubernetes Nginx コンテナと Service ClusterIP Kubernetes Nginx コンテナと Service NodePort Kubernetes Nginx コンテナと Service LoadBalancer コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける CentOS 8 で WordPress を構築した記録 – 現在は Ubuntu / Kubernetes 構成へ読み替える WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する WordPress が wordpress.org に接続できない原因と切り分け方 Ubuntu 22.04 Kubernetes 管理ツールのインストール Kubernetes Harbor の導入 – Helm でコンテナレジストリを構築する Kubernetes クラスタの初期化 – kubeadm reset の基本 Kubernetes に Docker / Podman のような stop/start がない理由