从 1Panel 初探 Docker：WordPress 部署逻辑与实践

把服务器管理工具迁到 1Panel 后，我第一次接触了基于 Docker 的应用部署。WordPress 仍然由网站文件、PHP 和数据库组成，但文件位置、OpenResty 的职责和配置生效方式都与传统部署不同。

文件路径与 OpenResty 的职责

在同一台服务器上，我同时管理着两种不同模式部署的 WordPress 站点，它们的差异是理解后续所有逻辑的基础。

传统部署（非容器化）：网站文件位于集中的 Web 根目录，例如 /opt/.../www/sites/。主机上的 Nginx 在 1Panel 中对应 OpenResty，它直接处理 Web 请求，配置文件中的 root 指向网站文件所在的物理路径。
容器化部署（1Panel 一键部署）：网站文件位于独立路径，如 /opt/1panel/apps/wordpress/你的网站名/data。主机上的 OpenResty 不再直接读取网站文件，而是通过 proxy_pass 把 Web 请求转发给 WordPress 容器。

所以容器化站点的 OpenResty 配置中，即使 root 指向的目录几乎为空也不影响访问，因为请求实际由后面的容器处理。

在 1Panel 的 WordPress 部署中，docker-compose.yml 指定使用哪个镜像创建容器，并将主机上的 /data 目录挂载到容器内部。主题、插件、上传文件和 wp-config.php 因此不会随着容器重建而丢失。

直接在后台更新：这会修改数据卷中的核心文件，使运行代码与镜像版本不一致，之后排查和回滚会更麻烦。
正确做法：
1. 编辑应用的 docker-compose.yml 文件。
2. 修改 image: 标签，例如从 wordpress:6.8.2 改为 wordpress:6.9.0。
3. 在 1Panel 中对该应用执行“重建（Rebuild）”。

“重建”会销毁基于旧镜像的容器，并基于新镜像创建一个全新的容器，然后将包含用户数据的旧数据卷重新挂载到新容器上。这个过程实现了核心程序的原子化、无污染更新，并保留了“一键回滚”（将版本号改回去再重建）的能力。

插件和主题属于用户数据，仍可在 WordPress 后台更新。

PHP 参数也通过挂载的配置文件修改。1Panel 的 WordPress 应用模板会在 docker-compose.yml 中设置配置文件挂载，例如把主机上的 ./conf/uploads.ini 挂载到容器内部。

因此，正确的修改流程是：

即使在 uploads.ini 中放宽了 PHP 的上传限制，大文件仍可能上传失败。上传请求至少经过主机上的 OpenResty 和容器内的 PHP，两处限制都要检查。在 1Panel 的“网站 > 配置文件”中，可以为对应站点添加 client_max_body_size 128m;。

上传进度走了一段时间后连接中断，可能是 OpenResty 等待后端容器响应超时。可以在站点配置中检查并按需设置 proxy_connect_timeout 300;、proxy_send_timeout 300; 和 proxy_read_timeout 300;。

修改主机上的站点配置后，需要重启 openresty 应用使配置生效，无须重建 WordPress 应用。

原笔记由 Gemini 2.5 Pro 整理、构建。