容器编排工具作为当今最重要的Web开发技术之一，众多强者都在尝试争夺这一行业的主导地位。

Podman是RedHat的一款产品，旨在使用类似于Kubernetes的方法来构建、管理和运行容器，作为一款主流容器的可靠替代产品，它吸引了开发人员的关注。自RHEL 8起，Red Hat用CRI-O/Podman取代了Docker Daemon。为什么Red Hat想要摆脱Docker Daemon？这是因为使用Docker Daemon运行Docker有以下这些问题：

• 单点故障问题，Docker Daemon一旦死亡，所有容器都将死亡

• Docker Daemon拥有运行中的容器的所有子进程

• 所有Docker操作都必须由具有跟root相同权限的用户执行

• 构建容器时可能会导致安全漏洞

Podman通过直接与Image Registry、Image和Container进行互动，而不是通过守护进程来解决以上问题。此外，Podman还允许用户在没有完全root 权限的情况下运行容器。

更棒的是，它还提供了与Docker兼容的指令，使用户可以很轻易的从原本的Docker指令切换到Podman。

Podman和Docker这两种标准的容器化工具已经有近十年的历史了，今天这篇文章我们来对比下这两个技术，它们虽有不同，但还是非常适合一起使用。

— 1 —

Docker什么？

Docker是标准的容器管理技术。Docker在行业中举足轻重，以至于大多数人一想到容器，就会想到Docker。

Docker是容器编排世界的一把瑞士军刀，在其他替代方案出现之前就已经提供了诸多特性。随着容器管理复杂度的增加，它也必须成长为一个独立的、自给自足的工具，以便能提供开发人员的所有需求。

Docker也在很短的时间内，就成为All-in-one解决方案的关键工具之一。其中一款就是Docker Swarm，这是一款由Docker原生的，可以让你组建群集和调度Docker引擎，以及用来创建和管理容器群的解决方案。

Docker的诸多辅助工具处理所有与容器编排相关的任务，从负载均衡到网络，使其成为行业的首选，不光是作为行业技术参考。

尽管Docker是一个强大的系统，但这种自给自足的模式也有它的缺点。虽然可以在开发的所有阶段创建和运行容器，但其他工具在与Docker集成交互时或多或少存在些困难。

近年来，随着许多其他用于特定任务的专用工具的出现，Docker成为许多开发人员的起点，随之，他们将一些任务分配给其他更轻量级的平台和工具。

— 2 —

Podman是什么？

Podman是一种开源的Linux原生工具，旨在根据开放容器倡议（Open Container Initiative，OCI）标准开发、管理和运行容器和Pod。Podman是RedHat开发的一个用户友好的容器调度器，是RedHat 8和CentOS 8中默认的容器引擎。

它是一款集合了命令集的工具，设计初衷是为了处理容器化进程的不同任务，可以作为一个模块化框架工作。它的工具集包括：

• Podman：Pod和容器镜像管理器

• Buildah：容器镜像生成器

• Skopeo：容器镜像检查管理器

• Runc：容器运行器和特性构建器，并传递给Podman和Buildah

• Crun：可选运行时，为Rootless容器提供更大的灵活性、控制和安全性

这些工具还可以与任何OCI兼容的容器引擎（如Docker）一起工作，使其易于转换到Podman或与现有的Docker安装一起使用。Kubernetes可以使用Podman吗？答案是：是的。事实上，Kubernetes和Podman在某些方面是相似的。

Podman对于容器有着不同的方法论。正如它的名字所暗示的那样，Podman可以创建一起工作的容器“Pod”，这是一个类似Kubernetes里Pod的特性。Pod在一个共同的命名空间里，作为一个单元来管理容器。

比较主要的好处是开发人员可以共享资源，在一个Pod中为同一个应用程序使用不同的容器：一个容器用于前端，另一个容器用于后端，还有一个数据库。Pod的配置可以导到Kubernetes兼容的YAML文件，并应用到Kubernetes集群中，从而允许容器更快地进入生产。

Podman的另一个特性是它是无守护进程的。守护进程是在后台运行的程序，它处理服务、进程和请求，没有用户界面。Podman是一种独特的容器引擎，因为它实际上并不依赖于守护进程，而是作为子进程启动容器和Pod。

