用 Docker 部署 WordPress:compose 文件、数据卷备份与升级(2026)
摘要:用 Docker Compose 跑 WordPress,关键不是「能打开安装页」,而是数据库和上传文件存在哪个 volume、升级镜像时会不会丢数据、docker compose down -v 会删掉什么。本文对照 Docker 官方 WordPress 样例、Compose 文档与 Volumes 备份命令,给出一份可照着做的清单。查询日期 2026-10-09。
依据:Docker 官方文档 WordPress samples、Volumes、docker compose up、docker compose down,Docker Hub
wordpress官方镜像,以及 docker/awesome-composewordpress-mysql样例。查询日期:2026-10-09(北京时间)。规则与镜像标签会变,以官网最新说明为准;本文只放官网普通链接,以后若接云厂商联盟再补(affiliate_later)。
程序旅途 2017 年写过「WordPress 迁到 Docker」的过程记录;本站已有轻量应用服务器搭 WordPress和搬家到新服务器。这篇只补一条线:Compose 文件怎么组织、命名数据卷怎么备份、升级镜像时怎样避免误删库。
最小结构:两个服务 + 一个(或两个)命名卷
Docker Hub 官方 wordpress 镜像文档给的 compose.yaml 典型形态是:wordpress 服务 + db(MySQL)服务,并用 named volumes 分别挂网站目录和数据库目录。

awesome-compose 的 wordpress-mysql 样例更偏向 MariaDB(方便 AMD64/ARM64),数据库卷名常写成 db_data,WordPress 侧有时只暴露 80 端口、把上传文件留在容器可写层——生产环境更稳妥的做法是:数据库一定用命名卷;wp-content(至少 uploads)也挂卷或绑定宿主机目录,否则一删容器就丢媒体文件。

样例里的密码是演示用的 somewordpress / examplepass。上线前请改成强密码,并用环境变量文件或密钥管理注入,不要把真实密码提交到 Git。
启动:
docker compose up -d
按 awesome-compose README,浏览器打开映射端口(样例常见 http://localhost 或 Hub 示例的 8080)进入 WordPress 安装向导。国内云主机还要处理安全组放行、域名解析与(若在内地)ICP 备案;解析概念见域名解析入门。
升级镜像时:Compose 会重建容器,但默认保留卷
docker compose up 文档写明:若服务配置或镜像变了,Compose 会停掉并重建容器,同时 preserving mounted volumes(保留已挂载的卷)。不想因配置变化自动重建,可用 --no-recreate;要强制全量重建用 --force-recreate。

实操建议:
- 先备份(下一节),再改
image:标签或执行docker compose pull && docker compose up -d。 - 大版本跨越(例如 MySQL 8.0 → 更高主版本、或 PHP 大版本)先在另一台机器或另一套 compose 项目名上恢复备份试跑,再切流量。
- WordPress 核心/插件更新仍可在容器内的后台进行;镜像升级主要解决 PHP/基础镜像补丁。
- 改端口、环境变量后若站点 URL 变了,按本站搬家文里的「改 Site URL」注意序列化替换,不要对数据库裸
sed。
备份命名卷:官方推荐的 --volumes-from 打 tar
Docker《Volumes》文档「Back up, restore, or migrate data volumes」给出的模式是:再起一个临时容器,用 --volumes-from 挂上数据库容器的卷,把目录打成 backup.tar。

对应到 WordPress 栈,至少两类数据要进备份计划(与网站定期备份方案同一思路):
| 数据 | 常见挂载点 | 丢了会怎样 |
|---|---|---|
| 数据库卷 | /var/lib/mysql(MySQL/MariaDB) | 文章、用户、设置全没 |
| 网站文件卷 | /var/www/html 或至少 wp-content | 主题、插件、上传图片没 |
示意(容器名、卷路径按你 docker compose ps / docker volume ls 的实际名称替换):
# 假设数据库服务容器名是 mywp-db-1
docker run --rm --volumes-from mywp-db-1 -v "$(pwd)":/backup ubuntu \
tar cvf /backup/db-data-$(date +%F).tar /var/lib/mysql
有网站文件卷时,对 /var/www/html 再打一份。备份文件离开这台机器(对象存储/另一台机),并定期做恢复演练:新目录 docker compose up 后按文档「Restore volume from a backup」把 tar 解开到空卷。云厂商对象存储做备份落点可参考对象存储做图床里的权限与防误删思路(备份桶请关掉公开读)。
最危险的一条命令:docker compose down -v
awesome-compose README 写得很清楚:普通 docker compose down 停掉并删除容器;若要连 WordPress 数据一起删,才加 -v 删命名卷。

Compose CLI 文档里,--volumes / -v 的含义就是移除 Compose 文件声明的命名卷。手滑在生产机执行,等于库和文件卷一起清空。

习惯建议:
- 日常停服务:只用
docker compose stop或docker compose down(不加-v)。 - 脚本里永远不要把
-v写进「重启」别名。 - 真要销毁测试环境:先确认项目目录、再确认
docker volume ls里的名字,最后才down -v。
上线前清单(和「能打开安装页」不是一回事)
compose.yaml里数据库、(建议)wp-content都用了命名卷或明确的 bind mount。- 密码不进仓库;
.env权限收紧。 - 只暴露需要的端口;SSH/防火墙基线见新服务器安全基线。
- 备份脚本已跑通,且在另一路径成功恢复过一次。
- 升级镜像前先备份;理解
up会重建容器但默认留卷,down -v会删卷。 - 内地机备案、解析、HTTPS;海外机注意访问与合规。机器选型见ECS 和轻量怎么选,到期保留期见云服务器到期不续费会怎样。
- 需要图形化面板时再评估宝塔等工具的利弊(见宝塔面板要不要装),与 Docker 方案不要混成「两套都半吊子」。
相关阅读
来源(查询 2026-10-09):docs.docker.com WordPress samples / Volumes / compose up / compose down;hub.docker.com/_/wordpress;github.com/docker/awesome-compose/wordpress-mysql。镜像标签与路径以你拉取时的官方页面为准。