是时候和 DOCKER 说再见了！！！Docker 时代已经结束了……

从 Docker 迁移到 Podman

另请阅读：无根 Docker

Podman 是一款符合开放容器倡议 (OCI) 标准的容器管理工具，与 Docker 类似，Podman 非常轻量级，没有庞大的特权守护进程。它在构建时充分考虑了安全性，是 Docker 开发的绝佳替代方案。

我说过 Podman 兼容OCI吗？这意味着，我们可以使用任何现有的容器镜像，用 Podman 命令替换任何 Docker 命令，而无需进行任何更改。截至 2020 年 5 月 28 日，OCI 的现有成员如下：

甚至有一个官方软件包，通过或多或少地创建从 Docker 到 Podman 的别名来提供向后兼容性。但首先，你到底为什么要停止使用 Docker？关于 Docker，或者更确切地说，关于人们对待 Docker 的方式，让我担心的一件事是，我们忘记了 Docker 是什么。

简单解释一下，Docker 是众多容器管理工具之一。它无疑是同类产品中首创的，并得到了广泛的应用。Docker 也无疑引领了业界对容器的采用。但我们已经使用 Docker 很久了，以至于我们已经不再考虑“容器”这个词了，现在我们认为“Docker”无处不在，你可以看到“Doc​​ker 服务器”、“Docker 镜像”和“Docker 注册表”。

这就是我们用“Git”来举例说明的语言。然而，我们通常说的是“git 仓库”，并且我们清楚地看到了 git 作为业界通用的版本控制系统与 gitHub 之间的区别，gitHub 只是众多在 git 仓库上进行协作的服务之一，或者更明确地说，是 Ubuntu 本身。GitHub 一直在彻底改变我们使用 Git 仓库的方式。

我们每个人对 Linux 的偏好各不相同——我喜欢 Ubuntu，但最终我们都使用 Linux，而且都知道自己使用的是 Linux 操作系统。我们对 Linux 的偏好各不相同。

对于容器，我们也需要类似的思维转变。我们必须理解什么是容器，并区分容器和我们用来操作容器的工具之间的界限。

也为了证明 Docker 有不错的替代方案。不过，在开始之前，我先来谈谈容器。有些人可能会认为其他容器管理工具不如 Docker 完善。这
是一个合理的问题——没有人愿意使用不稳定、崩溃的应用程序。我将向你展示如何使用 Podman 构建和运行容器镜像。在你的开发环境中，你肯定不想对一些花哨的新应用进行 Beta 测试。
但我不会给出几个你不必担心的理由：

(1)首先，AWS Fargate 是最受欢迎的无服务器容器运行平台之一，它在最新版本中放弃了 Docker。这一变化的美妙之处在于它只是一个实现细节，AWS 客户不需要重新编写他们的 Dockerfile，也不需要更新他们的容器。从最终用户的角度来看，Fargate 的工作方式与以前完全相同。唯一的区别是没有 Docker 守护进程。
(2) Openshift 是最受欢迎的企业 Kubernetes 平台之一，它在 2019 年 6 月用 Cri-O 取代了 Docker。现代 OpenShift 集群中没有 Docker 的迹象。
(3) OpenSUSE 在 2018 年做了同样的事情——他们将 cri-o 切换为 Kubic 项目的默认容器运行时，Kubernetes 本身在集群安装期间为您提供了多种选择。
(4)你可以选择 cri-o 或只选择 containerd，大多数情况下你甚至不会注意到其中的区别。越来越多的公司正在从“运行 Docker”转向“运行容器”，并采用新的工具，所有这些工具都符合标准，甚至可以很好地相互配合。
所有这些都意味着在生产环境中，Docker 只是一个实现细节。你不必关心使用哪种容器运行时，只要它稳定且符合标准即可。再举一个例子，你不必关心你的云提供商使用哪种虚拟机管理程序。

作为开发者，你不必担心，因为即使你不知道 Docker 是否已投入生产，也没有什么能阻止你尝试构建 Docker 解决方案。只需尝试一下 Podman。试试 Podman 就好。

