前言
鄭重聲明：本文不是 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