9.1 从 Docker 搬家：一次真实迁移

本节摘要：一次团队级 Docker 到 Podman 迁移的完整记录：盘点阶段的依赖清点（找出 socket 挂载、存储目录依赖、守护进程 API 三类高危项）、试点与分批的执行顺序、每阶段的验证标准与回退预案。踩坑记录可直接复用——你的迁移可以从这份清单裁剪开始。

背景与盘点

场景设定：二十个开发者的团队，一条 Jenkins CI 流水线，两台应用服务器跑着 Docker Compose 部署的六个服务。迁移动机是安全审计的硬性发现：CI 构建容器挂载 docker.sock（第 1.1 节的"CI 即 root"）、应用服务器上容器以 root 运行。目标：六周内完成迁移，全程可回退。

盘点阶段的产出是一张依赖清单，三类高危项被逐个编号：

H1 socket 挂载：CI 构建容器挂载 docker.sock 构建镜像——迁移最大风险点，也是最大收益点
H2 存储目录依赖：三台机器上有脚本直接读写 Docker 的镜像目录路径（备份脚本、磁盘清理脚本）
H3 守护进程 API 脚本：两个内部运维脚本通过 Docker API（HTTP 端点）查询容器状态

低风险项：日常命令行使用（兼容性高）、compose 文件（兼容层覆盖）、镜像本身（OCI 标准互通）。

阶段二：试点——单人单项目的验证

选了一个独立小项目（一个 API 服务加一个数据库）先行。验证清单四条，全部通过才进下一阶段：


# 验证一：命令兼容（alias 切换后日常操作无感）
alias docker=podman
docker build -t pilot-api:dev .     # 实际走 buildah bud
docker run -d --name pilot pilot-api:dev
docker logs -f pilot
# 结果：通过。唯一差异提示来自 pull 输出的仓库解析回显

# 验证二：compose 兼容层
podman-compose up -d
# 结果：通过。网络与卷按预期创建；
# 注意点：depends_on 语义有细微差别，健康检查依赖
# 用了 healthcheck 的 sleep 兜底方案

# 验证三：数据卷权限（第 5.2 节的知识在这里兑现）
podman volume create pilot_db
podman run -v pilot_db:/var/lib/postgresql/data:Z \
    -e POSTGRES_PASSWORD=... postgres:16-alpine
# 结果：通过。命名卷路径避开了 UID 与标签两个坑

# 验证四：服务化（第 7 章的 Quadlet）
# pilot.container 写好，enable 后重启机器验证
# 结果：通过。linger 已开启，注销不中断

试点的真实价值是暴露"文档里不会写"的问题：团队发现 IDE 的 Docker 插件连不上默认 socket（改接 Podman 的兼容 socket，第 10 章的伏笔）、VPN 环境下 rootless 网络初始化慢了几秒。两个小问题都在试点期解决，没有传染到分批阶段。

阶段三：分批——从 CI 到开发机

先啃 H1。CI 构建容器改造是整个迁移的样板戏：


# 旧 CI 配置（危险示例，第 1.1 节批判过的形态）
# docker run -v /var/run/docker.sock:/var/run/docker.sock \
#     -v $PWD:/workspace ci-builder ./build.sh

# 新 CI 配置：无任何特殊挂载
podman run --rm \
    -v $PWD:/workspace:Z \
    -v ci-cache:/cache \
    ci-builder-podman ./build.sh
# 构建容器内跑 buildah bud（第 3.1 节的方案）：
# 无特权、缓存用命名卷持久化、SELinux 标签用 :Z 处理。
# 安全审计复查：构建容器能造成的最大破坏 = CI 用户权限

# 构建镜像本身改为 buildah bud（Dockerfile 原样保留）
# push 环节直接 podman push --sign-by（顺手接上第 6.3 节签名链）

H2、H3 随后清理：备份脚本改用 skopeo 检查归档（第 4.1 节）；磁盘清理改读 podman system df；两个 API 脚本改接 Podman 的 REST 服务（第 10 章）——其中一个因依赖 Docker 专有端点字段被重写，工作量两小时。开发机按"每人一周窗口、alias 双轨、周五自检"节奏推进，两周完成。

回退预案与最终收尾

回退设计贯穿全程，原则是"任何阶段 24 小时内可退"：镜像仓库双写（迁移期 CI 同时推两个引擎都能用的 OCI 镜像，本来就互通）；compose 文件在 git 分支上双轨维护；服务器上新旧服务单元并存（Quadlet 单元停用即回到旧 docker 服务）。实际触发过一次：一位开发者的 GPU 工作站上容器需要访问 NVIDIA 设备，rootless 配置繁琐，该机器回退到 Docker 并在决策表里标注"设备直通场景暂缓"——回退机制的存在让"个别例外"不阻塞整体推进。

六周后收尾：共享脚本全部切换、文档更新、新机器镜像只装 Podman 工具链。审计复查：CI 容器特权挂载清零、应用服务器容器全部以非 root 运行。迁移的原始动机（安全）全部兑现。

踩坑速查表（可直接抄进你的迁移文档）

IDE 或监控连不上容器引擎：接 Podman 的 Docker 兼容 socket，改连接路径即可
sudo 下看不到镜像：rootful 与 rootless 两套存储（第 2.1 节），统一操作身份
挂载目录报权限：先 :Z 再查 UID（第 5.2 节决策树）
绑定低端口失败：rootless 限制，用高位端口或 NET_BIND_SERVICE（第 6.2 节）
compose 服务健康依赖不稳：改用探针或 sleep 兜底，别迷信 depends_on
设备直通（GPU 等）rootless 繁琐：评估保留 Docker 的例外，或走 rootful Podman
找 docker 命令的习惯残留：保留 alias 长期有效，别强求改口

本节要点回顾

迁移是项目管理：盘点、试点、分批、收尾、固化五阶段，每阶段有通过标准
先啃高危项：socket 挂载的 CI 是风险与收益的交点
试点要暴露文档外的问题：IDE、VPN 这类环境摩擦只在小范围试错便宜
回退设计决定推进速度：能退才敢进，个别例外不阻塞整体
踩坑表是迁移的主要交付物之一：下一团队的起步资产

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流