原文链接：Podman 使用指南

Podman 原来是 CRI-O 项目的一部分，后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似，不同的是 Podman 没有 daemon。以前使用 Docker CLI 的时候，Docker CLI 会通过 gRPC API 去跟 Docker Engine 说「我要启动一个容器」，然后 Docker Engine 才会通过 OCI Container runtime（默认是 runc）来启动一个容器。这就意味着容器的进程不可能是 Docker CLI 的子进程，而是 Docker Engine 的子进程。

Podman 比较简单粗暴，它不使用 Daemon，而是直接通过 OCI runtime（默认也是 runc）来启动容器，所以容器的进程是 podman 的子进程。这比较像 Linux 的 fork/exec 模型，而 Docker 采用的是 C/S（客户端/服务器）模型。与 C/S 模型相比，fork/exec 模型有很多优势，比如：

• 系统管理员可以知道某个容器进程到底是谁启动的。

• 如果利用 cgroup 对 podman 做一些限制，那么所有创建的容器都会被限制。

• SD_NOTIFY : 如果将 podman 命令放入 systemd 单元文件中，容器进程可以通过 podman 返回通知，表明服务已准备好接收任务。

• socket 激活 : 可以将连接的 socket 从 systemd 传递到 podman，并传递到容器进程以便使用它们。

废话不多说，下面我们直接进入实战环节，本文将手把手教你如何用 podman 来部署静态博客，并通过 Sidecar 模式将博客所在的容器加入到 Envoymesh 之中。

1. 方案架构

我的部署方案涉及到两层 Envoy：

• 首先会有一个前端代理单独跑一个容器。前端代理的工作是给访问者提供一个入口，将来自外部的访问请求转发到具体的后端服务。

• 其次，博客静态页面由 nginx 提供，同时以 Sidecar 模式运行一个 Envoy 容器，它与 nginx 共享 network nemspace。

• 所有的 Envoy 形成一个 mesh，然后在他们之间共享路由信息。

我之前写过一篇用 Docker 部署 hugo 静态博客并配置 HTTPS 证书的文章，本文采用的是相同的方案，只是将 docker 换成了 podman，具体参考为 Envoy 开启 TLS 验证实战。

2. 部署 hugo 和 sidecar proxy

我的博客是通过 hugo 生成的静态页面，可以将其放到 nginx 中，其他静态网站工具类似（比如 hexo 等），都可以这么做。现在我要做的是让 nginx 容器和 envoy 容器共享同一个 network namespace，同时还要让前端代理能够通过域名来进行服务发现。以前用 docker 很简单，直接用 docker-compose 就搞定了，podman 就比较麻烦了，它又不能用 docker-compose，服务发现看来是搞不定了。

好不容易在 Github 上发现了一个项目叫 podman-compose，以为有救了，试用了一下发现还是不行，podman-compose 创建容器时会将字段 network_mode: "service:hugo" 转化为 podman CLI 的参数 --network service:hugo（真脑残），导致容器创建失败，报错信息为 CNI network "service:hugo" not found。将该字段值改为 network_mode: "container:hugo_hugo_1" 可以启动成功，然而又引来了另一个问题：podman-compose 的做法是为每一个 service 创建一个 pod（pod 的名字为 docker-compose.yml 所在目录名称），然后往这个 pod 中添加容器。我总不能将前端代理和后端服务塞进同一个 pod 中吧？只能分别为前端代理和 hugo 创建两个目录，然后分别创建 docker-compose.yml。这个问题解决了，下个问题又来了，podman-compose 不支持通过 service name 进行服务发现，扒了一圈发现支持