Podman Compose 指南：告别 Docker Daemon，拥抱无根容器

在容器化的世界里，Docker Compose 几乎是开发环境编排的标准。但是，随着 Docker Desktop 许可协议的变更，以及对安全性（Rootless）和轻量级（Daemonless）需求的增加，越来越多的开发者开始寻找替代品。

Podman 就是那个最强有力的挑战者。而 Podman Compose，则是让这一切变得平滑迁移的关键。

为什么要用 Podman？

在深入 Podman Compose 之前，先简单回顾一下 Podman 相对于 Docker 的三大核心优势：

无守护进程（Daemonless）：Docker 需要一个一直在后台运行的守护进程（Docker Daemon），如果它挂了，你的所有容器都得挂。Podman 是直接与 Linux 内核交互的，没有这个单点故障。
无根模式（Rootless）：Docker 默认需要 Root 权限，这意味着容器内的漏洞可能危及宿主机。Podman 默认允许非 Root 用户运行容器，安全性大大提升。
原生 Pod 支持：Podman 的名字来源于 Pod（豆荚）。它直接支持 Kubernetes 的 Pod 概念，允许你在一个 Pod 里运行多个容器，共享网络和存储。这也是它向 K8s 迁移更丝滑的原因。

简单来说，Podman Compose 是一个社区驱动的工具，它实现了 Docker Compose 的规范（Spec）。

原本 Podman 希望用户使用 Kubernetes 的 YAML 来编排容器（通过 podman play kube），但这对于习惯了 docker-compose.yaml 的开发者来说，学习成本有点高。

于是，Podman Compose 出现了。它的工作原理很简单：读取你的 docker-compose.yaml 文件，然后把它翻译成 Podman 的命令来执行。

这意味着，你现有的 docker-compose.yaml 文件，绝大多数情况下可以直接用！

在 macOS 上，你可以通过 Homebrew 轻松安装：

brew install podman podman-compose

安装完成后，你需要初始化一个 Podman 虚拟机（因为 macOS 是 Unix 系统，需要一个 Linux 内核来运行容器）：

podman machine init
podman machine start

假设你有一个标准的 docker-compose.yaml：

version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"

你只需要把命令中的 docker-compose 换成 podman-compose：

# 启动服务
podman-compose up -d

# 查看日志
podman-compose logs -f

# 停止服务
podman-compose down

如果你不想改习惯，可以直接给 podman-compose 设置一个别名：

alias docker-compose=podman-compose

这样，你就在不知不觉中切换到了 Podman 的世界。

虽然 Podman Compose 兼容性很好，但毕竟底层机制不同，有几点需要注意：

Socket 映射：某些工具（如 Portainer）依赖 Docker Socket (/var/run/docker.sock)。Podman 也有 Socket，但路径不同。你需要开启 Podman Socket 服务并正确映射。
网络：Podman 的网络模型（尤其是 Rootless 模式下）与 Docker 略有差异，跨容器通信通常没问题，但在复杂的自定义网络配置下可能需要调整。
Pod 的魔法：你可以尝试把一组相关的容器放在同一个 Pod 里。这是 Docker Compose 做不到的体验。

Podman Compose 是摆脱 Docker Desktop 依赖的最佳途径。它让你保留了熟悉的 docker-compose.yaml 流程，同时享受到了 Podman 带给你的安全性和轻量级优势。

如果你还在犹豫，不妨先在一个小项目上试一试。你会发现，没有 Daemon 的日子，也挺清爽的。

📝 本文受 DataCamp 教程启发，详细介绍了 Podman Compose 的核心概念与迁移指南。

📢 公众号

💬 个人号