WordPress Docker 安全更新记录：PHP 8.3 漏洞修复实践
一、更新背景
近期关注到 PHP 相关的安全漏洞信息。由于个人网站使用 Docker 部署 WordPress，因此决定检查当前运行环境，并更新相关镜像，降低已知安全漏洞带来的风险。
本次更新主要围绕三个目标展开：
- 核实 PHP 运行版本及对应的安全修复情况。
- 更新 WordPress 官方 Docker 镜像。
- 重新创建容器，并验证网站运行状态。
这次没有直接切换 PHP 大版本，而是继续使用 PHP 8.3，以尽量减少现有插件、主题和业务代码的兼容性风险。
二、核实 PHP 版本与安全补丁
Docker 镜像标签并不一定能直接反映内部 PHP 的完整补丁版本，因此不能仅凭镜像名称判断漏洞是否已经修复。
更新前，需要检查容器内实际运行的 PHP 版本：
docker compose exec <服务名> php -v同时，应核对镜像来源、官方安全公告以及对应漏洞的修复说明。
经过检查，本次选定的镜像内 PHP 版本为 8.3.36。
确认运行版本达到修复版本门槛，是安全更新的重要一步。但对于具体 CVE，还应核实相应补丁是否包含在实际使用的构建中，不能仅凭版本号代替完整的安全验证。
三、更新 Docker 镜像
确定目标镜像后，先修改部署配置中的镜像引用，再拉取新版镜像并重新创建容器。
整个过程遵循以下原则：
- 更新前备份数据库及重要网站文件。
- 优先使用官方发布、版本明确的镜像。
- 尽量减少与此次安全修复无关的组件变更。
- 重新创建容器后，验证实际运行版本，而不是只检查镜像是否下载成功。
如果镜像更新同时涉及 WordPress 程序版本升级，还需要关注插件、主题和数据库的兼容性。
四、重新部署与验证
镜像更新完成后，重新创建容器，并检查服务运行状态。
常用检查命令：
docker compose ps
docker compose logs --tail=100然后再次检查容器内的 PHP 版本：
docker compose exec <服务名> php -v部署完成后，重点检查以下内容：
- 网站首页和管理后台能否正常访问。
- Web 服务器与 PHP-FPM 之间的请求转发是否正常。
- 数据库连接及读写是否正常。
- 插件、主题和文件上传功能是否正常。
- 容器启动日志中是否存在异常。
如果网站出现网关错误，应优先检查 PHP-FPM 是否正常启动，以及 Web 服务器的 FastCGI 转发配置是否正确。
五、Docker Compose 项目管理
本次更新还涉及 Docker Compose 项目名称的管理。
Compose 创建的容器名称通常与项目名、服务名及副本序号有关。项目名默认可能来自部署目录名称，也可以通过显式配置指定。
因此，修改项目目录名称时，需要注意 Compose 可能将其识别为另一个项目，从而创建新的容器，而不是管理原有容器。
长期维护时，建议：
- 使用稳定、简洁且不绑定具体软件版本的项目目录名称。
- 合理管理 Compose 项目名，避免意外创建重复服务。
- 将软件版本信息放在部署配置和维护记录中，而不是依赖目录名称。
- 重命名前确认原项目、容器及持久化数据的对应关系。
六、本次更新的经验总结
1. 不要只看镜像标签
应检查容器实际运行的软件版本，并核对相关安全补丁。
2. 安全更新不等于盲目升级所有组件
明确更新目标，尽量减少不必要的兼容性风险。若涉及程序大版本升级，应单独评估插件、主题和业务代码的兼容情况。
3. 更新前先备份
至少确认数据库备份、网站上传文件及其他持久化数据可以恢复。不要把删除容器与删除数据卷混为一谈。
4. 重建容器后必须验证
镜像拉取成功、容器启动成功，并不代表网站功能正常，也不能单独证明所有安全问题都已解决。
5. 保持持续维护
定期关注 PHP、WordPress、Web 服务器及插件的安全公告，及时评估漏洞影响并安排修复。
七、总结
这次维护再次说明，Docker 环境下的安全更新不仅仅是更换一个镜像标签，还包括漏洞核实、版本确认、数据保护、容器重建以及部署后的功能验证。
对个人网站而言，建立一套可重复执行的更新流程，比每次临时处理漏洞更加重要。
后续仍会持续关注运行环境的安全公告，在控制兼容性风险的前提下，及时完成必要的安全更新。
说明：本文记录的是一次 Docker 化 WordPress 环境的维护实践。具体漏洞是否修复，应以实际镜像构建、官方安全公告及验证结果为准。
