为什么选择放弃 Docker 改用 Podman（而你也应该如此）

新加坡内哥谈技术

1565人浏览 · 2025-09-10 08:15:00

新加坡内哥谈技术 · 2025-09-10 08:15:00 发布

每周跟踪AI热点新闻动向和震撼发展想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！订阅：https://rengongzhineng.io/

起点：从兴奋到反思
许多开发者曾把 Vagrant 视为开发环境的“圣地”——一个可以在所有机器上保持一致环境的解决方案。然而，语言版本差异、操作系统版本不兼容等问题仍会造成数日低效的调试过程。Docker 的到来曾带来同样的兴奋感，尤其是第一次使用 Docker Swarm（如今已少有人用）。Docker 不只是一个工具，它重新定义了应用的开发与部署方式。它赋予开发者构建“可重复、与本地系统隔离的环境”的能力，成为现代工程师的必备工具。

然而随着经验积累，对“事情本就该这样做”的默认认知逐渐被质疑，原本在后台默默运行的 Docker 守护进程（dockerd）也开始令人感到隐忧。尤其是，随着大量安全漏洞的披露，这一设计变得愈发令人不安：

CVE-2019-5736：允许容器中进程覆盖宿主的 runc 二进制文件，造成主机全面沦陷。
CVE-2022-0847 “Dirty Pipe”：可被用于容器越狱攻击。
CVE-2022-0492：通过 cgroups v1 实现特权提升。
CVE-2024-21626 / CVE-2024-23651~53 “Leaky Vessels”：容器逃逸相关漏洞，影响 Docker Engine 与 BuildKit。
2024年下半年多起加密挖矿攻击：通过暴露的 Docker API 和 Swarm 节点发起攻击。

正是在对这些问题深入思考之后，作者开始探索 Podman——一款不依赖守护进程的容器工具。最初只是出于好奇，最终却彻底改变了其容器开发工作流，并促使其在家庭实验室中全面转向 Fedora 系统。

核心优势：无守护进程设计（Daemonless）

Docker 的设计核心是一常驻后台的 dockerd 服务。每个 docker 命令其实都是客户端与这个后台守护进程通信。然而，这一守护进程默认以 root 权限运行，一旦出现漏洞，整个宿主系统都可能面临风险。

Podman 改变了这一模型：

没有守护进程
容器作为当前命令的子进程运行
运行在当前用户权限下

关键好处包括：

更合理的安全模型
即使攻击者在容器中提权为 root，在 Podman 模式下，他们依然只是宿主系统上的一个非特权用户。
无单点故障
Docker 一旦 dockerd 异常，所有容器都可能崩溃；Podman 中的容器独立运行，互不影响。
更轻的资源占用
不再有常驻后台的高内存占用，MacBook 不再无故发热。

Podman 真正闪光的地方

除了安全和架构，Podman 还带来了许多实用功能，使容器工作更为顺畅：

✅ Systemd 原生集成

Podman 可直接生成 systemd 服务文件，容器变成 Linux 系统中的一等公民。只需一行命令：

podman generate systemd --name my-app

然后使用标准 systemctl 工具进行管理。

✅ 与 Kubernetes 对齐（不是营销噱头）

由于 Red Hat 同时也是 Kubernetes 的核心贡献者，Podman 在设计上就与 K8s 紧密集成。其“Pod”概念是核心，而非后期补丁。可使用 podman generate kube 将本地 Pod 直接转为 Kubernetes YAML，实现本地与生产环境的高度一致性。

✅ 遵循 Unix 哲学

Podman 专注于运行容器，构建镜像用 Buildah，镜像管理用 Skopeo，每个工具专职一项，不再受制于 Docker 的一体化“黑盒”。

“无感”的迁移过程

让作者惊喜的是：从 Docker 切换到 Podman 几乎无需迁移。Podman 命令接口兼容 Docker，可直接通过别名实现“无痛替换”：

alias docker=podman

现有 Dockerfile 无需修改，容器构建、运行命令行为几乎一致。即使遇到差异，也大多是设计上的“安全提升”：

无法以非 root 用户绑定 1024 以下端口？ → 这是安全特性，反向代理是更佳架构。
数据卷权限问题？ → 挂载目录需归属当前用户，体现了权限隔离原则。
某些老工具依赖 Docker socket？ → Podman 可启用兼容的 API Socket。

真实体验与长期收益

运行 Podman 六个月后的感受：

睡得更安稳：不再担心容器偷偷运行在 root 权限下。
监控更干净：资源占用更可控，系统监控图表更整洁。
生产系统更稳定：容器之间互不干扰，宕机更少。

尽管 Docker 依然具有庞大的生态和用户群，但对新项目或具有技术选型自由的团队来说，Podman 显然代表了容器技术更安全、现代的进化方向。

从 Docker 到 Podman：FastAPI 实战迁移指南

✅ Step 1：现有 Dockerfile 直接兼容

FROM python:3.10-slim-buster WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --upgrade -r requirements.txt COPY . . EXPOSE 8000 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

✅ Step 2：构建镜像

podman build -t my-fastapi-app:latest .

或者设置别名后继续使用 docker build。

✅ Step 3：运行容器

开发：

podman run --rm -p 8000:8000 --name my-fastapi-container my-fastapi-app:latest

后台运行：

podman run -d -p 8000:8000 --name my-fastapi-container my-fastapi-app:latest

✅ Step 4：使用 systemd 部署生产服务

podman run -d -p 8000:8000 --name my-fastapi-container my-fastapi-app:latest mkdir -p ~/.config/systemd/user/ podman generate systemd --name my-fastapi-container > ~/.config/systemd/user/my-fastapi-container.service systemctl --user daemon-reload systemctl --user enable my-fastapi-container.service systemctl --user start my-fastapi-container.service

若希望服务在用户未登录时保持运行：

loginctl enable-linger $(whoami)

✅ Step 5：Pod 支持多服务部署

podman pod create --name my-fastapi-pod -p 8000:8000 -p 5432:5432 podman run -d --pod my-fastapi-pod --name fastapi-app my-fastapi-app:latest podman run -d --pod my-fastapi-pod --name postgres-db -e POSTGRES_PASSWORD=mysecretpassword postgres:13

此结构无需 Docker Compose 即可实现本地完整服务组合。