一、部署模式的核心差异：文件路径与Nginx角色#

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

• 传统部署（非容器化）：网站文件位于一个集中的Web根目录，例如/opt/.../www/sites/。主机上的Nginx（1Panel中为OpenResty）直接负责处理Web请求，其配置文件中的root指令明确指向网站文件所在的物理路径。
• 容器化部署（1Panel一键部署）：网站文件被隔离在独立的路径下，如/opt/1panel/apps/wordpress/你的网站名/data。主机Nginx的角色发生了根本性转变，它不再直接访问网站文件，而是充当反向代理 (Reverse Proxy)。其配置文件中最核心的指令是proxy_pass，作用是将收到的Web请求转发给在特定端口上监听的WordPress容器。

这个角色的转变解释了为什么容器化站点的Nginx配置中，root指令指向的目录几乎为空——因为它并不需要处理文件，只负责转发。

二、Docker核心概念：镜像、容器与数据持久化#

为了有效管理容器化应用，理解以下三个核心概念至关重要。

1. 镜像 (Image)：一个只读的应用模板。例如，wordpress:6.9.0镜像包含了运行WordPress 6.9.0所需的所有环境和程序文件，如特定版本的PHP和WordPress核心代码。它是静态的、标准化的。

2. 容器 (Container)：镜像的一个运行实例。它是动态的，可以被启动、停止和销毁。容器本身是无状态的，其内部环境的任何非持久化修改都会在容器被销毁后丢失。

3. 数据卷 (Volume) / 目录挂载 (Bind Mount)：实现数据持久化的关键机制。它将主机上的一个目录（如/data）“映射”或“挂载”到容器内部的一个目录（如/var/www/html）上。所有对容器内这个目录的读写操作，都会被实际作用于主机上的对应目录。

这三者的关系构成了容器化部署的基石。在1Panel的WordPress部署中，docker-compose.yml文件定义了这种关系：它指定了使用哪个镜像来创建容器，并将主机上的/data目录挂载到容器内部，从而确保了用户数据（如主题、插件、上传文件和wp-config.php）的持久化。

三、应用生命周期管理：升级与配置#

容器化的管理哲学与传统模式截然不同，尤其体现在应用升级和配置修改上。

1. WordPress核心升级：镜像替换而非文件覆盖

• 错误做法：在WordPress后台点击“更新”。这会直接修改数据卷中的核心文件，导致运行中的代码与容器定义（镜像版本）不一致，产生“状态漂移”，破坏了容器的不可变性，使回滚变得极为困难。
• 正确做法：
  1. 编辑应用的 docker-compose.yml 文件。
  2. 修改image:标签，将其指向新的WordPress版本，例如从wordpress:6.8.2改为wordpress:6.9.0。
  3. 在1Panel中对该应用执行“重建 (Rebuild)”操作。

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

注意：插件和主题的管理不在此列，它们属于用户数据，应继续在WordPress后台进行更新。

2. 配置修改：通过数据卷挂载而非直接修改

对于PHP参数（如upload_max_filesize）的修改，同样遵循数据卷的逻辑。1Panel的WordPress应用模板已经预先在docker-compose.yml中设置好了配置文件的挂载，例如将主机上的./conf/uploads.ini文件挂载到容器内部。

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

1. 在主机上编辑./conf/uploads.ini文件。
2. 对应用执行“重建”操作，使新配置被新创建的容器加载。

四、运维实践与问题排查#

1. 上传大文件失败：排查全链路限制

• 问题：即使在PHP配置中（如uploads.ini）已放宽上传大小限制，上传大文件（如>1MB的主题）依然失败。
• 分析：一个上传请求的链路至少包含“主机反向代理Nginx”和“应用容器PHP”两环。主机Nginx有一个独立的请求体大小限制client_max_body_size，其默认值通常为1m，这成为了瓶颈。
• 解决：在1Panel的“网站”->“配置文件”中，为对应站点的主机Nginx配置添加client_max_body_size 128m;。

2. 请求超时：延长代理等待时间

• 问题：上传大文件时，进度条走一段时间后连接中断。
• 分析：这通常是主机Nginx作为反向代理等待后端容器响应的超时。默认的超时时间（如60秒）不足以完成大文件的上传和处理流程。
• 解决：在主机Nginx的站点配置文件中，添加代理超时参数，如proxy_connect_timeout 300;、proxy_send_timeout 300;和proxy_read_timeout 300;。

重要提示：在修改完主机Nginx（即openresty应用）的任何站点配置后，需要重启openresty应用本身，而不是重建WordPress应用，才能使新配置生效。

总结#

从传统运维转向容器化，核心是思想的转变：从管理一台服务器上的“软件”，转变为通过配置文件“定义”一个个独立的、可预测的、可复现的“应用”。这个过程需要我们放弃直接修改运行环境的习惯，转而拥抱通过编排文件和重建来管理应用生命周期的模式。虽然初见时有学习曲线，但其带来的稳定性、一致性和运维效率的提升是巨大的。

笔记由Gemini 2.5pro整理、构建