podman安装以及使用

最新推荐文章于 2025-09-16 16:17:09 发布

原创

最新推荐文章于 2025-09-16 16:17:09 发布 · 4k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#linux

podman

文章目录

podman

1 Podman简介

Podman是一个开源项目，可在大多数Linux平台上使用并开源在GitHub上。Podman是一个无守护进程的容器引擎，用于在Linux系统上开发，管理和运行Open Container Initiative（OCI）容器和容器镜像。 Podman提供了一个与Docker兼容的命令行前端，它可以简单地作为Docker cli，简单地说你可以直接添加别名：alias docker = podman来使用podman。

Podman控制下的容器可以由root用户运行，也可以由非特权用户运行。Podman管理整个容器的生态系统，其包括pod，容器，容器镜像，和使用libpod library的容器卷。Podman专注于帮助您维护和修改OCI容器镜像的所有命令和功能，例如拉取和标记。它允许您在生产环境中创建，运行和维护从这些映像创建的容器（podman官网）

2 Podman工作机制

Podman 原来是 CRI-O 项目的一部分，后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似，不同的是 Podman 没有 daemon。以前使用 Docker CLI 的时候，Docker CLI 会通过 gRPC API 去跟 Docker Engine 说「我要启动一个容器」，然后 Docker Engine 才会通过 OCI Container runtime（默认是 runc）来启动一个容器。这就意味着容器的进程不可能是 Docker CLI 的子进程，而是 Docker Engine 的子进程。

Podman 比较简单粗暴，它不使用 Daemon，而是直接通过 OCI runtime（默认也是 runc）来启动容器，所以容器的进程是 podman 的子进程。这比较像 Linux 的 fork/exec 模型，而 Docker 采用的是 C/S（客户端/服务器）模型。与 C/S 模型相比，fork/exec 模型有很多优势，比如：

系统管理员可以知道某个容器进程到底是谁启动的。
如果利用 cgroup 对 podman 做一些限制，那么所有创建的容器都会被限制。
SD_NOTIFY : 如果将 podman 命令放入 systemd 单元文件中，容器进程可以通过 podman返回通知，表明服务已准备好接收任务。
socket 激活 : 可以将连接的 socket 从 systemd 传递到 podman，并传递到容器进程以便使用它们。

3 Podman与Docker的区别

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

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

3.1 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.2 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体系中，这些并不重要

用户操作

在允许没有root特权的用户运行Podman之前，管理员必须安装或构建Podman并完成以下配置

cgroup V2Linux内核功能允许用户限制普通用户容器可以使用的资源，如果使用cgroupV2启用了运行Podman的Linux发行版，则可能需要更改默认的OCI运行时。某些较旧的版本runc不适用于cgroupV2，必须切换到备用OCI运行时crun。

[root@localhost ~]# yum -y install crun     //centos8系统自带

[root@localhost ~]# vi /usr/share/containers/containers.conf 
    446 # Default OCI runtime
    447 # 
    448 runtime = "crun"      //取消注释并将runc改为crun

[root@localhost ~]# podman run -d --name web -p 80:80 docker.io/library/nginx
c8664d2e43c872e1e5219f82d41f63048ed3a5ed4fb6259c225a14d6c243677f

[root@localhost ~]# podman inspect web | grep crun
        "OCIRuntime": "crun",
            "crun",

安装slirp4netns和fuse-overlayfs

在普通用户环境中使用Podman时，建议使用fuse-overlayfs而不是VFS文件系统，至少需要版本0.7.6。现在新版本默认就是了。

[root@localhost ~]# yum -y install slirp4netns

[root@localhost ~]# yum -y install fuse-overlayfs
[root@localhost ~]# vi /etc/containers/storage.conf
77 mount_program = "/usr/bin/fuse-overlayfs"     //取消注释

/ etc / subuid和/ etc / subgid配置

Podman要求运行它的用户在/ etc / subuid和/ etc / subgid文件中列出一系列UID,shadow-utils或newuid包提供这些文件