探索 Podman：更安全的 Docker 替代方案

原文 ↗ Hacker News 讨论 ↗

Podman 正在成为 Docker 的一个热门替代方案，主要原因是其安全优先的设计：无 root 容器、更好的 SELinux 集成，以及更少侵入的网络处理，避免了 Docker 在防火墙和 VPN 方面的一些问题。评论者指出，Podman 往往可以作为直接替代方案，并且与 systemd 和 docker-compose/podman-compose 等工具配合良好，但也提到在工具链、UID/GID 映射和平台问题上仍有粗糙之处，尤其是在 Apple Silicon 上。许多人仍然因为 Docker 的生态、文档和熟悉度而继续使用它，并认为如果正确配置，Docker 的无 root 模式也能解决类似的安全问题。

安全模型与无 root 容器

  • 许多人认为 Podman “默认更安全”的模型（无 root、用户命名空间、没有长期运行的 root 守护进程）是相较于 Docker 的主要优势。
  • Docker 默认以 root 运行并使用 docker 组的做法，被批评为在多用户 / 托管环境中存在严重安全风险。
  • 一些评论指出，Docker 确实 支持无 root 模式，并且默认使用 seccomp，但这并不是开箱即用的路径，而且被认为优先级更低。
  • 有人认为将 Podman-rootless 与 Docker-as-root 进行比较“不公平”；他们主张真正相关的比较应是 Docker-rootless 与 Podman-rootless。

SELinux 与标签

  • Podman 对 SELinux 策略的遵循被赞赏为适合生产环境的安全特性，但也会带来摩擦（容器无法访问绑定挂载的目录）。
  • 变通方法包括：在 containers.conf 中禁用标记，或者在卷上使用 :z / :Z 以自动调整标签。
  • 对 SELinux 的看法从“花一个小时学一下很值得”到“不可用的灾难”不等，不过也有人坚持应将其设为 permissive，而不是直接禁用。

网络行为

  • Docker 对 iptables/nftables 的操作是反复出现的痛点：会与防火墙（UFW）、VPN 和 KVM 网桥冲突。
  • 有人报告 Podman 与宿主机网络和 KVM 配合得“很友好”，不过无 root 网络仍受内核限制。
  • 动态修改转发端口是一个需求，但由于 iptables/nftables 的复杂性，这在技术上被描述为很难实现。

systemd、Quadlet 与编排

  • Podman 早期对 podman generate systemd 的支持很受欢迎；随后转向 Quadlet 的做法存在分歧。有些人觉得 Quadlet 更清晰，另一些人则认为这只是无谓的复杂化，并退回到 docker-compose 或手写单元文件。
  • podman-compose 可以生成并注册 systemd 单元；有人觉得这很优雅，也有人说它不够容易发现。
  • 一些人在 home lab 甚至小型生产环境中使用 docker-compose/podman-compose；另一些人认为更大的部署应该迁移到 Kubernetes、Swarm 或 Nomad，并希望有一个简单的 Podman 原生“类似 Swarm”的编排器。

工具链、兼容性与开发工作流

  • Podman “基本上”可以直接替代 Docker；但细微的 CLI 和行为差异会破坏脚本或 compose 配置，尤其是在网络方面。
  • 在 Podman 上使用 Docker 工具链通常需要运行一个兼容 Docker 的 socket，并把 DOCKER_HOST 指向它；有人觉得这很简单，也有人认为这只是多余的阻力。
  • Docker 的生态系统（compose 文件、文档、社区）仍被认为更成熟、更容易接触，因此很多组织即使在 CI 中使用 Podman/Buildah，也仍然让开发者继续使用 Docker。
  • NixOS 用户会强调像 compose2nix 这样的工具，用来把 compose 文件转换为原生的 systemd/OCI 配置。

平台特定体验

  • 在 Linux 上，有人声称如果能用 Podman，就“没理由再用 Docker 了”。
  • macOS（尤其是 Apple Silicon）上的体验则喜忧参半：有人报告多年使用都很顺利，也有人遇到严重卡死或冻结，只好回退到 Docker。Podman Desktop 有时在 CLI 安装不行的地方反而能工作。
  • 在 Windows 上，Podman 因比 Docker Desktop 更轻量、侵入性更低而受到称赞，但它缺少一些 IDE 集成。

动机、政治与生态系统担忧

  • Red Hat 对 Podman 的投入，被归因于与 Docker 合作尝试失败，以及对 Docker 在安全性、SELinux、systemd 和网络行为方面的不满。
  • 有人认为 Podman 的存在，就像 Linux 与专有操作系统的关系一样，能对 Docker 的权力形成制衡。
  • 关于哪家公司更值得信任也存在争论；对 Red Hat/IBM 与 Docker 的看法不一，但 Podman 的完全开源性质被视为一种安全网，以防企业方向改变。

痛点与替代方案

  • Podman 的 UID/GID 映射、ACL 和标签会让新用户感到困惑；早期采用者表示“它并不是开箱即用”，而且 podman system migrate 可能会把配置搞坏。另一些较晚开始使用的人则觉得它比 Docker 更容易。
  • 某些工作负载无法轻松以无 root 方式运行（例如 NFS 挂载），这限制了无 root Podman/Docker 在这些环境中的价值。
  • 少数人在某些用例中会绕开 Docker 和 Podman，直接使用 bubblewrap 或 Buildah，并批评 Dockerfile 是一种不必要的 DSL。