Docker 29.7.2 是一次聚焦稳定性的修复版本。它处理了两个会直接影响生产工作流的问题：重复传递同名环境变量可能导致 docker service create 或 docker service update panic，以及 Docker Engine 29.7.0 引入的镜像拉取回归。
Swarm 服务不再因重复环境变量 panic
在 Swarm 服务管理中，环境变量可能同时来自脚本默认值、部署参数和 CI/CD 平台。多层参数拼接很容易产生重复键，例如连续传入两个 APP_ENV：
docker service create \
--name duplicate-env-demo \
--env APP_ENV=staging \
--env APP_ENV=production \
nginx:alpine
受影响版本可能在处理这种输入时 panic。Docker 29.7.2 修复了该问题，使 CLI 不会因为重复环境变量而异常崩溃。类似问题也可能出现在更新现有服务时：
docker service update \
--env-add APP_ENV=staging \
--env-add APP_ENV=production \
duplicate-env-demo
修复 panic 并不意味着业务层面应该依赖重复键。重复环境变量的最终语义可能不直观，也容易让部署结果受参数顺序影响。更稳妥的做法是在调用 Docker 前完成去重，并让每个变量只有一个明确来源。
可以这样实践，在部署脚本中先生成唯一的环境变量参数：
#!/usr/bin/env bash
set -euo pipefail
APP_ENV="${APP_ENV:-production}"
LOG_LEVEL="${LOG_LEVEL:-info}"
docker service update \
--env-rm APP_ENV \
--env-rm LOG_LEVEL \
--env-add "APP_ENV=${APP_ENV}" \
--env-add "LOG_LEVEL=${LOG_LEVEL}" \
web
运行前需要把 web 改成实际服务名。--env-rm 后再 --env-add 的方式还能减少旧配置残留造成的歧义。
修复绝对 hardlink 目标导致的镜像拉取失败
Docker 29.7.0 引入了另一个回归：拉取包含绝对 hardlink 目标的镜像时，Engine 可能拒绝该镜像。hardlink 信息位于镜像层的 tar 归档中，一些既有镜像或特定构建工具生成的层可能使用绝对目标路径。
这个问题的关键在于兼容性边界。镜像此前可以正常分发，但升级 Engine 后突然无法拉取，故障通常会表现为节点部署失败、滚动更新停滞，或者新节点无法恢复工作负载。Docker 29.7.2 恢复了这类镜像的拉取兼容性。
升级后，可以对受影响镜像执行一次显式验证：
#!/usr/bin/env bash
set -euo pipefail
IMAGE="${1:?usage: ./verify-image.sh registry.example.com/team/app:tag}"
docker pull "$IMAGE"
docker image inspect "$IMAGE" --format 'id={{.Id}} os={{.Os}} arch={{.Architecture}}'
docker run --rm "$IMAGE" true
最后一条命令假设镜像允许覆盖默认命令，并且包含 true。若镜像是 distroless 或有固定入口点，可以改用该应用自身的健康检查命令；至少应保留 docker pull 和 docker image inspect 两步。
升级前后怎么验证
这两个修复都适合纳入升级冒烟测试。不要只确认 Docker daemon 能启动，还应覆盖组织实际使用的镜像和 Swarm 更新路径：
docker version
docker info
docker pull nginx:alpine
docker service ls
docker service inspect web --format '{{json .Spec.TaskTemplate.ContainerSpec.Env}}'
建议检查以下事项：
- 确认客户端与服务端版本，避免只升级 CLI 而遗漏 Engine。
- 在测试节点拉取曾受 hardlink 问题影响的真实镜像。
- 对 Swarm 服务执行一次环境变量更新，并观察服务任务是否正常收敛。
- 检查自动化脚本是否会生成重复的
--env或--env-add参数。 - 保留镜像摘要和服务配置快照，便于升级失败时定位差异。
是否应该立即采用
如果已经运行 Docker Engine 29.7.0，或者 Swarm 自动化中可能产生重复环境变量，29.7.2 的修复具有直接价值。升级仍应按照节点分批进行：先验证非关键节点，再推进管理节点和生产工作节点。
需要注意的是，本次修复解决的是 panic 和镜像兼容性回归，并不会替代部署参数校验。升级 Engine 的同时清理重复环境变量、固定关键镜像摘要，并为镜像拉取建立冒烟测试，才能避免同类问题在自动化链路中再次放大。