前言

为什么要用 podman 代替 docker？podman 主要有以下优点：

• 支持免 root 启动容器
• 无守护进程
• 支持 k8s 样式的 yaml 配置文件

docker 现在也可以使用 -userns-remap 参数来免 root 运行守护进程了。

免 root 启动容器能够提升系统的安全性。虽然容器化技术能够较好的抑制容器内的恶意软件，但容器逃逸技术层出不穷，不使用 root 启动容器能够在容器逃逸后依旧保持一定的安全性。同时，免 root 启动容器使用户权限管理更简单了。

但是，免 root 启动容器有一些限制，举例如下：
– 需要设置用户的 subuid/subgid （大部分 linux 发行版会在 adduser 的时候自动设置这一项目）
– 需要使用 cgroups v2 （因为要用到 cgroups v2 才有的资源限制）
– 需要额外安装 slirp4netns 软件包（用于提供网络）
– slirp4netns 的最大吞吐量约为 11.2 Gbps，而 root 下的 bridge 模式最大吞吐量可达 40.1 Gbps.
– 无法绑定小于 1024 的端口
– 无法与其他使用 root 启动的容器共享镜像
– 文件系统需要使用 overlayfs (Linux 5.11+) 或 fuse-overlayfs（Linux 4.18+），fuse 版本的性能相对较低。

详细限制可以查看官方文档。

在 docker 中，所有的容器都是通过 docker 的守护进程来启动的。这个守护进程会与 containerd 通信，再调用 runc，最终启动目标进程。所有的 container 都是守护进程的子进程，守护进程因此可以管理各个 container。

与 docker 使用守护进程管理 container 不同，podman 更希望使用已有的 systemd 管理各个 container 的启停。在 podman 中，podman 会首先拉起 conmon，conmon 会拉起对应的 container，然后监控其状态 (即 Contanier Monitor) 。

从 docker 迁移到 podman

podman 的命令与 docker 的命令基本一致，你甚至可以直接使用 alias 将 podman 作为 docker 的别名。完整的命令兼容列表可以查看这个文档。

不过，podman 本体并没有构建镜像的能力。若需要构建镜像，你需要使用 buildah。buildah 本身也支持 dockerfile 文件，你可以直接使用 buildah bud 命令作为 docker build 命令的替代。

需要注意的是，podman 并不将 Docker Hub 作为镜像的缺省源。即在仅指定路径 “centos:8” 时，podman 并不会自动的将其转换为 “docker.io/centos:8”.

从 docker-compose 迁移到 podman

概念

podman 中有一些特有的概念，部分概念与 docker-compose 不一致，参见下表

综上所述，我们可以简单的将 compose 看作 podman 的 pod 和 service 的集合体。

podman 和 docker-compose 的网络模型也略有不同。同一个 pod 下的所有 container 共享同一个网络 namespace，它们之间可以直接通过 localhost 互相访问。而 docker-compose 的不同 service 是不同的网络 namespace，需要通过对方的名称才能互相访问。
从网络的角度来说，podman 的 pod 概念也可以对应 docker-compose 的 service。

方案选择

现在有三种编排方案可以选择：

• docker-compose: podman 自 v3.0 起提供了兼容的 API，docker-compose 可以直接使用 podman 作为后端了。需要使用以下命令启用服务:
  systemctl enable --now podman.socket
• podman-compose: 在配置文件兼容的情况下，实现了 docker-compose 功能的子集。其相较于 docker-compose 更轻量，会直接调用 podman 命令，对原生 podman 的功能（如 rootless）也有更好的支持。
• podman k8s yaml: podman 原生的编排方案，是 k8s 语法的一个子集，可以很方便地迁移到 k8s。

docker-compose 和 podman-compose 都是第三方的解决方案，需要额外安装软件才能实现。在这里，我们使用 podman 原生的 k8s yaml 支持来编排服务。

ref: podman 与 docker-compose, podman 与 k8s

文件格式

要对文件格式迁移，podman 官方建议首先替换 docker-compose 的 backend，然后使用 docker-compose 启动容器。

接下来，使用以下命令导出 pod:

$ sudo podman generate kube -s -f [export_yaml] [container1_id] [container2_id] ...

-s 参数指示需要生成服务（Service）用于导出端口，-f 参数指示保存到文件。

不过如果你已经很熟悉 k8s yaml 的格式的话，也可以手动迁移配置文件。

服务管理

Docker-compose 使用了守护进程管理各个容器的启动和重启等操作。podman 没有守护进程，我们可以使用系统自带的服务管理工具 systemd 管理各个 pod 的启停。

使用 podman generate systemd -f --new [podname] 即可自动生成对应的服务文件；将这一服务文件放到 systemd 文件目录下，即可使用 systemd 管理此 pod。在这个过程中，Podman 根据 container 和 pod 的 ID，生成了对应的命令，使得 systemd 能够正确的调用 podman 启动需要的资源。

ref: 使用 systemd 将 pod 运行为服务

更新