你可能会问：“我为什么要使用Podman？”作为一种开发和管理工具，Podman具有独特的优势，这使得它在适当的环境中成为Docker的可行和有趣的替代品。或者一个与Docker并肩工作的强大补充，因为它支持与Docker兼容的CLI接口。

— 3 —

Podman vs Docker：区别

Podman和Docker有许多共同的特性，但也有一些根本的区别。技术不分好坏，只是着重于哪个更适用于某些特定的场景。

Podman与Linux内核交互，通过runC容器运行时进程而不是Daemon来管理容器。Buildah实用程序用于替代Docker build作为容器镜像构建工具，Docker push被Skopeo替代，用于在注册表和容器引擎之间移动容器镜像。

架构

Docker使用守护进程，一个正在后台运行的程序，来创建镜像和运行容器。Podman是无守护进程的架构，这意味着它可以在启动容器的用户下运行容器。Docker有一个由守护进程引导的客户端——服务器逻辑架构；但Podman不需要此类守护进程。

Root特权

由于Podman没有守护进程来管理其活动，也无需为其容器分配Root特权。Docker最近在其守护进程配置中添加了Rootless模式，但Podman首先使用了这种方法，并将其作为基本特性进行了推广。原因如下。

安全

Podman比Docker安全吗？Podman允许容器使用Rootless特权。Rootless容器被认为比Root特权的容器更安全。在Docker中，守护进程拥有Root权限，这使得它们易成为攻击者的首选入侵点。

Podman中的容器默认情况下不具有Root访问权限，这在Root级别和Rootless级别之间添加了一个自然屏障，提高了安全性。不过，Podman可以同时运行Root容器和Rootless容器。

Systemd

如果没有守护进程，Podman需要另一个工具来管理服务并支持后台运行的容器。Systemd为现有容器创建控制单元或用来生成新容器。Systemd还可以与Podman集成，允许它在默认情况下运行启用了Systemd的容器，从而无需进行任何修改。

通过使用Systemd，供应商可以将他们的应用程序封装为容器用来安装、运行和管理，因为现在大多数应用程序都是通过这种方式打包和交付的。

构建镜像

作为一款自给自足的工具，Docker可以自己构建容器镜像。Podman则需要另一种名为Buildah的工具的辅助，该工具充分体现了它的特殊性：它是为构建镜像而设计的，而不是为构建容器而生。

Docker Swarm

Podman不支持Docker Swarm，这可能会在某些项目中被刨除在外，因为使用Docker Swarm命令会产生一个错误。然而，Podman最近增加了对Docker Compose的支持，使其与Swarm兼容，从而克服了这个限制。当然，Docker由于其原生的特性，与Swarm当然融合得很好。

All in one vs 模块化

也许这就是这两种技术的关键区别：Docker是一个独立的、强大的工具，在整个循环中处理所有的容器化任务，有优点也有缺点。Podman采用模块化的方法，依靠专门的工具来完成特定的任务。

— 4 —

Podman vs Docker：他们能合作吗？

作为最好的、最易应用于Docker的替代方案——用户可以将Docker别名设置为Podman（alias docker=podman），且不会出现任何问题，正如本演示[1]中所示——Podman是一个非常强大的容器化任务工具。

Podman会是Docker的替代品吗？

如果你要从头开始一个项目，Podman可以是一个首要的容器化技术选项。如果项目正在进行，并且已经在使用Docker，这还需要具体情况具体分析，实际情况并不一定值得去改。而且作为一款Linux原生的应用，它要求相关开发人员具备Linux的相关技能。

开发人员可以在开发阶段依赖Docker，然后在运行时环境中将项目推向Podman，从而结合使用这两种工具，并受益于Podman所提供的更安全性。由于它们都是OCI兼容的，因此，兼容性不是个问题。

Docker和Podman能共存吗？是的，而且会很好。许多开发人员一直在合用Docker和Podman来创建更安全、更高效、更敏捷的框架。它们有很多共同之处，无论是从Docker到Podman的转变，亦或是二者合并使用，都可以做到无缝衔接。

你可以通过此链接[2]在Linux机器上直接使用Podman，如果手边没有，也可以在线[3]试用一下。

相关链接：

1. https://www.youtube.com/watch?v=riZ5YPWufsY

2. https://github.com/containers/podman

3. https://www.katacoda.com/courses/containers-without-docker/running-containers-with-podman