跳至主要內容

Podman 与 Rancher Desktop：替代本地容器运行时的兼容工程

高谷深陵大约 14 分钟约 4066 字
Podman rootless 与 Rancher Desktop 双运行时兼容链路知识海报
Podman 与 Rancher Desktop 兼容判定图命令入口相似只是起点，真正需要验证的是 daemon、用户命名空间、镜像存储、Compose Provider、网络、卷和清理边界。高清原图

“换个命令就能跑”为什么会变成半天故障

一个团队把开发机从 Docker Desktop 换成 Podman。podman run 能启动 Nginx，大家便把迁移标记为完成。第二天，Compose 项目找不到环境变量，测试容器不能写 bind mount，依赖 Docker Socket 的工具报权限错误；另一位同事切换 Rancher Desktop 的 container engine 后，又发现昨天拉取的镜像全部“不见了”。这些现象不是偶发故障，而是迁移时只验证了命令表面，没有验证运行时边界。

Podman 采用 daemonless CLI 和 OCI 容器模型，Linux 上可以由普通用户以 rootless 模式运行；macOS 与 Windows 需要 podman machine 提供 Linux VM。Rancher Desktop 则管理一台本地 Linux VM，并允许在 containerd 与 Moby/dockerd 之间选择：前者主要使用 nerdctl，后者提供 Docker API 和 docker CLI。两者都能运行容器，但镜像存储、API、用户映射、Compose 实现和故障证据并不相同。

替代运行时能否进入团队基线，应由五个不变量决定：

新人能从干净机器安装、启动并确认自己连接的是哪个运行时。项目的镜像、Compose、网络、卷、健康检查和退出码在支持矩阵内一致。rootless、SELinux、UID/GID 和 Socket 权限没有被“临时提权”掩盖。

代理、企业 CA、Registry 凭证在正确层生效，且不会进入仓库和镜像层。切换或卸载后能解释数据在哪里、哪些对象仍保留、怎样安全回退。

先建立运行时身份证据

不要先创建业务容器。安装完成后，先保存能够区分客户端、服务端、VM 和存储根的证据：

podman version
podman info --format '{{.Host.Security.Rootless}} {{.Store.GraphRoot}}'
podman system connection list
podman machine list

Linux rootless 环境的第二条命令应输出 true，存储通常位于当前用户的数据目录；root 用户与另一个普通用户看不到这批容器和镜像。macOS/Windows 上先初始化受控 VM：

podman machine init --rootful=false --cpus 4 --memory 4096 --disk-size 40 dev-podman
podman machine start dev-podman
podman machine inspect dev-podman
podman info

machine inspect 中的 CPU、内存、磁盘和连接信息要与团队基线一致。VM 启动失败时，先看虚拟化能力、WSL/Hyper-V 或 macOS provider，再看企业代理；不要反复 machine reset，它会扩大数据丢失范围。

Rancher Desktop 安装后使用 rdctl 留下同类证据：

rdctl version
rdctl list-settings
nerdctl version
docker version

只有当前选中的运行时对应命令应成功连接。containerd 路径使用 nerdctl，Moby/dockerd 路径使用 Docker API 与 docker。团队手册应记录 Rancher Desktop 版本、container engine、Kubernetes 是否启用、VM 资源和支持的宿主系统，不要只写“安装 Rancher Desktop”。

Linux 上把 rootless 跑通

rootless 的价值是让容器进程不直接获得宿主 root 权限，但它不是沙箱承诺。安装应走发行版官方包仓库，随后核对辅助 UID/GID、存储和网络组件：

command -v podman newuidmap newgidmap
grep "^${USER}:" /etc/subuid /etc/subgid
podman unshare cat /proc/self/uid_map
podman info --debug

/etc/subuid 与 /etc/subgid 需要为该用户分配足够且不重叠的范围。修改映射后，已有 pause process 仍可能持有旧命名空间；先停止当前用户容器，再执行 podman system migrate 让新映射生效。不要手工删除运行时 PID 文件来“碰运气”。

rootless 网络通常还经过用户态网络组件，低端口绑定、源地址保留、VPN 与企业 DNS 的表现可能不同于 rootful bridge。先从 podman info --debug 确认 network backend，再分别验证容器出网、容器间 DNS、宿主回连和端口绑定。不要为了绑定低端口直接改用 rootful；应先选择高端口，确有兼容要求时再由平台 owner 评估系统的非特权端口下限和影响范围。

用一个限定名称的正向实验验证进程、端口和用户映射：

set -eu
name=te05-podman-ok
podman rm -f "$name" >/dev/null 2>&1 || true
podman run -d --name "$name" -p 127.0.0.1:18085:8080 \
  docker.io/library/nginxinc/nginx-unprivileged:alpine
