Podman 是一个虚拟容器工具，定位和 Docker 类似。简单来说，它也能跑容器、管理镜像、组织服务，理论上可以作为 Docker 的替代品。
它的优势主要有几个：
Podman 的优点
1. 权限隔离更安全
众所周知，给用户加入 docker 用户组，基本上就等于授予了接近 root 的权限。
所以在很多大公司的公共开发环境里，Docker 并不是随便能用的，docker用户随时可能变成“我不是 root，但我约等于 root”的奇妙存在。
Podman 在这方面要安全不少，尤其适合需要权限隔离的服务器环境。
2. 镜像和容器可以自动更新
Docker 想要定期更新镜像和容器，通常需要自己写脚本、配定时任务，或者额外引入工具。
Podman 在这方面的设计更现代一些，配合 systemd 等机制，可以更自然地实现自动更新。
3. 有一定性能优势
这个优势存在，但日常使用中感知不一定明显。
比如网络层面，因为 Podman 不依赖 Docker 那套 daemon 架构，理论上网络性能可能略好一些。
内存占用方面，因为没有常驻 daemon 进程，也会少占一点资源。至于能省多少？大概几十 MB 吧。
4. 免费，尤其适合公司环境
公司使用 Docker Desktop 是有授权成本的。如果不符合免费使用条件，理论上是可能收到律师函警告的。
因此不少公司为了省事，直接一刀切禁用 Docker Desktop。
Podman 的整体设计其实是领先于 Docker 的，尤其是在安全、架构和系统集成方面。
但问题是，它在很多细节上又非常折磨人。
1. 配置语言不够直观
Podman 相关工具使用的是 ini-like 的配置格式，而不是更现代化的 YAML。
这就导致配置的可读性和解释性下降。
Docker Compose 的 YAML 虽然也不是完美无缺，但至少大部分开发者一眼看上去结构更清晰。
Podman：
“先进的古典工艺”
2. 单文件变多文件，个人开发体验倒退
Docker Compose 的设计是一个主配置文件，也可以拆分多个子文件，比较自由。
Podman 则强制要求配置拆成多个文件，比如：
.container.pod.volume
而且这些文件还需要分门别类放在某个特定目录里。
在生产环境中，这种设计可能更规范、更系统化。
但在个人开发场景里，这**不是捣乱吗？
3. 生态支持比较残缺
随手测试一下最近常用的工具，比如 Dify、new-api，就会发现一个问题：
很多工具并没有官方支持 Podman。
Dify 还有一些用户在尝试用 Podman 跑，但遗憾的是，无法通过 Podman 相关工具链一次性顺利执行。
原因之一是 Docker 和 Podman 的网络配置存在差异，所以使用 Podman 时往往需要手动修改网络配置。
更让人无奈的是，相关问题几年前就有人提过 PR，但至今没有合并。
至于 new-api？
Podman? Who?
4. 工具链之间还会互相嫌弃
Podman 的部分工具链也有点微妙。
比如 podman-compose，如果系统里同时安装了 Docker 和 Podman，它可能会优先启动 Docker，需要额外手动配置。
这还算好的。
更糟糕的是，有些工具链在 Docker 和 Podman 同时存在时，干脆无法正常工作。
Podman 到底适合谁？
综合来看，Podman 非常适合一种场景：
公司内部小组在服务器上搭开发环境。
尤其是那些真正主流、成熟的开发工具，往往已经适配了 Podman。
而这种公司内部开发环境，恰好又非常需要 Podman 的权限隔离能力。
毕竟用Docker给新手（也可能是老手），轻则误操作破坏环境，重则绕过安全审查工具，给运维和安全团队制造惊喜和惊吓。
所以在企业服务器、小组共享开发机、受控开发环境里，Podman 的价值非常明确。
但它的定位又很尴尬
Podman 是一个定位非常奇怪的工具。
对普通用户来说，它不够方便。
对企业用户来说，生产环境我为什么不上k8s呢？
如果你搜索podman，会看到一把替代docker的软文，但目前为止，podman占用了10%左右，仅为对手的1/7。
总结
如果是个人用户设备，推荐docker
如果是小组共享设备，推荐podman
一句话总结：
人生苦短，我用docker
2 个帖子 - 2 位参与者