Podman vs Docker:该选择哪一个?
如果你对虚拟化和容器化世界感兴趣,那么你可能已经遇到了Podman和Docker,并且你可能想知道它们之间有什么区别。
在这篇文章中,我们将探讨Docker和Podman的区别,并试图找到对你来说最合适的选择!
Docker
Docker是一种容器化技术,可以在项目的各个层面(开发和部署)上简化依赖管理。
Docker可在Linux、Windows和Mac OS上使用,其机制主要围绕容器及其编排展开,这就是容器化与虚拟化的区别所在。
Docker有两个主要构建模块:Docker CLI和Docker Daemon。
Docker Daemon:
它是一个常驻后台进程,用于管理Docker镜像、容器、网络和存储卷。Docker使用其Docker Engine REST API与Docker守护进程进行交互,通过HTTP协议进行访问。
Docker CLI:
它是与Docker守护进程交互的Docker命令行客户端。在运行任何Docker命令时使用该客户端。
Docker的运行基于Linux内核及其功能,如cgroups和命名空间。这些功能将进程分离,使其能够独立运行,因为容器的目的是独立运行多个进程和应用程序。
这使得在不降低安全性水平的情况下,优化基础设施的使用成为可能。
所有像Docker这样的容器工具都具有基于镜像的部署模型。该模型简化了在多个环境中共享应用程序或一组服务的过程。
此外,Docker还帮助自动化在容器环境中部署应用程序。借助这些各种工具,用户可以完全访问应用程序,并加速部署、控制版本和分配它们。
Podman
Podman(POD MANager)构建、运行和管理OCI容器和容器镜像。它由Red Hat开发,最初用于其企业Linux 8。它用于容器管理,并作为Docker的官方继任者。
因此,Red Hat放弃了Docker,并确保用户的转换将轻松进行,因为Podman是基于Docker开发的,尽管最初它只被视为一个调试工具。
它使用Containeer Image Spec(OCI)来管理整个容器生态系统。由于Podman只在Linux平台上工作,目前正在开发REST API和客户端,以允许Mac和Windows系统调用该服务。
然而,目前已经有了基于Varlink的远程客户端,可以在Mac或Windows平台上工作,允许与基于Linux的Podman服务器进行远程通信。libpod库支持多种安全上传镜像的方法,包括信任和镜像验证。
它还支持使用Pods一起管理多个容器和多种镜像格式,包括OCI和Docker镜像格式。
在非常小且可管理的环境中,Podman甚至可以作为Kubernetes的先导。它填补了容器热潮的早期年份中单个实例的单一管理与现代编排之间的差距。
雄心勃勃的容器用户已经可以通过使用Pods来享受到更高的水平。构建和操作Kubernetes集群不再是必需的。在最简单的情况下,新设计的Pods可以在单个操作中进行测试和改进。甚至可以随后迁移到Kubernetes。
命令podman generate kube
提供相应的配置文件。然后,这些文件可以作为输入逐一用于kubectl。
当前版本的Podman甚至可以为systemd创建配置文件-对于使用普遍的容器编排的人来说,这是一种享受。
Podman与Docker的区别
Docker迅速确立了自己作为管理容器的首选工具。然而,Docker具有许多优点,尤其是迅速增长的镜像库,以及一些缺点和潜在的安全风险。此外,Docker作为Kubernetes的容器可能存在。
与虚拟系统不同,容器通常被认为不需要自己的内核,这被视为一个巨大优势。然而,这对于Docker来说却是一个重大安全风险,因为只有使用root权限才能运行。
这允许在容器中运行的进程以root权限访问内核,从而攻击主机系统。
首次使用时就可以明显看出它们之间的区别。在启动Docker之前,需要先启动Docker守护程序,而Podman容器可以直接从命令行启动。因此,没有后台进程,只有在需要时才执行应用程序。
从安全角度来看,这是一个好事,因为如果守护程序不必以超级用户特权24/7运行,Podman就不容易受到攻击。由于Podman的架构与Docker根本不同,它不需要后台进程。
Docker遵循客户端-服务器模型,其中Docker客户端通过API与Docker守护程序通信,而Podman遵循分叉-执行模型。每个容器都作为Podman的子进程运行。
在使用普通用户权限运行Podman时,会创建一个用户命名空间。在用户命名空间中,Podman以root权限运行,并具有挂载文件系统和创建容器的权限。
因此,Podman容器只有执行用户拥有的权限。使用用户命名空间意味着每个用户都可以创建和管理自己的容器,但这些容器对其他用户和超级用户不可见。
由于Podman独立于Docker运行,开发人员有很大的余地可以响应社区的需求。Podman的一些有趣的补充包括挂载/卸载命令和systemd集成。
主机可以使用挂载/卸载命令挂载容器的文件系统,例如访问或更改文件,然后再次卸载。
虽然由于Docker中的守护程序,无法使用systemd监视容器,但可以通过systemd启动、监视甚至重新启动容器。
此外,Podman还提供了podman generate systemd
命令,用于为相应的容器生成相应的systemd服务,从而减轻了用户创建systemd服务的负担,这意味着主机系统上可以使用集成。
Podman和Docker之间的另一个重要区别是,由于能够创建内部网络,Docker不会更改防火墙规则或当前安装。相比之下,Docker必须覆盖防火墙规则以实现容器间的通信。
Podman | Docker | |
架构 | 守护程序 | 无守护程序 |
服务管理 | Systemd | Docker引擎 |
防火墙兼容性 | 覆盖防火墙规则 | 遵守防火墙规则 |
平台 | 本机支持Linux | Linux,Windows和Mac |
何时应从Docker迁移到Podman
如果您在基于RHEL的环境中部署容器,那么除了使用Podman作为RHEL本地工具之外,您几乎没有其他选择。如果您只有少量容器的小规模部署,您也可以选择将其迁移到或选择使用Podman而不是Docker。
然而,如果您想要更复杂的操作,拥有多个容器和一组在网络上协同工作的容器,那么最好使用Docker,因为它对此的处理更好。
同样地,如果您刚开始涉足容器领域,那么Docker是一个更好的选择,因为它稳定、经过充分验证并且有良好的文档,并且相对于Podman来说学习曲线较低,Podman仍然缺乏稳定性并且没有明确定义的文档。
从Podman迁移到Docker
如果您在命令行上操作,从Docker Engine切换到Podman非常简单。最简单的方法是使用$ alias docker=podman
命令。
当然,这假设适当的软件已安装在系统上。对于Linux来说,这也不是问题;现成的软件包可用于商业可用的发行版。
Windows或macOS不是受支持的操作系统之一。使用别名的方法是因为许多Docker命令都有对应的Podman命令。
但也有例外,因为一些Docker命令在Podman世界中没有对应项。同样地,某些命令在Docker和Podman的世界中的行为也不同。目前,这仅影响已经设置好的卷的处理方式。
如果使用了类似于的图形化工具,切换会稍微复杂一些,尤其适用于那些使用Windows或macOS的开发人员。
Docker Desktop用户将不得不适应命令行,Docker compose也是如此。然而,现在有了podman-compose项目。这个用Python编写的软件作为Docker compose的替代品。
最后的话
用Podman替代Docker的工作几乎完成了。对于用户和管理员来说,这个变化的大部分方面都很容易。许多Docker功能在Podman中都有相同的等效功能。
真正的好处是没有单一的守护进程和root权限,更不用说自然使用的容器组。然而,值得一提的是,Docker仍然是关于容器的主要技术,但这很可能在长期内发生改变。
您还可以探索一些用于管理容器的工具。