WordPress 運用・開発・トラブルシューティングガイド

このドキュメントでは、Docker Infrastructure課題における WordPress のデータ管理、初期化ミス時の対応、および将来的な運用・開発フローの考え方についてまとめます。

1. 設定ミス時の対処（データが更新されない問題）

現象

.env ファイルで WP_ADMIN_USER やパスワードを変更して make re (再ビルド) しても、WordPress のログイン情報が古いまま変わらない。

原因

データの永続化（ボリューム） が機能しているためです。 Dockerコンテナを再作成しても、ホスト側の /home/${USER}/data/wordpress や /home/${USER}/data/mariadb に保存されたデータベースの実体ファイルは残ったまま再利用されます。 WordPressの初期セットアップスクリプトは「既に設定済み（wp-config.phpがあるなど）」と判断すると、インストール処理をスキップします。

対処法：データの完全リセット

初期構築段階（開発中）での設定ミスであれば、データを一度捨てて作り直すのが最も確実で早いです。

# 1. コンテナとボリューム（データ）を全て削除
make clean

# 2. 正しい設定で再構築
make all

make clean は docker compose down --volumes を実行し、Docker管理下のボリュームを削除します。 ※ ただし、本プロジェクトではホスト側のディレクトリをバインドマウントしているため、make clean だけでは消えない場合があります（Makefileの記述によります）。その場合は手動削除が必要です：

# データディレクトリの中身を空にする（管理者権限が必要な場合あり）
sudo rm -rf /home/${USER}/data/wordpress/*
sudo rm -rf /home/${USER}/data/mariadb/*

make all

2. データの「破棄」と「修正」の判断基準

初期化ミスが起きた際、データを捨てるべきか、修正して使い続けるべきかの判断フローです。

A. 破棄して再インストールすべきケース

• フェーズ: プロジェクトの初期セットアップ中、学習中。
• 状況:
  • 重要な記事データなどがまだ何もない。
  • 管理者ユーザー名 (admin 禁止など) や、WebサイトのURL設定など、根本的な設定を間違えた。
  • データベースの文字コード設定などを間違えた。
• 理由: 無理に修正パッチを当てるより、クリーンな環境で正しい手順を確立する方が「再現性」が高まるため。

B. データを温存して修正すべきケース

• フェーズ: 本番運用中、あるいはデータ入力が進んだ開発後半。
• 状況:
  • 記事を100件書いた後に、管理者パスワードだけ変えたい。
  • 「サイトのタイトル」だけ変えたい。
• 方法:
  • WP-CLI: docker exec -it wordpress wp user update ... コマンドで修正する。
  • 管理画面: ログインして GUI で変更する。
  • SQL: 直接DBを操作する（最終手段）。

3. WordPress開発・運用の実践的アプローチ

ローカル開発環境（Docker Infrastructure）と、実際の本番環境（デプロイ先）を考慮したワークフローの考え方です。

開発スタイルとデータ同期

パターン1: ローカルを「正（マスター）」とする

個人ブログなど小規模な場合。

1. ローカル（Docker）で記事を書く、デザインを変える。
2. 完成したら、プラグイン（All-in-One WP Migration等）を使ってデータをエクスポート。
3. 本番サーバーにインポート。

パターン2: コードとコンテンツの分離（推奨）

より実践的・チーム開発的なアプローチ。

• コード（テーマ、プラグイン）: Git で管理。ローカルで開発し、GitHub経由で本番にデプロイ。
• コンテンツ（記事、画像、DB）: 本番環境が「正」。
  • 開発時は本番からデータをダンプしてローカルに取り込む（wp db export / import）。
  • ローカルで作った「テスト記事」は本番には反映させない（破棄する）。
  • 理由: 本番でユーザーがコメントしたり記事が増えている間に、ローカルで古いデータをいじって上書きすると、本番の新規データが消えてしまうため。

SSL証明書の移行（自己署名 vs 正規）

Docker Infrastructureでは openssl で自己署名証明書を作りましたが、本番公開時はアプローチを変えます。

1. 開発環境 (Docker Infrastructure):

   • 自己署名証明書を使用。
   • ブラウザの警告は「無視」して進める。
   • 目的: HTTPS通信の構成（Nginxの設定、443ポート動作）を確認するため。

2. 本番環境 (Deploy):

   • Let's Encrypt などの無料認証局、または有料の認証局を使用する。
   • Docker構成としては、certbot コンテナを追加して証明書の自動更新を行わせるのが一般的。
   • あるいは、手前に AWS ALB や Cloudflare などのロードバランサを置き、そこでSSL終端（Offloading）を行い、コンテナへはHTTPで流す構成も多い（管理が楽なため）。

4. まとめ: 今回のケース（Docker Infrastructure）では？

「データを破棄して再作成 (make clean + ディレクトリ削除)」を推奨します。

• 理由: Docker Infrastructureは「インフラ自動構築の課題」だからです。
• 「あとから手動で直した」状態は、もし明日VMが消えたら再現できません。
• 「設定ファイル(.env)さえ修正すれば、コマンド一発で正しい環境が立ち上がる」状態を目指すべきです。

5. トラブルシューティング: データ削除時の「Permission denied」対策

校舎環境などでホストOSの root 権限がない場合、make clean や rm -rf でデータを消そうとしても「許可がありません」と怒られることがあります。

原因

コンテナ内（Linux）で作成されたファイルは、ホストOS側でも「所有者」が維持されることがあります。多くの場合、DBやWordPressは内部で root や特定のユーザー権限でファイルを作るため、ホスト側の一般ユーザー（学生）には削除権限がない状態になります。

解決策: Dockerを使って消す（毒をもって毒を制す）

権限がないなら、権限を持てる Docker コンテナ自身 に消させれば解決します。 以下のコマンドを実行してください。

# Dockerコンテナ(Alpine)を使い、ボリュームディレクトリをマウントして強制削除する
docker run --rm -v /home/${USER}/data:/data alpine rm -rf /data/mariadb /data/wordpress

• --rm: 使い終わったらこの削除用コンテナを自動で消す。
• -v ...: ホストのデータディレクトリを、コンテナ内の /data に繋ぐ。
• alpine: 軽量なLinuxイメージ。
• rm -rf ...: コンテナ内の root権限 で強制削除を実行。

この手法は、sudo権限がない環境での「開発者の知恵（ワークアラウンド）」として非常に有効です。