2026年7月3日
2026年7月3日
DockerでWordPressを動かす方法|公式イメージとComposeで作る最小構成と、つまずきやすい点
DockerでWordPressを動かすには、公式の wordpress イメージとMySQL(またはMariaDB)のイメージを、Docker Composeで1つのファイルにまとめて起動するのがいちばん手早い方法です。compose.yaml と .env の2ファイルを用意すれば、docker compose up -d でインストール画面まで進めます。この記事では、その最小構成を作ったうえで、公式イメージが wp-config.php をどう扱うか、データがどこに残るか、URLやアップロード上限・ファイル権限でつまずいたときの直し方、WP-CLIの使い方までを説明します。
想定しているのは、テーマやプラグインの開発、検証用の環境づくりです。前提はDocker EngineとDocker Compose v2(docker compose コマンド)で、Docker Desktopでも同じ手順で動きます(2026年10月現在)。
用意するファイル
作業用のディレクトリを作り、まずパスワードを書いた .env を用意します。このファイルはGitに含めないよう .gitignore に追加してください。
# .env(値は自分で決めた長いランダム文字列に置き換える)
DB_PASSWORD=change-this-db-password
DB_ROOT_PASSWORD=change-this-root-password
次に compose.yaml です。
services:
db:
image: mysql:8.4
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: ${DB_PASSWORD}
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
volumes:
- db-data:/var/lib/mysql
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "--silent"]
interval: 10s
timeout: 5s
retries: 10
start_period: 30s
restart: unless-stopped
wordpress:
image: wordpress:php8.3-apache
depends_on:
db:
condition: service_healthy
ports:
- "127.0.0.1:8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
volumes:
- wp-data:/var/www/html
restart: unless-stopped
volumes:
db-data:
wp-data:
構成のポイントは次のとおりです。
- **
WORDPRESS_DB_HOST: db**:Composeでは、同じファイル内のサービス名がそのままホスト名になります。localhostと書くとWordPressのコンテナ自身を指してしまい、「データベース接続確立エラー」になります。 - **
depends_onとhealthcheck**:MySQLは初回起動時の初期化に時間がかかります。DBが応答できる状態になってからWordPressを起動させることで、起動直後の接続エラーを避けます。 - タグの指定:
wordpress:php8.3-apacheのように、PHPのバージョンとWebサーバーを含むタグを選べます。どのタグがあるかはDocker Hubの公式wordpressページで確認し、latestに頼らず系列を固定しておくと再現性が上がります。 - **
127.0.0.1:8080:80**:自分のPCからだけ開けるようにしています。同じネットワークの別の端末から見たい場合だけ127.0.0.1:を外します。
起動とインストール
docker compose up -d
docker compose ps
docker compose logs -f wordpress
docker compose ps で両方のサービスが動いていて、dbが healthy になっていれば、ブラウザで http://localhost:8080/ を開きます。言語の選択とサイト情報の入力画面が出るので、通常のWordPressと同じようにインストールします。管理者のユーザー名には推測されやすい admin を避け、パスワードは画面が提案する強いものを使ってください。
公式イメージは wp-config.php をどう作るか
公式イメージは、/var/www/html が空の状態で起動すると、WordPress本体をそこにコピーし、wp-config.php も自動で作ります。このとき作られる wp-config.php は、DBの接続情報を毎回 WORDPRESS_DB_HOST などの環境変数から読む書き方になっています。そのため、compose.yaml の接続情報を変えたら docker compose up -d でコンテナを作り直せば反映されます(MySQL側のパスワードは初回にしか設定されないので、MySQLのユーザーのパスワードも合わせて変える必要があります)。
wp-config.php に定数を足したいときは、ファイルを直接編集するより、WORDPRESS_CONFIG_EXTRA という環境変数にPHPのコードを書く方法が使えます。
environment:
# 他の WORDPRESS_* 変数に加えて
WORDPRESS_DEBUG: "1"
WORDPRESS_CONFIG_EXTRA: |
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_EDIT', true );
WORDPRESS_DEBUG に "1" のような値を入れると WP_DEBUG が有効になります。開発用の設定なので、公開する環境では外してください。
データはどこに残るか
この構成では、データは2つの名前付きボリュームに残ります。
db-data:投稿や設定などのデータベースwp-data:WordPress本体、wp-content(テーマ・プラグイン・アップロード画像)
docker compose down でコンテナを消してもボリュームは残るので、up -d すれば元の状態に戻ります。一方、docker compose down -v はボリュームまで削除します。検証環境をまっさらにしたいとき以外は -v を付けないでください。
テーマやプラグインを開発する場合
自作のテーマをホストのエディタで編集したい場合は、そのディレクトリだけをバインドマウントします。WordPress全体(/var/www/html)をホストに出すより、本体の更新と自分のコードがはっきり分かれて扱いやすくなります。
volumes:
- wp-data:/var/www/html
- ./my-theme:/var/www/html/wp-content/themes/my-theme
よくあるつまずきと直し方
管理画面でFTPの接続情報を聞かれる
プラグインの追加や更新のときに「接続情報」としてFTPのホスト名などを聞かれるのは、WordPressがファイルを書き込めないときの動作です。公式イメージのApacheは www-data(UID 33)で動いているため、ホストからバインドマウントしたディレクトリの所有者が自分のユーザーのままだと書き込めません。名前付きボリュームを使っている部分では通常起きないので、まずバインドマウントしたディレクトリの所有者と権限を確認してください。
ポートを変えたらページが崩れる・リダイレクトされる
WordPressはインストール時のURL(例:http://localhost:8080)をデータベースの home と siteurl に保存します。あとからポートやホスト名を変えると、古いURLへ転送されたり、CSSが読み込まれなくなったりします。後述のWP-CLIで書き換えるか、WORDPRESS_CONFIG_EXTRA で WP_HOME と WP_SITEURL を定義して上書きします。
大きなファイルをアップロードできない
アップロードの上限はPHPの設定で決まります。公式イメージでは、/usr/local/etc/php/conf.d/ に .ini ファイルを置くと読み込まれます。
; uploads.ini
upload_max_filesize = 64M
post_max_size = 64M
volumes:
- wp-data:/var/www/html
- ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
post_max_size は upload_max_filesize 以上にしておきます。反映後、メディアの追加画面に表示される最大サイズが変わったかで確認できます。
メールが届かない
公式イメージにはメール送信の仕組み(MTA)が入っていないため、パスワードリセットなどのメールは送られません。開発環境では、Mailpitのようなメール受信テスト用のコンテナを追加し、SMTP送信のプラグインでそこに送ると、送信内容をブラウザで確認できます。
WP-CLIを使う
公式の wordpress:cli イメージを使うと、WP-CLIのコマンドをコンテナで実行できます。Composeに次のサービスを足します。
wpcli:
image: wordpress:cli
user: "33:33"
depends_on:
db:
condition: service_healthy
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
volumes:
- wp-data:/var/www/html
profiles: ["tools"]
docker compose run --rm wpcli wp plugin list
docker compose run --rm wpcli wp option update home 'http://localhost:8081'
docker compose run --rm wpcli wp option update siteurl 'http://localhost:8081'
docker compose run --rm wpcli wp db export /var/www/html/backup.sql
user: "33:33" を指定しているのは、cliイメージ(Alpineベース)とApache版イメージ(Debianベース)で www-data のUIDが異なるためです。指定しないと、WP-CLIで入れたプラグインのファイルをApacheが書き換えられない、といった権限のずれが起きます。profiles を付けたサービスは docker compose up では起動せず、run したときだけ動きます。環境変数は wp-config.php が接続情報を読むために必要です。
wp db export の出力先は wp-data ボリュームの中なので、作ったファイルは docker compose cp wordpress:/var/www/html/backup.sql ./ でホストに取り出し、ボリュームの中には残さないようにします。
公開サーバーで使う前に
この記事の構成は開発・検証向けです。インターネットに公開する場合は、少なくとも次の点を別途整える必要があります。
- HTTPS化(前段にリバースプロキシを置いて証明書を管理するのが一般的です。公式イメージの
wp-config.phpは、プロキシから渡されるX-Forwarded-Protoヘッダーを見てHTTPSと判定する処理を含んでいますが、版によって異なる可能性があるので確認してください) - データベースと
wp-contentの定期バックアップと、復元の確認 - イメージの定期的な更新と、WordPress本体・プラグインの更新手順
.envなどの秘密情報の管理
プラグインやテーマの開発だけが目的なら、Node.jsの @wordpress/env(wp-env)という、Dockerを使って開発環境を立ち上げるツールもあります。設定ファイルが少なく済むので、目的に合わせて選んでください。
まとめ
- 公式の
wordpressとmysqlイメージをComposeでまとめ、WORDPRESS_DB_HOSTにはDBのサービス名を書きます。 - DBのヘルスチェックと
depends_onで起動順を整えると、初回の接続エラーを避けられます。 - 公式イメージの
wp-config.phpは環境変数を読む作りで、定数の追加はWORDPRESS_CONFIG_EXTRAで行えます。 - データは名前付きボリュームに残ります。
docker compose down -vはデータごと消えるので注意します。 - 権限のずれ(UID 33)、保存されたURL、PHPのアップロード上限、メール送信が主なつまずきどころです。WP-CLIは
wordpress:cliイメージで使えます。