podman inspect "$name" --format '{{.State.Status}} {{.HostConfig.PortBindings}}'
curl --fail --silent http://127.0.0.1:18085/ >/dev/null
podman top "$name" user huser
podman rm -f "$name"

预期 inspect 显示 running，curl 退出码为 0，top 中容器用户与宿主映射不是一个无解释的宿主 root 进程。镜像拉取依赖网络；离线团队应把镜像按 Digest 缓存在受控 Registry，并把 Digest 写进兼容夹具，而不是把一次公网成功当成长期保证。

用反向实验暴露 bind mount 问题

下面的夹具只创建当前目录下带固定前缀的临时目录，不会递归清理其他路径：

set -eu
root="$PWD/.te05-podman-mount"
case "$root" in "$PWD"/.te05-*) ;; *) echo "unsafe path" >&2; exit 64;; esac
rm -rf -- "$root"
mkdir -p "$root"
printf 'seed\n' > "$root/input.txt"

set +e
podman run --rm -v "$root:/work" docker.io/library/alpine:3.22 \
  sh -c 'printf "container\n" >> /work/input.txt'
rc=$?
set -e
printf 'write_rc=%s\n' "$rc"
ls -ln "$root/input.txt"
rm -rf -- "$root"

在 SELinux enforcing 主机上，未标注的 bind mount 可能以 Permission denied 和非零退出码失败。项目私有目录可评估 :Z，多个容器共享时评估 :z；二者都会修改宿主文件标签，大目录重标记会拖慢启动，系统目录绝不能随意 relabel。UID 不匹配时优先评估 --userns=keep-id 或镜像用户设计。:U 会递归改变宿主 owner，必须先在测试副本验证，不能作为通用修复。

Socket 兼容不是安全兼容

一些 IDE、测试库和 Compose Provider 只会调用 Docker API。Linux rootless Podman 可通过用户级 socket 激活兼容 API：

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
curl --unix-socket "${XDG_RUNTIME_DIR}/podman/podman.sock" \
  http://d/v1.40/_ping

_ping 应返回 OK。这只证明协议入口可达，不证明所有 Docker API 字段和行为等价。该 Socket 可以让调用者以当前用户身份执行任意 Podman 操作；挂进不可信容器，相当于把当前用户的容器控制权交给容器内进程。网络暴露 Socket 必须使用双向 TLS，通常更稳妥的是 Unix Socket 权限或 SSH 转发。

用户级 podman.socket 通过 systemd socket activation 按需拉起 API service，并不意味着 Podman 重新变成管理所有容器的中心 daemon。若登出后仍要保留 Socket，需由管理员明确评估并执行 loginctl enable-linger "$USER"；不需要常驻兼容入口时，用 systemctl --user disable --now podman.socket 回收暴露面。直接运行 podman system service 时还要明确监听地址和空闲超时，不能把无 TLS 的 TCP 端点留在本机或办公网。

兼容工具要逐项测试 API 版本、Build、网络、volume、healthcheck、日志、exec、事件流和清理。若工具硬依赖 Docker 特有字段或 Swarm API，就应保留 Moby/dockerd 路径，而不是在故障后关闭安全控制。

Compose 的真正执行者是谁

podman compose 是外部 Compose Provider 的包装层。先查实际 provider，再运行配置解析：

podman compose version
podman compose --help
printf 'provider=%s\n' "${PODMAN_COMPOSE_PROVIDER:-auto-selection}"

Provider 可能是 docker-compose 或 podman-compose，而且两者同时存在时 docker-compose 优先。可通过 PODMAN_COMPOSE_PROVIDER 指向经过验证的可执行文件，或在 containers.conf 的 compose_providers 中固定绝对路径。若团队不固定 provider，同一条命令在两台机器上可能由不同程序解释。

创建兼容夹具 compose.yaml：

name: te05-runtime-compat
services:
  web:
    image: docker.io/library/nginxinc/nginx-unprivileged:alpine
    ports:
      - "127.0.0.1:18086:8080"
    healthcheck:
      test: ["CMD-SHELL", "wget -q -O- http://127.0.0.1:8080/ >/dev/null || exit 1"]
      interval: 2s
      timeout: 2s
      retries: 20
    volumes:
      - web-cache:/tmp/cache
volumes:
  web-cache:

然后执行完整闭环：

set -eu
provider="${PODMAN_COMPOSE_PROVIDER:?set an audited provider executable}"
test -x "$provider"
export PODMAN_COMPOSE_PROVIDER="$provider"
podman compose -f compose.yaml config
podman compose -f compose.yaml up -d
podman compose -f compose.yaml ps
curl --fail http://127.0.0.1:18086/ >/dev/null
podman compose -f compose.yaml logs --no-color web > .te05-compose.log
podman compose -f compose.yaml down

