提到podman就不能不说说OCI，这个组织有点意思。Docker容器技能涌现并且迅速风靡环球，为传统的持续集成与持续发布领域带来了革命性的变革。 这个时候各个大佬们（谷歌，Redhat、微软、IBM、Intel、思科）就有点坐不住了，大家一起喝喝茶聊谈天就决定要成立一个新的组织：OCI。这个组织成立的目的很明显，便是要防止容器技能被docker一家垄断。docker方面虽然心不甘、情不愿，但是也没有什么太好的办法，也加入了该组织，毕竟胳膊拧不过大腿。其余还有以下几个缘故原由
docker的容器观点和设计很新颖，但是底层实现并不是什么高精尖的技能，很随意马虎被模拟。docker方面希望被推广利用，离不开大佬们的支持。docker本身还存在几个硬伤，确实随意马虎被超越和追赶。有的朋友说podman是docker运行、构建、共享的赞助工具，这么说并禁绝确哈，podman目前的发展其本身便是一种独立的容器技能，其运行时环境不依赖于docker。
二、docker有什么硬伤？硬伤一：docker存在一个名为dockerd 的进程，会占用比较多的CPU资源。同时一个dockerd守护进程还可能导致单点故障的问题，该守护进程挂掉了，容器也就无法正常供应做事。硬伤二：docker守护进程以root用户运行，这给操作系统的安全性和容器安全性带来了非常大的寻衅。然而Podman 不须要以 root 身份运行的守护进程，Podman 容器的运行权限与启动它们的linux用户相同，这办理了一个重大的安全问题。Podman 是一个无守护进程的容器引擎，并且Podman 不须要守护进程来启动和管理容器。这是两个开源项目之间的一个最主要差异。这也是笔者看好podman未来会代替docker成为主流容器技能的核心缘故原由。
如果你利用过docker的CLI命令行，podman险些没有任何的差异，只须要把docker换成podman即可，参数顺序、含义都是一样的。如：
docker pull nginx换成podman pull nginx即可
如果你不想将docker命令换成podman，由于这样须要修正以往的脚本。也可以通过映射命令alias docker=podman来实现，这样就可以无缝地将docker迁移到podman环境下利用。
其余容器镜像格式方面在 Docker 和 Podman 之间也是完备兼容的。以是现有的镜像，不论是docker官方镜像，还是我们以往自己构建的docker镜像，都可以在podman环境下利用。
四、上手podman4.1.安装下面我们就来大略的搞一搞，在CentOS操作系统可以直策应用yum命令安装podman。事先解释的是我这个是一台新的最小化安装的CentOS7虚拟机，并不包含docker，也未曾安装。
yum -y install podman # root用户安装
查看版本
# podman versionVersion: 1.6.4RemoteAPI Version: 1Go Version: go1.12.12OS/Arch: linux/amd64
新建podman用户，后续利用该用户运行的容器。
adduser podman # root用户新建podman用户4.2.CentOS7环境下须要做的分外处理
出于上文中所说的安全性考虑，我们不该用root用户操作镜像及容器。以是须要做如下的一些配置。如果你利用CentOS7，须要做如下的一些分外处理。其他的操作系统可能须要不同的办理方案，这些办理方案基本大同小异。
如果你利用root用户运行镜像容器，这些分外处理就不须要做，直接就可以用
CentOS7默认关闭用户namespace，将它打开
echo 10000 > /proc/sys/user/max_user_namespaces;grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)";echo "user.max_user_namespaces=10000" >> /etc/sysctl.conf;4.3. 配置非root用户id及组id范围
考试测验在linux宿主机操作系统新建用户podman用户环境下实行nginx镜像拉取
su - podman # 切换用户为podmanpodman pull docker.io/library/nginx # 实行拉取镜像
如果你有如下的报错信息
ERRO[0000] cannot find mappings for user podman: No subuid ranges found for user "podman" in /etc/subuid
或者如下报错信息
Error processing tar file(exit status 1): there might not be enough IDs available in the namespace
请退出podman用户切换回到root用户（exit命令），实行下列命令，podman为运行容器的一个非root用户
echo "podman:100000:65536" >> /etc/subuidecho "podman:100000:65536" >> /etc/subgid
这段配置的浸染便是设置一个容器内的操作系统与宿主机操作系统用户的uid、gid之间的映射关系。如上所示 100000 - 165535(100000 + 65535) 在宿主机的id就映射到容器内的 0-65535的用户。配置完之后实行如下命令
podman system migrate
官方阐明上面的命令可以让配置生效，但是不知道什么缘故原由，笔者实行该命令时配置并未生效，而是重启了一下操作系统才生效。
五、在非root用户下容器镜像的利用同样的先把root切换到宿主机的podman用户
su - podman
拉取镜像命令
$ podman pull docker.io/library/nginxTrying to pull docker.io/library/nginx...Getting image source signaturesCopying blob 1ae07ab881bd done Copying blob 091c283c6a66 done Copying blob 78091884b7be done Copying blob 5eb5b503b376 done Copying blob b559bad762be done Copying blob 55de5851019b done Copying config c316d5a335 done Writing manifest to image destinationStoring signaturesc316d5a335a5cf324b0dc83b3da82d7608724769f6454f6d9a621f3ec2534a5a
查看镜像列表（在x用户下拉取的镜像，在y用户下是查看不到的）
$ podman imagesREPOSITORY TAG IMAGE ID CREATED SIZEdocker.io/library/nginx latest c316d5a335a5 2 weeks ago 146 MB
运行容器镜像
podman run -p 8080:80 -d docker.io/library/nginx
其他的命令就不一一的列举了，和docker命令运行办法是千篇一律的，参数顺序、名称也是千篇一律的。
总结在单机环境下docker可以无缝地切换到podman环境，对docker-swarm或dcoker-compose支持须要验证，但笔者险些从来不用这两个东西，以是暂时没有验证的动力。至于与k8s的兼容性，我想这是一定的，而且会越来越好，由于OCI组织的首席大佬便是谷歌，不可能不支持自己的产品之间的兼容性。如果你利用root用户操作podman容器，与docker险些是千篇一律的，乃至连命令行都不须要改。但是我们用podman代替docker的紧张缘故原由我想便是利用非root用户，来提升容器安全性。以是不同的操作系统及版本须要针对非root用户的权限做一些额外配置，从而来知足利用哀求。
