很多站长第一次接触 Docker Compose 时会困惑：为什么有了 Docker 还要再装一个 Compose？这其实是一个容器（container）与编排（orchestration）的关系问题。Docker 只负责运行单个容器，而 WordPress 站点至少要同时跑 WordPress 应用、MySQL（数据库）、Nginx（Web 服务器）三个程序，如果手动一个个启动并配置网络，既容易漏掉依赖，也难以重复部署。这篇文章会用一次完整的实战带你走通从环境准备到 HTTPS 上线的全过程，让 WordPress 容器化部署变得可重复、可维护，而不是靠记忆敲一条条命令。如果你是第一次用容器跑站点，可以先阅读这篇 Docker WordPress 容器搭建指南 了解单容器的基础写法。
一、环境准备：确认 Docker 与 Compose 都已就绪
部署前先确认服务器上已经安装 Docker 和 Docker Compose 插件。现代发行版通常把 Compose 集成进了 Docker CLI，命令是 docker compose（新版）而不是旧的 docker-compose。下面三步可以快速自检：
在终端依次执行，看到版本号就说明就绪：
docker --version
docker compose version
如果你用的是已经预装 Docker 的云主机方案（如 Hostease 的 VPS 主机（VPS，即虚拟专用服务器，是划分出的独立运行环境）），通常只需补充安装 Compose 插件。若确认缺失，可以用系统包管理器安装，例如 Debian/Ubuntu：
sudo apt-get update
sudo apt-get install -y docker-compose-plugin
安装好后建议把当前用户加入 docker 组，避免每条命令都要加 sudo：
sudo usermod -aG docker "$USER"
newgrp docker
这部分验证属于常见的 服务器初始化检查清单 里的基础项，提前做能省下后面排错的时间。
二、编写 docker-compose.yml：一次定义三个容器
进入项目的部署目录，创建一个 docker-compose.yml。Compose 用声明式配置把 WordPress、MySQL、Nginx 三个服务的镜像、端口、数据卷和依赖关系一次性写清楚。以下是经过实际验证的最小可用配置：
services:
db:
image: mysql:8.0
container_name: wp_db
restart: always
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wp_user
MYSQL_PASSWORD: "choose_a_strong_password"
MYSQL_ROOT_PASSWORD: "another_strong_root_password"
volumes:
- db_data:/var/lib/mysql
wordpress:
image: wordpress:6
container_name: wp_app
restart: always
depends_on:
- db
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wp_user
WORDPRESS_DB_PASSWORD: "choose_a_strong_password"
WORDPRESS_DB_NAME: wordpress
volumes:
- wp_data:/var/www/html
nginx:
image: nginx:1.27
container_name: wp_nginx
restart: always
ports:
- "80:80"
- "443:443"
volumes:
- wp_data:/var/www/html
- ./nginx/conf.d:/etc/nginx/conf.d:ro
volumes:
db_data:
wp_data:
配置里有三个值得留意的细节。第一，wordpress 和 nginx 通过同一个命名卷 wp_data 共享站点代码，这样 Nginx 才能直接读取 WordPress 吐出的 PHP 文件。第二，depends_on 保证数据库先启动，避免 WordPress 容器在 MySQL 还没就绪时报连接错误。第三，数据库口令通过环境变量注入，而不是写死在代码里，换环境时改配置即可，不需要动镜像。
三、配 Nginx 反向代理，让 WordPress 与 PHP 正常对接
WordPress 容器默认内置的 web 服务只监听容器内部端口，并不会自动暴露到主机。为了让外网通过 Nginx 访问，需要把 Nginx 作为反向代理，把 / 的请求转发给 WordPress 容器。先建目录并写入配置文件：
mkdir -p nginx/conf.d
cat > nginx/conf.d/default.conf <<'EOF'
server {
listen 80;
server_name _;
location / {
proxy_pass http://wordpress:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
EOF
关键点在于 proxy_pass http://wordpress:80 这一行：Compose 会自动为服务名 wordpress 生成内部 DNS 记录，容器之间用服务名互访，而不需要关心具体的容器 IP。如果你已经有一台在用 Nginx 的主机，想复用现成的转发规则，可以参考这篇 Nginx 部署实操，把代理段替换成上面这段即可。
四、启动容器并验证站点可访问
配置写完，回到 docker-compose.yml 所在目录，一次拉起三个服务：
docker compose up -d
docker compose ps
-d 让容器在后台运行，ps 用来确认三个服务的状态都是 running。第一次启动要拉取镜像，如果网络较慢需要耐心等待一两分钟。启动后，在浏览器访问服务器公网 IP，应该能看到 WordPress 的安装页（选择语言的界面）。如果页面迟迟打不开，用下面命令看日志定位问题：
docker compose logs -f wordpress
最常见的失败原因是 WordPress 容器启动早于 MySQL 就绪。除了 depends_on，还可以在 WordPress 服务上叠加一个健康检查脚本，等待数据库端口能连上再真正开始接受请求。排障过程中如果遇到 Nginx 层面的转发或并发问题，这篇 Nginx 并发排障指南 列举了几类高频诱因，能帮你快速缩小范围。
五、加上 HTTPS，别让站点裸奔在 HTTP
站点能访问只是第一步，浏览器地址栏出现”不安全”会明显损害访客信任，也会拖累搜索排名。给 Docker 里的站点上 HTTPS，最省事的方式是用 Let’s Encrypt 证书配合自动续期。这里采用一种常用的容器化做法：先用刚才的 HTTP 配置验证站点，再让证书签发工具去申请证书。
如果你的域名已经解析到服务器 IP（也就是让 DNS，域名系统，把域名指向这台服务器），可以先在 nginx/conf.d 里配置好 server_name，再执行签发命令换取证书。签发完成后，把 Nginx 配置改成 443 端口 + 证书路径 + 80 端口 301 跳转。如果签发过程报错，这篇 certbot 排障指南 整理了域名解析、防火墙放行、端口占用三类最常见的失败原因，逐条对照能少走弯路。
完成 HTTPS 后，还有两件事值得做：打开 WordPress 后台的”设置”里把站点地址改成 https，以及在 Nginx 配置里显式转发 X-Forwarded-Proto，否则 WordPress 会误判协议导致图片和资源链接仍是 HTTP。
六、数据持久化与备份，别让数据跟着容器一起消失
容器是易碎品，删除容器不等于删除数据，前提是你把数据放进了命名卷。上面配置里的 db_data 和 wp_data 正是干这件事的，容器重建后数据仍在卷里。但命名卷也存在同一个宿主机或同一块磁盘上，主机出问题就全没了，因此定期的异地备份必须补上。
一个实用的做法是配合 cron 定时把数据库导出成 SQL 文件，再同步到对象存储。数据库导出可以这样执行：
docker compose exec -T db mysqldump -uwp_user -p"choose_a_strong_password" wordpress > wp_backup_$(date +%F).sql
备份策略怎么定、保留几份、多久验证一次恢复，可以整体参照这篇 321 备份策略指南，把容器环境下的数据库和上传目录都纳入同一套备份体系，避免只备份了代码却漏掉数据库这种常见疏漏。
七、总结与行动建议
到这一步，你已经用 Docker Compose 完成了一套可复用的 WordPress 容器部署：三个服务由一个 docker-compose.yml 声明，Nginx 负责对外代理，命名卷保证数据不随容器消失，HTTPS 和备份兜底了上线后的安全与数据风险。比起传统在裸机上手动安装 LAMP 环境，这套方案的最大价值是”一处定义、处处可复现”——换一台新 VPS 主机 时，把配置文件和备份恢复过去即可快速重建，不用重新回忆每一步安装过程。
如果你需要更稳妥的线上运维，可以考虑把上面的 docker-compose.yml 纳入版本库，配合 CI/CD 在提交后自动重建；同时把 WordPress 的 PHP-FPM 调优也纳入部署检查，例如这篇 WordPress 环境里的 PHP-FPM 实操 提到的进程数、超时时间与慢日志配置。最后建议你为线上站点设置资源告警，磁盘、内存和数据库连接数到达阈值时能第一时间收到通知，再配合定期恢复演练，这样一套容器化 WordPress 才能真正稳定地跑在业务上。