正向判据是配置解析退出 0、容器进入健康状态、HTTP 退出 0、日志可读取，普通 down 后 named volume 仍存在。反向实验把宿主端口临时改成已占用端口，up -d 应非零退出，并在日志中看到 bind/listen 冲突；若命令返回成功却没有服务可用，说明 Provider 的错误传播不符合团队门禁。

删除实验数据前先按 Compose project 盘点：

podman ps -a --filter label=io.podman.compose.project=te05-runtime-compat
podman ps -a --filter label=com.docker.compose.project=te05-runtime-compat
podman volume ls --filter name=te05-runtime-compat
podman compose -f compose.yaml down --volumes

down --volumes 是重置数据，不是日常停止。共享开发数据库或未知 volume owner 存在时不得执行。

Rancher Desktop 双运行时切换实验

切换前分别记录对象清单和镜像摘要：

nerdctl namespace ls
nerdctl --namespace default images
nerdctl --namespace k8s.io images
docker context show
docker image ls --digests

containerd 使用 namespace 隔离对象；Kubernetes 常见对象位于 k8s.io，普通 nerdctl 默认 namespace 中看不到它们。Moby/dockerd 则使用自己的镜像存储。Rancher Desktop 切换 container engine 时，旧运行时构建或拉取的镜像在新运行时不可见，但不等于立即被删除。

先停止夹具容器并确认需要保留的本地镜像已经推送到 Registry 或导出。团队可以用同一 Dockerfile 做切换验收：

FROM docker.io/library/alpine:3.22
RUN printf 'runtime-compat\n' > /runtime.txt
CMD ["cat", "/runtime.txt"]

下面的脚本在 containerd 中构建唯一测试标签，切到 Moby 后先证明镜像不可见，再重建同一 Dockerfile。等待有次数上限，正常结束和异常中断都会删除两边的夹具镜像并恢复原引擎：

set -eu
command -v jq >/dev/null
tag="te05-runtime:check-$$"
original_engine="$(rdctl list-settings | jq -er '.containerEngine.name')"

wait_engine() {
  desired="$1"
  attempt=0
  while [ "$attempt" -lt 60 ]; do
    if rdctl list-settings | jq -e --arg engine "$desired" \
      '.containerEngine.name == $engine' >/dev/null 2>&1; then
      return 0
    fi
    attempt=$((attempt + 1))
    sleep 2
  done
  echo "engine did not become ready: $desired" >&2
  return 70
}

cleanup() {
  set +e
  rdctl set --container-engine.name=containerd >/dev/null
  wait_engine containerd && nerdctl image rm "$tag" >/dev/null 2>&1
  rdctl set --container-engine.name=moby >/dev/null
  wait_engine moby && docker image rm "$tag" >/dev/null 2>&1
  rdctl set --container-engine.name="$original_engine" >/dev/null
  wait_engine "$original_engine"
}
trap cleanup EXIT

rdctl set --container-engine.name=containerd
wait_engine containerd
nerdctl info >/dev/null
nerdctl build -t "$tag" .
test "$(nerdctl run --rm "$tag")" = "runtime-compat"

rdctl set --container-engine.name=moby
wait_engine moby
docker info >/dev/null
if docker image inspect "$tag" >/dev/null 2>&1; then
  echo "test tag unexpectedly exists in the Moby store" >&2
  exit 71
fi
docker build -t "$tag" .
test "$(docker run --rm "$tag")" = "runtime-compat"

cleanup
trap - EXIT

rdctl set 会触发运行时重启，命令返回不代表业务夹具已经恢复；必须再检查目标 CLI、容器、网络和镜像。反向检查应证明镜像在新存储中不存在，而不是把“不存在”误判为数据损坏。某些版本的 Moby 还可在 classic 与 containerd snapshotter 两种 image store 间切换，Wasm 设置也可能改变所用 store；这类“同为 Moby 但镜像不可见”的问题应先看 docker info、Rancher Desktop Diagnostics 和 container-engine.moby-storage-driver，不能误判为 engine 切换丢盘。可移植交付物应推到受控 Registry 并使用 Digest，而不是依赖 Desktop VM 内部存储。

代理、CA 与 Registry 凭证要分层排查

拉取失败时先判断是哪一层发起连接：Podman CLI、Podman Machine 内服务、Rancher Desktop VM、containerd、dockerd、Compose Provider 或容器内进程。宿主 curl 成功不能证明 VM 内 Registry TLS 成功。

排障时收集这些证据：

image_digest="${IMAGE_DIGEST:?set the approved sha256 digest}"
[[ "$image_digest" =~ ^sha256:[0-9a-f]{64}$ ]] || { echo "invalid digest" >&2; exit 64; }
podman info --debug
podman login --get-login registry.example.com
podman pull "registry.example.com/your-project/app@${image_digest}"
rdctl list-settings
nerdctl info
docker info

