Docker 大势已去，Podman 万岁

前言

郑重声明：本文不是 Podman 的入门篇，入门请阅读这篇文章：再见 Docker，是时候拥抱下一代容器工具了

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，并传递到容器进程以便使用它们。

总结

以上就是将博客从 Docker 迁移到 Podman 的所有变更操作，总体看下来还是比较曲折，因为 Podman 是为 Kubernetes 而设计的，而我要求太高了，就一个资源紧张的 vps，即不想上 Kubernetes，也不想上 etcd，既想搞 sidecar，又想搞自动服务发现，我能怎么办，我也很绝望啊，这个事怨不得 podman，为了防止在大家心里留下 “podman 不好用” 的印象，特此声明一下。啥都不想要，只能自己想办法了~~

 

详见此文章：

https://blog.csdn.net/alex_yangchuansheng/article/details/102618128?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2.control