显然，目前围绕Red Hat的关注点完全不同且非常全球化，但我们仍在谈论我们自己的-本地的和在容器世界中应用的。 从今年年初开始，Red Hat一直在积极地开发名为
Podman （或
libpod ）的Docker替代品。 由于某些原因，他们还没有写过这个项目的书，现在是一个了解他，了解其起源和思考前景的好时机。 走吧
CRI-O作为背景故事
如果您看一下Linux容器的现代世界，很容易看到今天的文章只是Red Hat长期战略的一个阶段。 我们
一年前
写 的CRI-O项目就是对此的生动证实。 简而言之，CRI-O是Kubernetes CRI（容器运行时接口）接口的实现，用于启动与OCI标准（开放容器倡议）兼容的容器运行时。 更短地说，这是Docker作为Kubernetes的运行时的替代品。
（来自Docker Inc.的K8的技术上类似的举措是cri-containerd ，我们也写过此文章；在同一篇文章中，对这两种解决方案的性能进行了比较。）CRI-O的历史是如此悠久，以至于OCI正在准备容器标准（
运行时规范和
映像规范 ）
（但是，在Red Hat的参与下也发生了） ，创建了一个名为OCID的新项目，并将其放置在RH的Kubernetes孵化器中（ Open Container Initiative守护程序），后来[OCI请求]重命名为CRI-O。 其目的是“为Kubernetes中的容器的运行时环境实现标准接口”，并且作为一个大型项目Red Hat的一部分，进行了“技术批量”推广，以创建容器的操作系统-Project
Atomic 。
KubeCon + CloudNativeCon North America 2017上带有CRI-O徽标的瓶盖在过去的时间里，CRI-O已经发展到
1.0版 ，并在Minikube中
得到了支持，其最后的成就可以被视为在
Kubic项目中 采用了默认的容器接口，其中最引人注目的是由竞争性社区（针对Red Hat）开发的Linux发行版-openSUSE。
回到文章的主题：Podman最初是CRI-O的一部分。
Podman的外观和本质
Podman项目的正式宣布（名称是“ pod manager”的简称）
于今年2月举行：
“自去年夏天以来，就已经存在Podman（以前称为kpod）。 最初，它是CRI-O项目的一部分。 我们将podman分配到一个单独的项目libpod 。 我们希望Podman和CRI-O都能按照自己的步伐发展。 两者都可以单独运行（作为独立的实用程序），也可以一起运行。”
因此，公告本身被称为“
重新介绍” 。 Podman的第一个公开发行版本-v0.2-在此公告发布前2周进行。 那么Podman的本质是什么？
Podman的目标是提供一个控制台界面，用于在业务流程系统外部启动容器。 值得注意的是，启动的容器可以与具有常用名称空间的特殊组组合在一起，即 pods-感谢Kubernetes，这个概念已经广为人知。 该项目遵循UNIX命令的思想，其中每个实用程序只做一件事情，但是很好。 声明中已经引用了开发人员不懈强调的另一个重要细节：Podman可以与CRI-O一起使用，也可以独立使用。
总的来说，Podman的主要思想是为选择CRI-O作为容器运行时的Kubernetes用户提供类似于Docker CLI控制台界面（用于与在集群中运行的容器和映像进行交互）的模拟：
“ Podman实现了Docker 1.13中定义的40个Docker CLI命令中的38个命令（在2月发布之时- 大约是Transl。 ），但是其中一些我们没有特别重复。 例如，与Docker Swarm相关-相反，对于需要编排的pod /容器，我们建议使用Kubernetes。 此外，未实现用于Docker插件的某些命令，例如卷插件和网络命令。 可以在Podman使用转移页面上找到Docker中Podman命令及其等效命令的完整列表。”
Docker和Podman命令比较表的一部分：它们大多数相同，但也有区别但是，界面中此可见身份的背后是架构上的根本差异：如果Docker CLI与Docker守护程序通信以执行命令，则Podman是独立的实用程序，不需要任何守护程序即可工作。
至少由于这种架构上的差异，将Podman与Docker这样，而不是与
cri-tools的控制台实用程序crictl（尤其是用于
将容器化的容器与Kubernetes
集成 ）进行比较，将Podman与之比较是更正确的。 功能上也有所不同：Podman可以重新启动已停止的容器，还可以管理容器映像。 （有关更详细的比较，请参见
OpenShift博客 。）
随着Fedora 28 Atomic Host（今年5月）的发布，Podman已成为该Linux发行版的默认容器管理工具。 直到最近，在9月的Linux会议上，All Systems Go！ 在柏林，红帽容器工程团队的负责人丹·沃尔什（Dan Walsh）向更广泛的受众介绍了Podman-在
此处可以看到性能记录（但
此处仅作演示）。
Podman在所有系统上的演讲Go！ 2018年技术说明
Podman的最新版本是
v0.10.1.3 （日期为10月18日），最新的最新功能是
v0.10.1 （10月12日），其中合并了几个新团队和其他标志。
Podman代码使用Go编写，并根据免费的Apache License 2.0分发。 现成的软件包可用于Fedora 27版和更高版本（还有Ubuntu
的安装
指南 ）。 Podman可以使用的依赖组件包括Linux容器（如
runc和
conmon）的实用程序，以及
CNI网络插件 。
从Podman启动容器然后再使用它都类似于通常的
docker使用场景：
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
对于Podman的实用介绍，您还可以使用相应的Katacoda在线脚本：“
没有Docker的容器-使用Podman和Libpod启动容器 。”
最后，值得一提的是
pypodman项目，该项目正在积极开发中，它提供了Python编写的接口来远程执行Podman命令。
不只是Podman：libpod与生态系统
与Podman一起，本文反复提到了libpod项目。 有什么区别？
如果我们谈论Red Hat的“完整”项目，那么它实际上称为libpod，并以该名称
托管在GitHub上 。 如今，libpod被定位为“一个需要使用容器炉床概念的应用程序的库，该库已由Kubernetes推广”。 Podman本身是libpod库一部分的实用程序。
如果我们回到容器的更广阔的视野，那么Red Hat将拥有自己的愿景，它将在所有场合中使用一整套实用程序来实现。 他们中的大多数都集中在名称为
github.com/containers的存储库中，仅此一个就已经表明了该公司的雄心壮志
（顺便说一下，其中一些项目曾经位于github.com/projectatomic ） 。
在libpod项目的自述文件中直接
阐述了Red Hat关于标准化和开发容器生态系统的观点：
在
CRI-O审查中 ，我们已经写了几乎所有这些项目（runc，容器/映像，容器/存储，CNI，通用），但是自那时以来，一个重要的补充就是用于构建容器映像的实用程序
buildah 。 此外，Red Hat已经为现代容器世界的其他一些需求提供了现成的解决方案，例如用于生成SELinux的
udica和用于与远程图像注册中心配合使用的
skopeo安全配置文件。
总结
正如Red Hat不仅支持其OpenShift容器企业平台，而且还积极参与基础开源项目Kubernetes的生命一样，这家美国公司正在更基本的层面上实现对现代IT基础架构的看法-对于容器本身，DevOps和SRE工程师非常关心其编排。 Podman和libpod是Red Hat在开放标准容器世界中构建的整个生态系统的重要组成部分。 如果您了解正在发生的事情，那么本文开头提到的与IBM的交易是作为形成混合云领域领先的解决方案提供商而
提出的 ，在整个行业中看起来更加有趣...
最后，在本文出现之前，我提出了一份关于哈布拉（Habra）读者关于Podman项目知识的小型调查。 感谢您的参与！
聚苯乙烯
另请参阅我们的博客：