Docker 与 Podman：哪款容器化工具更适合您

什么是 Podman 与 Docker？

让我们先概览这两款工具，再展开比较：

Docker 概览

Docker 是构建、运行与交付容器的事实标准。容器是将操作系统层面的依赖与某种应用代码组合在一起的对象，可在其独立的环境中打包并运行诸如全栈应用或 ETL 流水线之类的内容。容器就像一台“微型计算机”，只包含运行某段代码所需的必备要素。

Docker 的历史并不长，2013 年以开源项目首次发布，此后项目发展迅猛。

在企业环境中运行容器时，几乎所有软件与数据团队都会首先选择 Docker。

开发者可在三大操作系统上运行 Docker，并且它几乎能与所有现代技术良好集成。这意味着数据工程师可以在本地 Mac 上使用 Docker 容器编写并打包数据流水线，然后将该容器部署到 AWS ECS 上运行。

Docker CLI、Docker Desktop 与 Docker Hub 等工具让各个水平的开发者都能轻松上手。

如果您想通过更实操的方式学习 Docker，我们提供了多项Docker 项目以及关于Docker 认证的信息，助您全面提升 Docker 技能！

Podman 概览

与 Docker 类似，Podman 是一款用于开发与管理容器的开源工具。Podman 最初由 Red Hat 开发，作为面向 Linux 的 Docker 替代方案，并于 2019 年发布。

两者最显著的区别在于底层架构：Docker 依赖守护进程，而 Podman 采用无守护进程的运行方式（后文详述）。

与 Docker 不同，Podman 不需要对其所管理 Pod 运行所在机器的 root 访问权限；这使得 Podman 成为对安全性更为重视的团队在使用容器运行应用与工作负载时的可选方案。

Podman 为用户提供了与 Docker 相似的体验；开发者可以在本地环境中通过 CLI 或 GUI（Podman Desktop）与 Podman 交互。

无论是 Linux、Mac 还是 Windows 用户，都可以使用 Podman 在本地构建与测试容器，然后部署到诸如 Kubernetes 等远程环境。

Podman 与 Docker 的关键差异

有无守护进程的架构

Docker 与 Podman 的最大区别在于各自构建所基于的底层架构。Docker 严重依赖守护进程，而 Podman 则是无守护进程的。

可以将守护进程理解为在宿主操作系统后台运行的进程。对于 Docker，其守护进程负责管理 Docker 对象（镜像与容器）并与其他系统通信。为了运行其守护进程，Docker 使用名为 dockerd 的软件包。

为什么这很重要？首先，守护进程通常需要对其运行所在机器的 root 级访问权限。这会带来安全隐患——如果恶意行为者获得了对守护进程的访问权限，就等于可以访问整台机器。

Podman 的无守护进程架构带来多项好处。由于运行守护进程几乎总是需要 root 权限，无守护进程的架构可视为“无 root（rootless）”。这意味着即使用户对运行其容器的机器没有系统级访问权限，也能使用 Podman；而 Docker 并非总是如此。

Podman 不使用守护进程，而是采用 Linux 原生的软件包 systemd。由于 systemd 是 Linux 操作系统原生组件，Podman 常被认为比 Docker 更“轻量”；使用 Podman 时，容器的启动速度通常会更快。

构建镜像与容器

尽管在架构上有根本差异，Docker 与 Podman 的核心目的相同——创建并运行镜像与容器。不过，两者在实现流程上略有不同。

在 Docker 中，首先将命令写入 Dockerfile，然后执行如 docker build 之类的命令。该命令会依次调用 Dockerfile 中的语句，最终构建出镜像。随后，镜像可“运行”为容器。正如您所料，这可通过 docker run 命令并指定镜像 ID 或标签来完成。若要构建并运行多个容器，我们会使用一个名为 docker-compose 的专用工具，稍后我们会进一步介绍。