Docker 的问题是什么？实际上，主要有以下几点：
• 单个进程可能成为单点故障。
• 该进程拥有所有子进程（正在运行的容器）。
• 如果 Docker 守护进程出现任何故障，则所有子进程都会丢失其运行轨迹。
• 构建容器会导致安全漏洞。
• 所有 Docker 操作都必须由拥有相同完全 root 权限的用户（或多个用户）执行。

最重要的是，podman 中没有守护进程的概念。podman 通过 runC 容器运行时进程（而非守护进程）直接与镜像仓库、容器和镜像存储进行交互。
此外，runC 是一个轻量级、可移植的容器运行时。Docker 构建于 runC 运行时容器之上。我们直接使用 runC 运行时容器，而不是在 podman 中使用守护进程。

从 Docker 迁移到 Podman

您需要安装 Podman，而不是 Docker。您无需像 Docker 守护进程那样启动或管理守护进程。Docker 使用的命令与 Podman 相同。Docker 镜像与 Podman 兼容。Podman 将其容器和镜像存储在 Docker 以外的位置。

1. 如何在我的机器上安装 Podman

2. Podman 命令与 docker 相同...只需替换 docker，如 podman pull、podman -ps、podman exec -it h33435dds bash 等...

3. 拉取并推送至 docker hub :)。是的，您可以从 docker hub 推送和拉取镜像。

4. 如何使用 podman 将 docker 镜像发布到 docker hub

接下来，我将创建一个 Containerfile。Containerfile 本质上是一个 Dockerfile，唯一的不同之处在于 Podman 的文件名。开发人员选择这个名字是为了明确表明该文件不是 Podman 专用的。

我们都应该开始将 Dockerfile 重命名为 Containerfile，因为其他多个容器镜像构建工具都可以使用它们。Containerfile 的内容与 Dockerfile 完全相同。我们使用相同的 FROM、RUN、ADD、EXPOSE 等操作……

Containerfile 准备好后，我们就可以创建容器镜像了。默认情况下，Podman 可以从各种公共镜像仓库（包括 Dockerhub）拉取镜像，然后使用 podman 创建镜像。

最后，镜像正在创建，我们可以通过运行“podman images”命令来查看它。现在，让我们从这个文件构建一个新的容器。“podman run”命令接受的原因与“docker run”命令大致相同。

这里我们展示了容器到主机的所有端口，并以分离模式运行该容器。通过运行命令“podman ps”，我们可以看到该容器。

由于我们使用了大写“P”选项，Podman 在主机上打开了一个随机端口。看来我不想手动执行“podman run”命令，我需要 LanguageTool 始终作为服务运行，而在 Linux 主机上运行服务的最佳方式是使用 systemd。

请记住，Podman 没有附带守护进程 - 它依赖于更稳定和更容易的 fork-exec 模型来生成容器，并且 fork 和 exec 架构允许将 Podman 与 systemd 很好地集成，Podman 生成命令非常方便，它采用正在运行的容器之一的概念并生成 systemd 单元文件或 kubernetes pod yaml。

我们以个人用户身份而不是 root 用户身份进行操作，这就是
使用 Podman 时的主要区别。它没有一个中央的、系统范围的守护进程来管理它。

我们以个人用户身份而不是 root 用户身份进行操作，这就是使用 Podman 时的主要区别。它没有一个中央的、系统范围的守护进程来管理它。

Podman 的架构可以帮助拥有此镜像并运行特定容器的用户正确地限定每个容器镜像和容器的范围。网络上没有其他人可以看到我的照片或容器。这意味着现在我必须重新创建图片。实际上，我不需要重建图片。用户可以复制容器镜像。

如果我重启 systemd 操作，它就会获取这个镜像并运行容器，这就是我今天想展示的全部内容！希望您了解 Podman 的使用方法。您可能想继续使用 Docker，但至少您知道还有其他不同的容器管理资源，而且容器不仅仅是 Docker。如果您或您的公司需要有关容器化主题的建议或培训，请联系我们。

另请阅读：无根 Docker

新型 Docker：无根 + 更安全：适用于每个 Docker 用户。

manish srivastava ・ 2020年6月1日

#docker #linux #devops #showdev