docker 与 podman 的故事：一个方兴未艾，一个异军突起



摘要：podman虽然与docker有替代关系，但是在“弃用docker”事件中，podman并非是主角。Kubernetes所进行的“弃用docker”的主角是CRI的其他实现方式，而由RedHat推出的podman则更加前沿。在现实的应用中，docker方兴未艾，podman却已经异军突起。

1 podman是什么？

podman（Pod Manager）是一个由RedHat公司推出的容器管理工具，它的定位就是docker的替代品，在使用上与docker的体验类似。podman源于CRI-O项目，可以直接访问OCI的实现（如runC），流程比docker要短。





二者主要的区别在于，podman是一个开源的产品；而docker已经是商业化的产品。

podman的开源代码，由RedHat的OpenShift项目维护。podman.io上面的文档还不算很健全，作为普通开发者，将其当成docker去用，难度也不算很大。

https://podman.io/

https://github.com/containers/podman

虽然RedHat推行podman的方式，还有一些“象牙塔”、“学院派”，但由于docker自身的问题，从开源社区江湖地位的考虑，podman有替代昔日docker地位的趋势，甚至可以说是大势所趋。

2 podman和Docker的主要区别是什么？

dockers在实现CRI的时候，它需要一个守护进程，其次需要以root运行，因此这也带来了安全隐患。

podman不需要守护程序，也不需要root用户运行，从逻辑架构上，比docker更加合理。

在docker的运行体系中，需要多个daemon才能调用到OCI的实现RunC。



在容器管理的链路中，Docker Engine的实现就是dockerd daemon，它在linux中需要以root运行，dockerd调用containerd，containerd调用containerd-shim，然后才能调用runC。顾名思义shim起的作用也就是“垫片”，避免父进程退出影响容器的运训。

podman直接调用OCI runtime（runC），通过common作为容器进程的管理工具，但不需要dockerd这种以root身份运行的守护进程。

在podman体系中，有个称之为common的守护进程，其运行路径通常是/usr/libexec/podman/conmon，它是各个容器进程的父进程，每个容器各有一个，common的父则通常是1号进程。podman中的common其实相当于docker体系中的containerd-shim。

下图常用来描述podman与docker的区别。





图中所体现的事情是，podman不需要守护进程，而dorker需要守护进程。在这个图的示意中，dorcker的containerd-shim与podman的common被归在Container一层。

3 podman的使用与docker有什么区别？

podman的定位也是与docker兼容，因此在使用上面尽量靠近docker。在使用方面，可以分成两个方面来说，一是系统构建者的角度，二是使用者的角度。

在系统构建者方面，用podman的默认软件，与docker的区别不大，只是在进程模型、进程关系方面有所区别。如果习惯了docker几个关联进程的调试方法，在podman中则需要适应。可以通过pstree命令查看进程的树状结构。总体来看，podman比docker要简单。由于podman比docker少了一层daemon，因此重启的机制也就不同了。

在使用者方面，podman与docker的命令基本兼容，都包括容器运行时（run/start/kill/ps/inspect），本地镜像（images/rmi/build）、镜像仓库（login/pull/push）等几个方面。因此podman的命令行工具与docker类似，比如构建镜像、启停容器等。甚至可以通过alias docker=podman可以进行替换。因此，即便使用了podman，仍然可以使用docker.io作为镜像仓库，这也是兼容性最关键的部分。

下图表示docker、podman的二级命令，它们相当接近。





podman相比docker也缺失了一些功能，比如不支持windows，不支持docker-compoese编排工具。显然在Kubernetes或者OpenShift体系中，这些并不重要。

4 podman相关的东西还有什么？

podman是github的Containers项目的一部分，这里面还包括几个相关的项目，它们都是用go语言组成的。





下面是podman、buildah、skopeo三个软件的图标。





podman、buildah、skopeo组成了一个完整的容器工具体系：

• podman项目对标的是docker命令的代替，官方说明是A tool for managing OCI containers and pods

• buildah项目实现的是dockerfile的脚本化执行，官方说明是A tool that facilitates building OCI images

• skopeo项目负责处理镜像相关的工作，比如检查、复制、签名，官方说明是Work with remote images registries - retrieving information, images, signing content

buildah完成对镜像的操作，类似docker build，也可以进行push等操作；skopeo完成对镜像仓库的操作，包括cp、inspect、delete等操作。它们的功能都比较纯粹，它们都是对podman功能的补充。

在Centos 8中，已经不适用docker作为默认的容器化工具，替代品也就是使用podman、buildah、skopeo。