在 Podman 中，构建镜像并将其作为容器运行的过程几乎完全一致。不同的是，Podman 用户会创建 Containerfile（虽然使用 Dockerfile 这个文件名也同样可行），其编写镜像的语法相同。在将相应命令加入 Containerfile 后，即可使用 Podman CLI 构建并运行镜像。

在大多数情况下，Podman 与 Docker 高度兼容。虽会在细节上存在差异，但总体而言，可以无缝地将 Docker CLI 替换为 Podman CLI。

来源

Podman vs Docker Desktop

Docker Desktop：简化的多平台访问

与 Docker 交互有多种方式。经验丰富的软件与数据从业者通常依赖 Docker CLI（亦称 Docker 客户端）来操作其 Docker 镜像与容器。

不过，还有一种更易上手的方式，那就是使用 Docker Desktop。

Docker Desktop 是一款免费的图形化工具，为用户提供界面来构建与管理运行其应用或工作负载的镜像与容器。数据工程师可用 Docker Desktop 查看其机器上的可用镜像并将其启动为容器；同样，软件开发者也可从 Docker Hub 拉取镜像，以便开启下一个项目。

该 UI 简洁直观，同时让您对 Docker 环境保持完整的可见性与掌控。

然而，Docker Desktop 的能力不止于查看与管理 Docker 对象。

用户可以精细到字节地管理其 Docker 对象可用的资源、附加到正在运行的容器，或在本地机器上启动一个 Kubernetes 集群。Docker Desktop 用户可以从数百个扩展中进行选择，或通过实用教程与示例环境快速开启 Docker 之旅。好消息是，Docker Desktop 跨平台可用，支持 Mac、Windows 与 Linux。

Podman Desktop 的特性与限制

Podman Desktop 的外观与体验与其 Docker 对应产品十分相似。在 Podman Desktop 的 UI 中，用户可以查看与管理容器、镜像、Pod 和卷。与 Docker 一样，Podman 也支持插件与集成，例如在本地运行 Red Hat OpenShift 集群，或通过 Podman AI Lab 使用大语言模型。

如果您有自定义插件想要使用，也没问题——可以直接在 Podman Desktop 中安装。

如果您同时是 Docker 与 Podman 用户，可能会惊讶地发现在 Podman Desktop 的 UI 中同时出现 Docker 与 Podman 的对象。这并非巧合！我们很快会更深入地解释其含义。与此同时，这意味着用户可以通过同一个界面同时操作 Podman 和 Docker 对象。

容器最常见的使用场景是通过 Kubernetes 运行。尽管 Docker 是容器化的行业标准，Podman 在 Podman Desktop 上提供了更为强大的 Kubernetes 体验。

能够查看与管理节点、Pod、Deployment（以及更多）等 Kubernetes 资源，使得 Kubernetes 的运维与开发在 Podman Desktop 上成为“一等公民”。这些工具，再加上前文提到的 Red Hat OpenShift 集成等插件，使得 Podman 成为面向 Kubernetes 团队的差异化工具。

Podman Compose 与 Docker Compose

使用 Docker 定义与管理多容器应用

有些应用与工作负载可以打包进单个容器，有些则不行。为了简化多容器管理，Docker 提供了 Docker Compose 工具。Docker Compose 使用单个 YAML 文件来定义应用的各个组件。

随后，通过 docker-compose CLI，您可以启动、停止或重建这些容器与服务。一个 Docker Compose 的 YAML 文件可能如下所示：

yaml
version: '3'
services:
	app:
		image: python:3.10
		container_name: app
		command: run app --host=0.0.0.0
	database:
		image: postgres:13
		container_name: database
		ports: 5432
		volumes:
			- postgres_data:/var/lib/postgresql/data
volumes:
	postgres_data技术支持

这里包含了不少内容，但 Docker Compose 允许我们在一个 YAML 文件中定义两个服务和一个卷。然后，执行 docker-compose up 命令就能启动这些容器，应用随即运行。

对于运行大型应用与工作负载的软件与数据团队而言，Docker Compose 既便于本地开发，也便于在生产环境中交付与运行代码。

