【第6回】Docker Composeで独立したWordPress検証環境を作る

日常の開発環境と検証環境を分ける

前回までに構築したwordpress-dev.testは、テーマやプラグインを継続して開発するための環境です。

ソースコードをVisual Studio CodeとCodexで編集し、WordPress上ですぐに動作を確認できます。

この環境には、開発中のプラグイン、設定、投稿、画像、テストデータなどが蓄積されていきます。

そのため、配布用ZIPファイルを新しいWordPressへインストールした場合と、まったく同じ状態ではありません。

例えば、開発環境では正常に動いていても、次のような問題が配布後に発生する可能性があります。

• 配布用ZIPに必要なファイルが含まれていない
• 開発環境だけに存在するファイルへ依存している
• 以前のバージョンで保存された設定が残っている
• プラグインの有効化処理が新規環境で失敗する
• ファイルやディレクトリの名前が配布時に変わっている
• 不要な開発用ファイルがZIPに含まれている

このような問題を確認するには、日常の開発サイトとは別に、必要に応じて作り直せる検証環境を用意する方法が適しています。

Dockerとは

Dockerは、アプリケーションの実行に必要なソフトウェアや設定を、コンテナという単位で分離して動かすための仕組みです。

通常のUbuntuへApache、PHP、MariaDBなどを直接インストールする場合、それぞれがOS上のサービスとして動作します。

Dockerを利用する場合は、WordPressやMariaDBをコンテナとして起動し、ホスト側のUbuntuから分離して管理できます。

ホスト

Dockerを実行しているUbuntu本体です。

イメージ

コンテナを作成するためのひな型です。WordPressやMariaDBの公式イメージなどがあります。

コンテナ

イメージから作成され、実際に起動している実行環境です。

ボリューム

コンテナを停止または再作成しても保持したいデータを保存する仕組みです。

仮想マシンとは異なり、コンテナごとに完全なOSを起動するわけではありません。

比較的軽量で、必要な環境を短時間で起動、停止、再作成できる点が特徴です。

Docker Composeで複数のコンテナを管理する

WordPressを動かすためには、WordPress本体だけでなく、投稿や設定を保存するデータベースも必要です。

今回は、WordPressとMariaDBの二つのコンテナを組み合わせます。

複数のコンテナの構成をまとめて管理するため、Docker Composeを利用しました。

Docker Composeでは、使用するイメージ、接続するネットワーク、環境変数、データの保存先などを、一つの設定ファイルへ記述します。

同じ設定ファイルを利用すれば、環境を停止、削除した後でも、同じ構成を再び作成できます。

Dockerの動作を確認する

最初に、UbuntuでDockerとDocker Composeを利用できることを確認しました。

docker --version
docker compose version

Dockerのサービスが起動していることも確認します。

systemctl status docker

続いて、現在のユーザーがDockerを操作できることを確認しました。

docker ps

Dockerの操作では管理者権限が必要になる場合がありますが、毎回sudoを付けて実行する運用は避けました。

開発ユーザーをDockerグループへ追加することで、通常ユーザーとしてDockerを操作できます。

sudo usermod -aG docker studio317

グループの変更は、通常、いったんログアウトして再ログインした後に反映されます。

検証環境の保存場所を決める

Dockerの設定ファイルや検証用データは、日常のWordPress開発プロジェクトとは別の場所で管理することにしました。

今回のUbuntuには、開発データを保存するためのストレージを次の場所へマウントしています。

/mnt/studio317-data

その中に、Docker環境を管理するディレクトリを作成しました。

/mnt/studio317-data/development/docker

今回のWordPress検証環境は、次の場所に配置します。

/mnt/studio317-data/development/docker/wp-dev-check

ディレクトリ名のwp-dev-checkには、日常的な開発サイトではなく、WordPressやプラグインの状態を確認するための環境という意味を持たせています。

プロジェクトのソースコードを保存する場所と、Dockerの検証環境を保存する場所を分けることで、それぞれの目的を明確にできます。

Docker Composeの設定ファイルを作成する

Docker Composeの構成は、一般的にcompose.ymlというファイルへ記述します。

今回の基本構成は、次のようになります。

services:
  db:
    image: mariadb
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: example-password
      MARIADB_ROOT_PASSWORD: example-root-password
    volumes:
      - db_data:/var/lib/mysql

wordpress:
image: wordpress
depends_on:
- db
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: example-password
volumes:
- wordpress_data:/var/www/html

volumes:
db_data:
wordpress_data:

blogに掲載しているパスワードは説明用です。実際の環境では、推測されにくい値を使用します。

servicesには、起動するコンテナを定義します。

dbはMariaDB、wordpressはWordPressを表します。

