Podman 与 Docker 有什么不同?
Podman 和 Docker 这两种标准的容器化工具已经有近十年的历史了, 我们将对它们进行一下对比, 这两种技术虽有本质的不同, 但还是非常适合一起使用.
容器编排工具作为当今最重要的 web 开发技术之一, 众多强者都在尝试争夺这一行业的主导地位.
Podman 是 RedHat 的一款产品, 旨在使用类似于 Kubernetes 的方法来构建, 管理和运行容器, 作为一款主流容器的可靠替代产品, 它吸引了开发人员的关注.
Podman 和 Docker 这两种标准的容器化工具已经有近十年的历史了, 我们将对它们进行一下对比, 这两种技术虽有本质的不同, 但还是非常适合一起使用.
容器编排是什么?
容器作为独立的软件包, 包含代码及其依赖项: 库, 工具, 设置和运行时. 由于容器提供了更快的部署和可伸缩性, 并且可以在开发和阶段之间统一工作, 所以业界很快就采用了容器作为容器化架构的核心组件.
容器的轻量化, 便携, 安全, 提供了与任何环境兼容的独立空间. 通过将软件与操作系统分离, 容器可以被移植到任何地点(例如, 从 Linux 到 Windows 系统), 从而避免了一些不必要的 bug 和报错.
比较流行的编排技术有 Docker,Docker Swarm, Kubernetes 和 Nomad, 所有这些我们已经在我们的博客中分析和比较了.
Docker 什么?
Docker 是标准的容器管理技术. Docker 在行业中举足轻重, 以至于大多数人一想到容器, 就会想到 Docker.
Docker 是容器编排世界的一把瑞士军刀, 在其他替代方案出现之前就已经提供了诸多特性. 随着容器管理复杂度的增加, 它也必须成长为一个独立的, 自给自足的工具, 以便能提供开发人员的所有需求.
Docker 也在很短的时间内, 就成为 All-in-one 解决方案的关键工具之一. 其中一款就是 Docker Swarm, 这是一款由 Docker 原生的, 可以让你组建群集和调度 Docker 引擎, 以及用来创建和管理容器群的解决方案.
Docker 的诸多辅助工具处理所有与容器编排相关的任务, 从负载均衡到网络, 使其成为行业的首选, 不光是作为行业技术参考.
尽管 Docker 是一个强大的系统, 但这种自给自足的模式也有它的缺点. 虽然可以在开发的所有阶段创建和运行容器, 但其他工具在与 Docker 集成交互时或多或少存在些困难. 近年来, 随着许多其他用于特定任务的专用工具的出现, Docker 成为许多开发人员的起点, 随之, 他们将一些任务分配给其他更轻量级的平台和工具.
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 接口.
Podman vs Docker: 区别
Podman 和 Docker 有许多共同的特性, 但也有一些根本的区别. 技术不分好坏, 只是着重于哪个更适用于某些特定的场景.
架构
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 采用模块化的方法, 依靠专门的工具来完成特定的任务.
Podman vs Docker: 他们能合作吗?
作为最好的, 最易应用于 Docker 的替代方案 -- 用户可以将 Docker 别名设置为 Podman(别名 Docker=Podman), 且不会出现任何问题, 正如本演示中所示 --Podman 是一个非常强大的容器化任务工具.
Podman 会是 Docker 的替代品吗?
如果你要从头开始一个项目, Podman 可以是一个首要的容器化技术选项. 如果项目正在进行, 并且已经在使用 Docker, 这还需要具体情况具体分析, 实际情况并不一定值得去改. 而且作为一款 Linux 原生的应用, 它要求相关开发人员具备 Linux 的相关技能.
开发人员可以在开发阶段依赖 Docker, 然后在运行时环境中将项目推向 Podman, 从而结合使用这两种工具, 并受益于 Podman 所提供的更安全性. 由于它们都是 OCI 兼容的, 因此, 兼容性不是个问题.
Docker 和 Podman 能共存吗? 是的, 而且会很好. 许多开发人员一直在合用 Docker 和 Podman 来创建更安全, 更高效, 更敏捷的框架. 它们有很多共同之处, 无论是从 Docker 到 Podman 的转变, 亦或是二者合并使用, 都可以做到无缝衔接.
你可以通过此链接在 Linux 机器上直接使用 Podman, 如果手边没有, 也可以在线试用一下.
来源: http://developer.51cto.com/art/202201/699378.htm