正如传统的 docker 一样，在 podman 中如果需要更新一个已有 container 的 image，则需要首先停止并移除这个 container，然后再重新启用一个新的 container。如果我们在之前生成了 systemd 文件，此时我们会需要重新再次生成一次新的 systemd 文件，以更新此文件中对应的资源 ID。
这项工作听上去就非常的麻烦，所以 Podman 提供了自动更新功能，用于一键更新所有 container 的镜像版本。

运行 podman auto-update 即可更新所有正在运行的 container。
这项功能有以下的限制：

• 需要是使用 –new 参数导出的 systemd service 文件启动的 container
• 需要设定 io.containers.autoupdate 标签，其值为 registry 表示升级到 registry 的版本，local 则表示升级到本地已有的版本
• 镜像引用不能是ID，必须是正常的url，否则无法正确新建 container

自动更新功能还提供了自动回滚的技术。如果一个服务在更新后无法正常启动，则 podman 会尝试将其回滚到之前能够正常启动的版本。Systemd 会根据进程的状态，更新对应 service 的状态；对于一些应用（如数据库），并不是进程在跑了就表示自身工作正常，此时 systemd 提供了一个 sd_notify 方法，用于通知 systemd 更新自身的状态。在默认情况下，conmon 会监控 container 的状态，再利用 sd_notify 机制更新服务的状态。如果需要让 container 里的进程自行使用 sd_notify 更新，可以使用 --sdnotify=container 参数设定，让 conmon 提供 sd_notify 代理服务。

ref: 自动更新与回滚

k8s yaml 格式的支持

详情可以参考官方手册。

简单来说，Podman支持以下四种类型的资源
– Pod
– Deployments
– PersistentVolumeClaim
– ConfigMap

对于 Pod 和 Deployment，Podman 只支持以下三种卷：
– hostPath：映射主机文件
– 支持 default (empty), DirectoryOrCreate, Directory, FileOrCreate, File, Socket, CharDevice, BlockDevice 设备类型
– 若值中含有斜杠，则视为文件路径；否则视为名字
– emptyDir: 提供一个空白文件夹，并在资源删除时删除
– persistentVolumeClaim

当然，由于 podman 只能在本地运行，所以 deployment 的所有的 replica 都会运行在本地。

对于 PersistentVolumeClaim，Podman 只需要名字（name）这一参数即可创建对应的资源。你也可以指定以下注解（annotation）来设定参数：

• volume.podman.io/driver
• volume.podman.io/device
• volume.podman.io/type
• volume.podman.io/uid
• volume.podman.io/gid
• volume.podman.io/mount-options

服务管理与自动更新

使用 k8s yaml 生成的 pod 不能通过 --new 参数生成 systemd 服务文件。若要使用 systemd 管理 k8s yaml 的 pod，一个简单的方法是使用以下命令:

$ escaped=$(systemd-escape ~/workload.yaml)
$ systemctl --user start podman-kube@$escaped.service
$ systemctl --user is-active podman-kube@$escaped.service

自动更新默认是不启用的，需要设定下列 annotation 控制更新的逻辑:
– io.containers.autoupdate: “registry|local” 控制所有 container 的更新逻辑
– io.containers.autoupdate/$container: “registry|local” 控制指定 container 的更新逻辑
– io.containers.sdnotify: “conmon|container” 控制所有 container 的 sdnotify 逻辑
– io.containers.sdnotify/$container: “conmon|container” 控制指定 container 的 sdnotify 逻辑

结语

podman 当前处于较为活跃的开发状态，上文所提到的一些功能需要在较新的 podman 版本下才能使用。同时，部分功能也需要依赖较高版本的内核。在写下本文的时候，podman 的最新版本 4.2.0 尚未进入各大发行版的默认仓库，主流的 LTS 内核也尚停留在 5.10 版本，这就意味着许多新功能（如 systemd 管理 k8s 样式的 pod）无法使用。

podman 的文档相对于 docker 可以说是少的可怜。官网仅给出了一些简单的示例，同时也给了非常详尽的命令行参考。但是，对于特定场景和特定功能的应用，你就需要去 redhat 的网站上找对应的博客。这些博客可以说的官方文档的一部分，但是它们却从未出现在官方网站上。

同时，podman 相对于 docker 的优势不大。实际上，podman 相对于 docker 的优点仅限于无守护进程、支持 k8s 样式的 yaml 文件以及自动更新回滚功能。

无守护进程听上去虽然很不错，但是它的代价是需要与 systemd 配合使用，这稍微增加了配置的复杂性。使用 systemd 管理各项服务确实是一个不错的选择，它能够提供统一的服务管理体验。然而如果是使用 k8s 的 yaml 文件创建的服务，其服务名称会变得非常长且丑，这非常影响使用体验。

在 k8s 已经成为容器编排的事实性标准的今天，使用 k8s 样式的文件可以很好的从 podman 迁移到 k8s，这无疑是一种较大的优势。但对于不需要往 k8s 迁移的应用来说，这其实并没有什么实际上的用处。

在当前状态下，对于使用 docker 作为对外服务的服务器来说，可以等待 podman 进入各大发行版后迁移。其 k8s 文件兼容特性和自动更新回滚功能对于服务器来说是非常有用的。而对以上优势没有感觉的个人来说，其实可以继续使用 docker 和 docker-compose，毕竟其文档充足而且使用简单。