Hacker News 中文摘要

RSS订阅

我弃用Docker转向Podman（你也该如此） -- I Ditched Docker for Podman (and You Should Too)

原文链接 | HN讨论 | 2025-09-05 21:43:26

文章摘要

文章作者回顾了从Vagrant到Docker的演变，认为Docker彻底改变了应用开发和部署的方式，成为工程师的必备工具。然而，作者指出Docker的持久守护进程以root权限运行并消耗资源，认为这是不可避免的代价。最终，作者决定从Docker转向Podman，并建议读者也考虑这一转变。

文章总结

从Docker转向Podman：为什么你应该考虑这一转变

在软件开发领域，Docker曾经是革命性的工具，彻底改变了应用程序的开发和部署方式。它提供了一个可重复、独立于本地系统的环境，成为了每个工程师的必备工具。然而，随着时间的推移，Docker的架构问题逐渐显现，尤其是其依赖的dockerd守护进程，始终以root权限运行，一旦出现问题，整个容器生态系统甚至主机系统都可能受到威胁。

Docker的安全隐患

近年来，Docker多次曝出安全漏洞，例如： - CVE-2019-5736：容器内的进程可以覆盖主机的runc二进制文件，导致主机被完全控制。 - CVE-2022-0847 “Dirty Pipe”：Linux内核中的只读文件被覆盖，容器可以滥用此漏洞访问主机。 - CVE-2024-21626 “Leaky Vessels”：文件描述符泄漏和进程工作目录问题，可能导致主机文件系统被访问。 - 2024年的加密劫持攻击：攻击者通过暴露的Docker API和微服务进行加密劫持。

这些安全问题促使我寻找替代方案，最终我发现了Podman。

Podman的优势

Podman的最大优势在于其无守护进程的架构。与Docker不同，Podman不需要一个持续运行的守护进程，容器直接作为命令的子进程运行，并且使用用户权限，而不是root权限。这一简单的架构变化带来了巨大的安全性和稳定性提升：

  1. 安全性提升：即使容器内的用户提升到root权限，他们在主机上仍然是无权限用户，大大减少了攻击面。
  2. 无单点故障：Docker守护进程的崩溃会导致多个容器同时停止，而Podman的容器是独立的，一个容器的崩溃不会影响其他容器。
  3. 资源占用更少：Docker守护进程会持续占用资源，而Podman没有守护进程，资源占用更少。

Podman的其他亮点

  • 与Systemd的无缝集成：Podman可以生成标准的Systemd单元文件，使容器成为Linux服务生态系统的一等公民。
  • 与Kubernetes的深度集成：Podman支持原生Pod，可以直接生成Kubernetes YAML文件，使本地开发环境与生产环境一致。
  • Unix哲学的体现：Podman专注于运行容器，而将构建镜像、镜像检查等任务交给专门的工具（如Buildah和Skopeo）。

迁移的便捷性

从Docker迁移到Podman几乎是无缝的。Podman的CLI与Docker完全兼容，只需将docker命令别名替换为podman即可。现有的Dockerfile无需修改，开发者的操作习惯也无需改变。

实际效果

在使用Podman六个月后，我发现： - 安全性更高：不再需要担心容器是否以rootless模式运行。 - 资源使用更清晰：监控仪表板显示的资源使用模式更加干净。 - 开发与生产环境一致：Podman的Pod概念使得本地开发环境与生产环境更加一致。

总结

虽然Docker仍然拥有庞大的生态系统和用户基础，但对于新项目或能够基于技术优势做出决策的团队来说，Podman代表了容器技术的明显进化。它更安全、更符合Linux系统管理实践，并且为2025年的容器部署方式提供了更合理的架构。最好的前进方式是质疑那些你甚至没有意识到的假设。

FastAPI迁移指南

为了证明迁移的便捷性，以下是将FastAPI应用从Docker迁移到Podman的步骤： 1. Dockerfile无需修改：Podman使用与Docker相同的OCI容器格式。 2. 构建镜像：使用podman build命令构建镜像。 3. 运行容器：使用podman run命令运行容器。 4. 生产部署：生成Systemd单元文件，使应用像其他Linux服务一样管理。 5. 多服务应用：使用Podman的Pod概念管理多服务应用。 6. Docker Compose兼容性：使用podman-compose或转换为Kubernetes YAML文件。

迁移过程通常比人们预期的更加顺利。从开发环境开始，逐渐熟悉工作流的差异，然后逐步迁移生产工作负载。安全性和操作上的好处使得这一努力是值得的。

评论总结

主要观点总结：

  1. Podman 与 Docker 的适用场景

    • 观点：Podman 和 Docker 主要用于本地开发或运行本地容器化服务，大多数容器最终会部署在 Kubernetes 集群中。
    • 引用：
      • "Most of my containers end up on k8s clusters as pods. What else would one use podman or docker for beyond local dev or maybe running a local containerized service?" (评论1)
      • "I know a lot of kubernetes fans migrate to podman, but if you use dev stacks. Use in dev: devcontainer, podman can't replace docker!" (评论9)

  2. Podman 与 Docker 的兼容性和稳定性问题

    • 观点：Podman 在某些情况下与 Docker 不完全兼容，尤其是在处理复杂容器或网络配置时，容易出现错误。
    • 引用：
      • "Last third party container I’ve built had COPY —-link statements that didn’t worked on podman." (评论5)
      • "Podman networking is extremely unreliable. Our company made an effort to switch to get away from Docker Enterprise. We had to kill the effort because multiple people had random disconnects and packet drops." (评论17)

  3. Podman 的优势

    • 观点：Podman 的 rootless 模式和无依赖的架构是其显著优势，尤其适合那些希望避免 Docker 许可证问题的用户。
    • 引用：
      • "Rootless is a big deal." (评论11)
      • "Podman rocks for me! I find docker hard to use and full of pitfalls and podman isn’t any worse. On the plus side, any company I work for doesn’t have to worry about licences." (评论15)

  4. Docker 的持续主导地位

    • 观点：尽管 Podman 有其优势，但 Docker 仍然是行业标准，尤其是在开发工具和生态系统支持方面。
    • 引用：
      • "I really wish Docker didn't take over the industry like it has. In my experience not enough people know how to debug yet another layer of abstraction." (评论7)
      • "Too many problems with things that worked out of the box with docker. I don't have time to waste on troubleshooting yet another issue that can be solved by simply using the thing that just works." (评论26)

  5. Podman 的文档和用户体验问题

    • 观点：Podman 的文档不够完善，用户体验有时不如 Docker，尤其是在网络配置和错误处理方面。
    • 引用：
      • "The documentation is lacking. Officially, it’s mostly man pages, with a few blog posts announcing features, though the posts are often out of date." (评论29)
      • "Both podman and docker have pretty poor error handling in my experience. I wish both projects would assert different assumptions/requirements at runtime and report errors/warnings in a human-readable way." (评论2)

  6. 替代方案和工具

    • 观点：一些用户转向了其他工具，如 OrbStack 或直接使用 Kubernetes，以避免 Docker 和 Podman 的复杂性。
    • 引用：
      • "I have ditched docker desktop on macOS for OrbStack." (评论6)
      • "I write programs that run on the target OS again. It’s much easier, turnaround time is much quicker, it’s faster. Even battery lasts longer on my laptop." (评论16)

总结：

评论中既有对 Podman 的积极评价，也有对其兼容性和稳定性的批评。尽管 Podman 在 rootless 模式和无依赖架构方面具有优势，但 Docker 仍然是行业标准，尤其是在开发工具和生态系统支持方面。用户在选择工具时，需根据具体需求和场景权衡利弊。