本文记录本站建成后第一次正式的运行环境维护。网站最初使用 Docker Compose 部署，由 Caddy、WordPress 和 MariaDB 组成。建站完成后检查 WordPress 后台时发现 PHP 仍为 7.4.27，已经无法接收安全更新。最终通过 Windows Docker Desktop 下载镜像、导出镜像、SCP 上传服务器，再重新创建 WordPress 容器的方式，将 PHP 成功升级到了 8.3.33。
本文保留过程中遇到的错误和解决办法。与其记录一套看起来顺利的操作步骤，我更希望把这次真实的排查过程留下来，方便以后维护本站，也给遇到类似问题的人参考。
一、发现 PHP 版本过低
本站使用 Docker Compose 部署，整体结构为：
Internet │ ▼ Caddy │ ▼WordPress │ ▼MariaDB
Docker Compose 中包含三个服务：
services: db: image: mariadb:latest wordpress: image: wordpress:php8.3-apache caddy: image: caddy:2
WordPress 和 MariaDB 的数据分别保存在 Docker Volume 中，因此程序容器与网站数据是分开的。
建站完成后检查 WordPress 后台，发现提示：
您的站点正在运行过时版本的 PHP（7.4.27），其无法接收安全更新。
首先进入 WordPress 容器检查实际 PHP 版本：
docker exec -it blog-wordpress-1 php -v
结果：
PHP 7.4.27 (cli) (built: Dec 21 2021 21:31:45) (NTS)Zend Engine v3.4.0, Copyright (c) Zend Technologieswith Zend OPcache v7.4.27
至此确认 WordPress 容器实际运行的确实是 PHP 7.4.27。
二、配置文件已经是 PHP 8.3，为什么容器还是 7.4？
继续检查 Compose：
docker compose config
确认 WordPress 服务已经写成：
image: wordpress:php8.3-apache
但正在运行的容器仍然是 PHP 7.4。
原因是：修改 compose.yml 不会自动修改已经存在的 Container。
可以简单理解为：
compose.yml ↓规定应该使用什么镜像Container ↓代表当前实际运行的环境
本站很可能经历了这样的过程：
建站初期创建 WordPress 容器 ↓容器使用了旧版 WordPress/PHP 镜像 ↓后来 compose.yml 改成 wordpress:php8.3-apache ↓旧容器没有重新创建 ↓网站继续运行 PHP 7.4
这也解释了为什么网站一直能够正常访问，却一直没有真正升级 PHP。
这次维护留下的第一个经验是：
建站完成后不能只检查“网页能不能打开”，还应该检查容器实际运行的软件版本。
例如：
docker exec -it blog-wordpress-1 php -v
三、第一次尝试：直接拉取新镜像
既然 Compose 已经指定：
wordpress:php8.3-apache
最自然的办法就是：
docker pull wordpress:php8.3-apache
但服务器返回：
failed to resolve reference "docker.io/library/wordpress:php8.3-apache"
一开始看起来像是镜像不存在。
不过后来证明，镜像本身没有问题。
四、检查建站早期配置的阿里云镜像加速器
建站初期，为了解决 Docker Hub 访问速度和成功率的问题，我曾根据阿里云官方的镜像加速器教程，在服务器上配置过 Docker 镜像加速。
当时配置在：
/etc/docker/daemon.json
内容为：
{ "registry-mirrors": ["https://keb6jyb7.mirror.aliyuncs.com" ]}
检查：
docker info | grep-A10"Registry Mirrors"
仍然可以看到：
Registry Mirrors: https://keb6jyb7.mirror.aliyuncs.com/
说明这项配置从建站初期一直保留到了本次维护。
但镜像加速器并没有解决这次问题。进一步测试服务器直接访问 Docker Hub：
curl https://registry-1.docker.io/v2/
等待了很长时间后得到：
curl: (28) Failed to connect to registry-1.docker.io port 443 after 131083 ms: Connection timed out
因此确认：
当前阿里云服务器无法正常连接 Docker Hub。
这也解释了为什么：
docker pull wordpress:php8.3-apache
始终无法成功。
五、换一台可以访问 Docker Hub 的电脑
既然服务器无法获取镜像，就换一个网络环境。
我的 Windows 11 电脑当时还没有 Docker，因此执行：
docker--version
得到：
docker : 无法将“docker”项识别为 cmdlet、函数、脚本文件或可运行程序的名称
于是从 Docker 官网下载安装了 Windows 11 AMD64 版 Docker Desktop。
安装完成后第一次执行 Docker，又遇到了：
failed to connect to the docker API atnpipe:////./pipe/dockerDesktopLinuxEngine
这是因为 Docker Desktop 的 Linux Engine 当时还没有正常启动。
启动 Docker Desktop 后再次执行：
dockerinfo
终于能够看到：
Server: Version: 29.7.2 Operating System: Docker Desktop OSType: linux Architecture: x86_64
说明 Windows Docker 环境已经正常。
小贴士：
php:8.6-rc-alpine是 PHP 基础镜像，并不是本站应该使用的 WordPress 镜像。本站需要的是已经包含 WordPress、Apache 和 PHP 的wordpress:php8.3-apache。另外，PHP 是运行在 WordPress 容器里的，因此没有必要在 Ubuntu 宿主机上通过apt install php8.3来升级本站 PHP。
六、Windows 成功下载 PHP 8.3 镜像
执行：
dockerpullwordpress:php8.3-apache
这次成功：
Digest: sha256:b427cec767f5de2aa649390cb8805aa1fe320e1e0d57fc1f467754edb6cc0a49Status: Downloaded newer image for wordpress:php8.3-apachedocker.io/library/wordpress:php8.3-apache
至此确认：
wordpress:php8.3-apache镜像本身没有问题，之前服务器上的失败主要是镜像获取的网络问题。
七、把镜像导出并上传到服务器
使用 Docker 的 save 命令导出镜像：
dockersavewordpress:php8.3-apache-owordpress-php83.tar
检查：
dirwordpress-php83.tar
得到：
Length: 277670400
约 265 MiB。
然后使用 Windows 自带的 SCP 上传到服务器：
scp .\wordpress-php83.tarroot@47.107.159.102:/opt/blog/
第一次连接服务器时出现：
The authenticity of host '47.107.159.102' can't be established.Are you sure you want to continue connecting(yes/no/[fingerprint])?
确认服务器 IP 后输入：
yes
即可继续。
SCP 遇到的一个小坑
第一次上传时出现：
Connection closed by 47.107.159.102 port 22
一开始容易怀疑是 SSH 或 SCP 配置出现了问题。
但后来确认服务器 SSH 本身正常，可以正常登录。
重新执行：
scp .\wordpress-php83.tarroot@47.107.159.102:/opt/blog/
并及时输入密码后，文件就正常开始传输了。
因此这次的经验是：
如果 SCP 已经进入密码输入阶段，却因为等待输入太久出现
Connection closed，不要急着修改 SSH 配置。先重新执行一次，并及时输入密码。
上传完成后服务器检查：
ls-lh /opt/blog/wordpress-php83.tar
结果：
-rw-r--r-- 1 root root 265M Aug 19 18:18 /opt/blog/wordpress-php83.tar
八、将镜像导入服务器
服务器执行：
docker load -i /opt/blog/wordpress-php83.tar
然后检查：
docker images | grep wordpress
结果：
wordpress:latest fc33b796b041 874MB 212MBwordpress:php8.3-apache b427cec767f5 1.09GB 278MB
此时新旧镜像同时存在。
这一步很重要：
到这里还没有删除正在运行的网站，也没有删除任何网站数据。
九、重新创建 WordPress 容器
进入网站目录：
cd /opt/blog
再次确认 Compose 配置：
docker compose config | grep image
得到：
image: caddy:2image: mariadb:latestimage: wordpress:php8.3-apache
确认无误后，只重新创建 WordPress 服务：
docker compose up -d--no-deps--force-recreate wordpress
结果：
[+] up 1/1 ✔ Container blog-wordpress-1 Started
这里没有使用：
docker compose down -v
因为没有必要，而且涉及 Volume 的操作存在误删数据的风险。
WordPress 数据仍然保存在：
blog_wordpress_data
MariaDB 数据仍然保存在：
blog_db_data
因此：
更换 WordPress Container 不等于重新安装 WordPress，也不等于删除网站数据。
十、确认 PHP 已经升级
执行：
docker exec -it blog-wordpress-1 php -v
最终得到：
PHP 8.3.33 (cli) (built: Aug 5 2026 00:32:16) (NTS)Zend Engine v4.3.33, Copyright (c) Zend Technologieswith Zend OPcache v8.3.33
PHP 已经从：
7.4.27
升级到：
8.3.33
再次检查：
docker ps
三个服务全部正常运行：
blog-wordpress-1blog-caddy-1blog-db-1
最后实际打开网站和 WordPress 后台进行检查：
- 网站正常访问
- 文章和页面正常
- WordPress 后台正常
- 没有出现白屏或 500 错误
- PHP 版本过低的警告已经消失
至此，本次 PHP 升级完成。
十一、清理临时文件
之前上传到服务器的：
/opt/blog/wordpress-php83.tar
只是为了迁移 Docker 镜像而产生的临时文件。
确认升级成功后删除：
rm /opt/blog/wordpress-php83.tar
最终 /opt/blog/ 中仍然只有网站实际使用的：
Caddyfilecompose.yml
十二、这次维护留下的经验
1. 建站完成后应该检查实际运行版本
不能只确认网页可以打开。
至少应该检查：
docker exec -it blog-wordpress-1 php -v
2. compose.yml 和正在运行的 Container 可能不是同一个状态
修改：
image: wordpress:php8.3-apache
并不会自动升级已经存在的容器。
需要重新创建容器。
3. Image、Container、Volume 是三个不同的东西
可以简单理解为：
Image ↓Container ↓Volume 保存数据
升级 WordPress 时通常需要更换 Image、重新创建 Container，但应该保留 Volume。
因此：
删除 Container≠删除网站数据
真正需要谨慎的是涉及 Volume 的操作，例如：
docker compose down -v
4. 服务器无法 docker pull 时，不一定需要更换整个部署方案
如果另一台电脑可以访问 Docker Hub，可以：
docker pull ↓docker save ↓SCP ↓docker load
把镜像离线迁移到服务器。
5. 镜像加速器不是永久的镜像备份
本站建站初期配置的阿里云 Docker 镜像加速器一直保留到了这次维护，但这次仍然遇到了 Docker Hub 镜像无法拉取的问题。
因此不能把“配置了镜像加速器”理解为“以后一定能重新拉到所有镜像”。
十三、最终结果
本次维护开始时：
WordPressPHP 7.4.27
最终：
WordPressPHP 8.3.33
整个过程可以概括为：
发现 PHP 过旧Windows 安装 Docker Desktop ↓解决 Docker Engine 未启动问题 ↓Windows 成功拉取镜像 ↓docker save ↓SCP 上传 ↓第一次 SCP 因等待密码过久断开 ↓重新执行并及时输入密码 ↓上传成功 ↓docker load ↓重新创建 WordPress Container ↓PHP 8.3.33 ↓网站正常运行 ↓清理临时镜像文件 ↓完成
这次维护是本站建成后的第一次完整运行环境升级。它不仅解决了 PHP 7.4 已停止安全更新的问题，也验证了当前 Docker 架构中程序容器与网站数