Registry 登录使用短期、最小权限凭证和系统凭证存储；不要把 auth.json、Docker config、私钥或企业 CA 私钥挂进项目。企业 CA 需要分别进入宿主信任、VM/daemon 信任和必要的容器镜像信任。关闭 TLS 校验只能用于隔离诊断，不能成为团队默认配置。

从现象反推边界

rootless 容器看不到 rootful 镜像

先比较 id、podman info 的 rootless 与 graphRoot，再分别执行普通用户和 sudo podman images。两个存储独立即为预期行为，不要复制内部存储目录；重新按 Digest 拉取或通过 Registry 迁移。

Compose 在两台机器表现不同

比较 podman compose version、PODMAN_COMPOSE_PROVIDER、provider 路径和 config 输出。把 provider 及版本写入团队基线，并将兼容夹具放进 CI 或代表开发机定期执行。

bind mount 能读不能写

同时检查宿主权限、容器进程 UID、user namespace 映射和 SELinux AVC。修复顺序是镜像用户、keep-id、目录 owner、正确的 :z/:Z；不要先上 root、privileged 或 label=disable。

Rancher Desktop 切换后镜像消失

核对当前 engine、nerdctl namespace 与 Docker context。若对象仍在旧 engine，回切即可确认；长期方案是 Registry Digest 和可重复 Dockerfile，不是复制 VM 磁盘。

API 客户端连接成功但操作失败

Socket _ping 只验证连接。捕获客户端请求、Podman 日志和失败 API 字段，建立“必需 API 清单”；无法兼容时选择原生 Podman 接口、替换工具或保留 Moby，不伪造完全兼容结论。

架构选择：替代的是产品，还是团队运行时合同

Linux 优先 rootless Podman，适合希望降低常驻 daemon 权限、使用 systemd/Quadlet 管理开发服务、并能接受兼容验证的团队。依赖大量 Docker API 工具、Desktop 扩展或厂商专用行为时，Moby/dockerd 的迁移成本更低。macOS/Windows 上 Podman 仍依赖 VM，rootless 指的是 VM 内用户模型，不能把它理解成没有虚拟化层。

Rancher Desktop 适合同时需要本地容器与可选 Kubernetes、希望在 containerd 与 Docker API 路径间做明确选择的团队。containerd/nerdctl 更贴近 Kubernetes 镜像与 namespace 模型；Moby/dockerd 更适合 Docker CLI 和 API 生态。频繁切换 engine 会造成重复拉取、双份存储和排障认知成本，正式基线应只选一条主路径。

容量预算至少包含 VM 磁盘、镜像层、Build Cache、named volume 和重复 engine 存储。团队要观测存储增长趋势、拉取命中率、兼容夹具通过率和迁移故障数；阈值由开发机磁盘预算与项目基线决定，不用统一百分比冒充标准。

团队治理与退出

运行时配置要像代码依赖一样有 owner：维护支持矩阵、版本基线、镜像 Registry、Provider、代理 CA、兼容夹具和升级窗口。升级先在代表性的 Linux、Windows/WSL、macOS、x86_64 与 ARM64 机器运行夹具，再分批推广；出现 bind mount、网络或 API 回归时，回退应用版本和运行时版本，不能通过全局 prune 清场。

卸载前先导出证据：

podman ps -a
podman images --digests
podman volume ls
podman machine list
nerdctl images
docker image ls --digests

只删除明确命名的 te05-* 夹具对象。业务开发数据先由 owner 决定保留、导出还是销毁；凭证随后撤销，Socket 停止，企业 CA 配置按变更记录恢复。最后重新运行对应清单命令，证明目标对象消失且其他项目仍存在。

当前 CLI、运行时、VM、context、rootless 状态和存储根可被证据区分。Podman Machine 的 CPU、内存、磁盘和 provider 有团队基线。rootless 的 subuid/subgid、user namespace、bind mount 与 SELinux 经过正反实验。

API Socket 只通过受控 Unix 权限或 SSH/mTLS 暴露，未挂给不可信容器。Compose Provider 已固定，配置、健康、错误传播、volume 保留和重置均有判据。Rancher Desktop 的 containerd/nerdctl 与 Moby/dockerd 只选一条主路径。

engine 切换前后必须验证镜像不可见、夹具清理和原引擎恢复，交付镜像使用 Registry Digest。代理、CA 和 Registry 凭证按宿主、VM、daemon、容器分层治理。清理只作用于明确 project 和 te05-* 对象，没有使用无范围全局 prune。

升级、回退、数据保留、凭证撤销和工具退出都有 owner。

跳到正文