サービス名は、同じDocker Compose環境内の接続先としても利用できます。

そのため、WordPressからデータベースへ接続するホスト名には、IPアドレスではなくdbを指定しています。

ポート番号を使って開発サイトへ接続する

DockerのWordPressコンテナ内では、Webサーバーが通常のHTTPポートである80番を使用します。

一方、Ubuntu本体では、すでにApacheが80番ポートを利用しています。

同じポートを複数のサービスで同時に使用することはできないため、Docker側には別のポート番号を割り当てました。

ports:
  - "8080:80"

左側の8080はUbuntu側、右側の80はコンテナ側のポート番号です。

この設定により、ブラウザから次のURLへアクセスすると、Docker内のWordPressが表示されます。

http://localhost:8080

日常の開発サイトはhttp://wordpress-dev.test、Dockerの検証サイトはhttp://localhost:8080となります。

データを保存するボリューム

コンテナは、削除して作り直せることが特徴です。

しかし、WordPressの投稿や設定、MariaDBのデータまで毎回消えてしまうと、継続した検証が難しくなります。

そこで、保持したいデータにはDockerのボリュームを使用します。

volumes:
  db_data:
  wordpress_data:

db_dataにはMariaDBのデータを、wordpress_dataにはWordPressのファイルを保存します。

コンテナを停止または再作成しても、ボリュームを削除しない限り、保存されたデータは残ります。

一方、完全にクリーンなWordPressへ戻したい場合は、コンテナとあわせてボリュームも削除します。

検証の目的によって、データを保持するのか、すべて初期化するのかを選択します。

環境変数と秘密情報を分ける

Docker Composeの設定には、データベースのパスワードなどが必要です。

これらをcompose.ymlへ直接記述すると、設定ファイルをGitへ追加した際に、秘密情報も記録される可能性があります。

そこで、実際のパスワードなどは.envファイルへ分離できます。

WORDPRESS_DB_NAME=wordpress
WORDPRESS_DB_USER=wordpress
WORDPRESS_DB_PASSWORD=安全なパスワード
MARIADB_ROOT_PASSWORD=安全な管理者パスワード

compose.ymlでは、変数を参照します。

environment:
  WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
  WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
  WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}

.envには秘密情報が含まれるため、Gitの管理対象から除外します。

.env

Dockerの検証環境であっても、パスワードやAPIキーをGitHubやChatGPTへ共有しない方針は変わりません。

Docker Composeで環境を起動する

設定ファイルを作成した後、対象のディレクトリへ移動します。

cd /mnt/studio317-data/development/docker/wp-dev-check

最初に、Docker Composeの設定内容に構文上の問題がないことを確認します。

docker compose config

問題がなければ、WordPressとMariaDBをバックグラウンドで起動します。

docker compose up -d

upは、設定に基づいてコンテナを作成し、起動するための操作です。

-dを付けると、ターミナルを占有せず、バックグラウンドで実行されます。

初回は、WordPressやMariaDBのイメージがUbuntuへダウンロードされます。

起動後、コンテナの状態を確認しました。

docker compose ps

WordPressとMariaDBが起動していることを確認した後、ブラウザからhttp://localhost:8080へアクセスします。

起動直後は少し時間が必要になる

docker compose up -dが正常に完了しても、その直後にWordPressを表示できるとは限りません。

MariaDBが初期データベースを作成し、接続を受け付けられる状態になるまで、少し時間が必要です。

WordPressも、MariaDBへ接続できるようになってから正常に動作します。

起動状態は、次のコマンドで確認できます。

docker compose ps
docker compose logs

特定のサービスだけを確認する場合は、サービス名を指定します。

docker compose logs db
docker compose logs wordpress

エラーが発生した場合は、ブラウザ上の表示だけで判断せず、コンテナの状態とログを確認します。

WordPressの初期設定を行う

ブラウザからDocker側のWordPressへ初めてアクセスすると、WordPressのインストール画面が表示されます。

言語、サイトタイトル、管理ユーザー、パスワード、メールアドレスなどを入力し、通常のWordPressと同じように初期設定を行います。

ただし、この環境は一般公開するWebサイトではなく、検証専用です。

検索エンジンによるインデックスを許可する必要はありません。

また、本番サイトと同じ管理者パスワードやメールアドレスを使用せず、検証環境専用の情報を設定します。

初期設定が完了した後、次の項目を確認しました。

• トップページを表示できること
• 管理画面へログインできること
• 投稿や固定ページを作成できること
• プラグイン画面を表示できること
• MariaDBへデータが保存されること
• コンテナを再起動しても設定が残ること

コンテナを停止する

検証を行わないときは、Docker Composeの環境を停止できます。

docker compose stop

stopはコンテナを停止しますが、コンテナ自体は残します。