Podman 的多容器应用方法

在 Podman 中运行多容器应用的方式与使用 Docker 看起来几乎完全相同。Podman 借助 Podman Compose 实现这一点。与 Docker Compose 一样，Podman Compose 使用 YAML 文件以声明式方式定义应用的组件。

随后，可以使用 podman-compose CLI 来启动、停止或重启 YAML 文件中定义的服务。

在大多数情况下， podman-compose 可以替代 docker-compose（个别地方存在不兼容）。与 Docker 相同，使用 Podman Compose 能够对多容器应用进行独立而灵活的管理。

下表对比了 Docker 与 Podman。

Podman 与 Docker 的使用场景与最佳实践

接下来探讨您最关心的问题——何时应使用 Docker，何时应选择 Podman？我们来具体看看。

何时使用 Docker

Docker 是构建、运行与交付容器的事实标准。如果您刚开始接触容器化（尤其是在个人电脑上），不妨先试试 Docker。

借助 Docker Desktop 或 Docker CLI 等工具，无论是第一个还是第五十个容器，都能轻松启动与运行。Docker 拥有庞大的社区，您想做的事情很可能已经有人做过了，这让故障排查等环节更加容易。

与 Podman 相比，Docker 提供了更强的一致性跨平台体验。更重要的是，Docker 几乎能与所有基于容器的服务集成，包括 AWS ECS、Azure AKS 和 Google Cloud Run。

这意味着当您需要在生产环境中运行容器时，能够轻松与所选服务集成。从本地开发无缝迁移到生产，是使用 Docker 对代码进行容器化最强大的优势之一。

使用 Docker 的不仅是软件与数据工程团队。AI 与 ML 工程师、数据科学家，甚至数据分析师也在用 Docker 驱动他们的工作！

何时使用 Podman

对于在安全敏感或高度合规环境中工作的开发者而言，Podman 或许是您钟意的容器管理器。请记住，Podman 是“无 root”的，这意味着在本地运行 Podman 的用户，无需对其机器拥有 root 访问权限即可在本地构建与管理容器。以下是更偏向选择 Podman 而非 Docker 的几项理由：

• 您在 Linux 机器上进行本地开发。
• 您非常关注底层资源占用与容器启动时间。
• 您计划将容器部署到 Kubernetes 集群，或希望在本地机器上模拟 Kubernetes 环境。

另一个需要记住的点是：在大多数情况下，Podman 与 Docker 可互换。这意味着，如果您从 Docker 入手，后来发现 Podman 更适合自己，在两者之间切换也很容易。

结语

运行容器需要有工具来管理这些对象。本文我们一起探索了两款最流行的容器化工具：Docker 与 Podman。

作为容器化的行业标准，Docker 被数百万人用于运行全球的应用与数据工作负载。Docker 的架构构建在 Docker 守护进程之上，而该进程需要对运行容器的系统拥有 root 访问权限。

开发者可通过 Docker CLI 或 Docker Desktop 与 Docker 交互，这两者都支持管理镜像、容器与卷等对象。Docker 的广泛采用带来了庞大而活跃的社区，并在三大操作系统以及几乎所有基于容器的服务上提供支持。

Podman 则提供了另一种容器管理方案。Podman 无守护进程且无 root 要求，这意味着用户无需对其运行 Podman 的机器拥有 root 权限。这对强调安全性的团队颇具吸引力。与 Docker 类似，Podman 同时提供 CLI 与 UI 用于构建与管理容器。尽管其原生于 Linux，Podman 也可在 Windows 与 Mac 上运行，并能与 AWS ECS、Azure AKS 等工具很好地集成。

无论您选择哪款工具，学习如何将自己编写的代码“容器化”都是快速提升开发技能的途径之一。如果您希望进一步了解 Docker 与 Podman，欢迎动手实践，例如参加Docker 入门或容器化与虚拟化概念等课程。祝您学习顺利，编码愉快！