如果您进入虚拟化和容器化领域，您可能遇到过 Podman 和 Docker，您可能想知道它们之间有何不同。
在这篇文章中，我们将探讨 Docker 和 Podman 之间的区别，并尝试找出最适合您的选择！
目录
码头工人
Docker 是一种容器化技术，可促进项目中所有级别（开发和部署）的依赖项管理。
在 Linux、Windows 和 Mac OS 上可用，Docker 的机制以容器及其编排为中心，这就是容器化与虚拟化的不同之处。
Docker 有两个主要构建块：Docker CLI 和 Docker Daemon。
码头工人守护进程：
它是一个持续的后台进程，有助于管理 Docker 映像、容器、网络和存储卷。 Docker 使用其 Docker Engine REST API 与通过 HTTP 协议访问的 Docker 守护进程进行交互。
码头工人命令行界面：
图片来源：Redhat
它是用于与 Docker 守护进程交互的 Docker 命令行客户端。 这是您在运行任何 Docker 命令时使用的内容。
Docker的运行是基于Linux内核和这个内核的功能，比如cgroups和namespaces。 这些功能将进程分开，以便它们可以独立运行，因为容器的目的是分别运行多个进程和应用程序。
与单独的系统相比，这使得在不降低安全级别的情况下优化基础设施的使用成为可能。
Docker 等所有容器工具都带有基于映像的部署模型。 此模型简化了跨多个环境共享应用程序或服务集。
此外，Docker 有助于在容器环境中自动部署应用程序。 通过这些不同的工具，用户可以获得对应用程序的完全访问权限，并可以加速部署、控制版本和分配它们。
波德曼
Podman（POD MANager）构建、运行和管理 OCI 容器和容器镜像。 它由 Red Hat 开发，最初用于其企业 Linux 8。它用于容器管理，是 Docker 的正式继承者。
Red Hat 因此停止了对 Docker 的支持，但保证这种转换对用户来说很容易，因为 Podman 是基于 Docker 的，尽管最初它只是作为一个调试工具。
它使用 libpod 库管理整个容器生态系统。 由于 Podman 仅适用于 Linux 平台，因此目前正在开发 REST API 和客户端以允许 Mac 和 Windows 系统调用该服务。
但是，目前有一个基于 Varlink 的远程客户端可以在 Mac 或 Windows 平台上运行，它允许与基于 Linux 的 Podman 服务器进行远程通信。 libpod 库支持多种安全上传图片的方法，包括信任和图片验证。
它还支持 pod 来管理容器组和多种图像格式，包括 OCI 和 Docker 图像格式。
在非常小且易于管理的环境中，Podman 甚至可以作为 Kubernetes 的前身。 它弥合了早年容器炒作对单个实例的单一管理与使用 Kubernetes 进行现代编排之间的差距。
雄心勃勃的容器用户已经可以享受 pod 的下一个层次。 不再需要 Kubernetes 集群的构建和运行。 在最简单的情况下，新设计的吊舱可以在单独的操作中进行测试和改进。 甚至可以随后转移到 Kubernetes。
命令 podman generate kube 提供相应的配置文件。 然后，它们一对一地作为 Kubernetes 工具 kubectl 的输入。
当前版本的 Podman 甚至可以为 systemd 创建配置文件——对于使用无处不在的 init 继任者进行容器编排的任何人来说，这是一种享受。
Podman 与 Docker：差异
Docker 已迅速成为管理容器的木马。 然而，Docker 有很多优点，最重要的是，快速增长的图像库，以及缺点和可能的安全风险。 此外，不再支持将 Docker 作为 Kubernetes 的容器。
与虚拟系统相比，容器不需要其内核这一事实通常被视为一大优势。 但是，它给 Docker 带来了重大的安全风险，因为 Docker 容器只能以 root 权限运行。
它允许在容器中运行的进程以 root 权限访问内核，从而攻击主机系统。
当您第一次使用它时，第一个区别是显而易见的。 虽然 Docker 需要先启动 Docker 守护进程，但可以直接从命令行启动 Podman 容器。 所以没有后台进程，应用程序只在需要的时候执行。
从安全角度来看，这很好，因为如果守护进程不必以超级用户权限全天候 24/7 运行，Podman 就不太容易受到攻击。 由于架构，Podman 不需要后台进程，这与 Docker 有根本区别。
Docker 遵循客户端-服务器模型，其中 Docker 客户端通过 API 与 Docker 守护进程通信，而 Podman 遵循 fork-exec 模型。 每个容器都作为 Podman 的子进程运行。
当 Podman 以普通用户权限运行时，会在首次使用时创建用户命名空间。 在用户命名空间中，Podman 以 root 权限运行，具有挂载文件系统和创建容器的权限。
因此，Podman 容器仅具有执行用户所具有的权限。 使用用户命名空间意味着每个用户都可以创建和管理自己的容器，但这些容器对其他用户和超级用户不可见。
由于 Podman 独立于 Docker 运行，开发者有很大的回旋余地，可以响应社区的意愿。 Podman 的有趣新增功能包括 mount/unmount 命令和 systemd 集成。
宿主机可以使用 mount/unmount 命令挂载容器的文件系统，例如访问或更改文件，然后再次卸载它们。
由于使用 Podman 的 Docker 中的守护进程，使用 systemd 监视容器不起作用，但可以通过 systemd 启动、监视甚至重新启动容器。
另外，Podman 提供了 podman generate systemd 命令，可以为各个容器生成相应的 systemd 服务，从而免去用户创建 systemd 服务的麻烦，也就是可以在宿主系统上进行集成。
Podman 和 Docker 之间的另一个重要区别是后者不会更改防火墙规则或当前的 dnsmasq 安装，因为它能够创建内部网络。 相比之下，Docker 必须覆盖防火墙规则才能启用容器间通信。
PodmanDockerArchitecture DaemonDaemon lessServices Management SystemdDocker EngineFirewall CompatibilityOverwrites firewall rulesRespects firewall rulesPlatformNative support for linuxLinux, Windows, and Mac
什么时候应该从 Docker 迁移到 Podman
如果您在基于 RHEL 的环境中部署容器，在这种情况下，您没有太多选择，只能使用 Podman，因为它是 RHEL 原生的。 如果您的部署容器很少，也可以迁移到 Podman 或选择 Podman 而不是 Docker。
但是，如果您想变得比这更复杂，可以在网络上拥有多个容器和一堆带有 docker-compose/podman-compose 的协调容器。 最好使用 Docker，因为它可以更好地处理网络。
同样，如果您刚刚开始进入容器世界，在这种情况下，Docker 是一个更好的选择，因为它稳定、完善且有适当的文档，并且与 Podman 相比学习曲线较浅，Podman 仍然缺乏稳定性和没有明确定义的文档。
从 Podman 迁移到 Docker
如果你在命令行上，从 Docker Engine 切换到 Podman 是相当容易的。 在最简单的情况下，$ 别名执行 docker=podman 命令大部分时间都有效。
当然，这是假设系统上安装了合适的软件。 对于 Linux，这也不是问题。 现成的软件包可用于商业发行版。
Windows 或 macOS 不在受支持的操作系统之列。 别名方法之所以有效，是因为许多 Docker 命令都有一个 Podman 等效命令。
但也有例外，因为一些 Docker 命令在 Podman 世界中没有对应命令。 同样，一些命令在 Docker 中的行为与在 Podman 世界中的行为不同。 目前，这只会影响已设置的卷的处理。
当使用 Docker Desktop 等图形工具时，切换会有点困难。 它应该特别影响那些使用 Windows 或 macOS 的开发人员。
Docker Desktop 用户将不得不习惯命令行，这同样适用于 Docker compose。 但是，有 podman-compose 项目。 该软件用 Python 编写，可替代 Docker compose。
最后的话
Podman 对 Docker 的替代也算是大功告成了。 对于用户和管理员来说，此更改的大多数方面都很容易。 许多 Docker 功能在 Podman 中具有相同的等价物。
真正的好处是没有单一的守护进程和 root 权限，更不用说容器组的自然使用了。 然而，值得一提的是，Docker 仍然是容器的主要技术，但从长远来看，这种情况很可能会发生变化。
您还可以探索一些 Docker 命令来管理容器。