再開する場合は、次のコマンドを使用します。

docker compose start

コンテナを停止して削除する場合は、downを使用します。

docker compose down

downを実行しても、通常は名前付きボリュームに保存したWordPressとMariaDBのデータは残ります。

そのため、再びdocker compose up -dを実行すると、以前のデータを利用して環境を再作成できます。

完全に初期化する場合の注意

配布用プラグインを、過去の設定が存在しないWordPressへ新規インストールして確認したい場合があります。

その場合は、コンテナだけでなく、WordPressとMariaDBのデータを保存しているボリュームも削除します。

docker compose down -v

-vを付けると、Docker Composeで作成した名前付きボリュームも削除されます。

WordPressの投稿、設定、ユーザー、インストール済みプラグイン、データベースの内容なども失われます。

元に戻すことはできないため、実行前に、削除する環境と保持したいデータがないことを必ず確認します。

通常の停止や再起動では-vを付けず、完全な初期状態が必要な場合だけ使用します。

開発中のソースコードを直接接続しない

Dockerでは、Ubuntu側のディレクトリをコンテナ内へマウントし、同じソースコードを直接利用することもできます。

これは、コードを編集するとすぐにコンテナ側へ反映できるため、日常的な開発には便利です。

しかし、今回の主な目的は、配布される状態に近いプラグインを独立したWordPressへインストールして確認することです。

開発中のリポジトリをそのまま接続すると、配布用ZIPに含まれていないファイルも利用できてしまいます。

その結果、実際の配布パッケージでは発生する問題を見逃す可能性があります。

このため、日常開発と配布パッケージの確認では、次のように使い分けます。

同じプラグインでも、確認する目的によって適切な環境が異なります。

Docker環境で確認する内容を限定する

独立した環境を用意すると、さまざまな検証を行いたくなります。

しかし、一度に多くの確認を始めると、問題が発生した原因や、どの時点の状態を検証しているのかが分かりにくくなります。

今回のDocker環境では、まず次の範囲を基本としました。

• WordPressとMariaDBが正常に起動すること
• WordPressを新規インストールできること
• 管理画面へログインできること
• 配布用プラグインをインストールできること
• プラグインを有効化できること
• 有効化時にPHPの致命的エラーが発生しないこと
• 基本画面を表示できること
• 停止と再作成を行えること
• 必要に応じて完全な初期状態へ戻せること

外部API、OAuth、メール送信、本番データとの接続などは、必要性と安全性を確認してから、別の目的として実施します。

検証環境が独立していても、外部サービスへ接続すれば、コンテナの外部へ影響を与える可能性があります。

ChatGPTとCodexの役割

Docker環境の構築でも、ChatGPT、Codex、人間の役割を分けました。

ChatGPT

日常開発環境と検証環境を分ける目的、Docker Composeの構成、データの保持方法、確認手順を整理します。

Codex

compose.ymlなどの設定ファイルを確認し、必要に応じて作成・修正します。また、コンテナの状態やログ、Git差分を確認します。

人間

Dockerグループへの追加、秘密情報の入力、ボリュームの削除、ブラウザ上の動作確認など、影響の大きい操作を判断して実行します。

特に、docker compose down -vのようにデータを削除する操作は、Codexへ自動的に実行させず、人間が対象環境を確認してから実施します。

AIへ操作を依頼する場合も、対象ディレクトリ、実行してよいコマンド、削除してはいけないデータを明確にします。

起動し直して状態を確認する

Docker環境は、作成した直後だけでなく、停止と再起動を行った後も正常に動作することを確認します。

今回は、次の操作を行いました。

cd /mnt/studio317-data/development/docker/wp-dev-check

docker compose down
docker compose up -d

起動後、コンテナが安定するまで待ち、状態を確認します。

docker compose ps
docker compose logs --tail=100

ブラウザからWordPressへアクセスし、以前に設定したサイト情報が残っていることも確認しました。

これにより、コンテナを再作成しても、ボリュームに保存したWordPressとMariaDBのデータが保持されることを確認できます。

今回の到達点

今回は、DockerとDocker Composeを利用して、日常のWordPress開発サイトとは独立した検証環境を作成しました。

WordPressとMariaDBを別々のコンテナとして起動し、ブラウザからhttp://localhost:8080へアクセスできる状態を整えました。

コンテナを停止、再開、削除、再作成する方法と、ボリュームによってWordPressとデータベースの情報を保持する仕組みも確認しました。

また、完全な初期状態へ戻す場合は、ボリュームの削除を伴うため、通常の再起動とは区別して慎重に実行する必要があることも分かりました。

これにより、日常の開発環境へ影響を与えずに、WordPressや配布用プラグインを確認するための基礎が整いました。