声明：我并不会在本系列中重复已有的主题，如容器以及容器标准化的内容，之前已经有很多也很棒的文章和视频，我会链接一些个人觉得最有用的内容。如果你不理解本文的某些部分，那么就参照文章中放置的链接。如果你仍然不理解某些东西，那就在文章下面留言，我会在回复中详细解答你的问题，或者会重新扩展这篇文章。
为什么选择 Dockerless？
首先，我需要解释一下这个系列的标题：”Dokerless”。我们为什么不用 Docker 呢？或者我们为什么要用 Docker 呢？难道就没有别的选择了吗？IT 社区在 2013 年第一次尝试容器的时候是否就已经提出了一个完美的解决方案呢？
答案并不完全是肯定的。容器工业界竭尽全力避免虚拟化技术出现的情形，尽管拥有libvirt这样出色的工具，但我们并没有一套每个虚拟化供应商都会遵循的标准。我们应该认可 Docker 公司的努力，作为一家公司它发起并积极支持了许多围绕容器技术标准化的倡议。
自 2015 年以来，我们有了开放容器计划（OCI）以及容器运行和容器镜像管理的规范。此外，我们还有容器运行时接口（CRI）和容器网络接口（CNI）。如果你很难理解所有新的容器标准是如何在一起工作的，那么就看一下 Scott McCarty 的理解容器标准，他甚至演示了如何在不同容器引擎之间转换这些借口，并且没有丢失任何功能。
如果你可以在 Kubernetes 集群中用 CRI-O 或其它引擎来替换 Docker Daemon，而且作为开发人员又不会注意到其中的差异，那么究竟哪个引擎在运行又有什么关系呢？就像容器让你不再关心主机服务器一样，容器标准也让你可以不用关心容器本身的管理。毕竟，你是否真地关心过 AWS EC2 究竟是在 Xen 还是 KVM 上运行呢？你只是需要一个虚拟机或者一个容器而已。
但是，那些负责 Kubernetes 集群维护、扩展和升级的工程师就非常关心这些选项了。例如，他们可能会担心使用Docker的一些安全问题。另外，他们可能认为没有必要在集群的每个节点上运行额外的守护进程。Docker 可能已经使容器非常流行，但这并不意味着它是最好的容器技术。如果你对各种容器引擎之间的差异很感兴趣，可以从这个对比入手：Kubernetes Container Runtimes。
作为一个开发者，如果你开始依赖一些标准或者一些公司（以免这些公司搞砸标准的开发和支持），那么你可以为本地开发自由地选择开发工具。如果所有工具最终都使用相同的 API，那么你就没有必要局限于某种特定的工具了。那么，”为什么不用 Docker 呢?”，答案是因为我们没有必要再使用 Docker。那么我们该用什么来代替它呢？
Buildah 和 Podman
我们将会分别使用Buildah和Podman来管理容器镜像和容器本身。这两个工具都是由 RedHat 开发，大多数 RedHat 的 Linux 发行版都搭载了这些安装包。更重要的是，从 RedHat Enterprise Linux 8 开始，将不会再有直接使用Docker的安装包。当然，你仍然可以选择从 Docker 库中直接来安装 Docker。
注意，当我说”由 RedHat 开发”时，我并不是说这些工具只是由 RedHat 开发的。Buildah 和 Podman 都是开源项目，源代码托管在 Github 上的容器组织中。的确，Redhat 雇佣员工来开发这些工具，但其实还有一个更大的开发者社区来维护和扩展这两个项目。
使用 Buildah 和 Podman 的弊端
在我们开始讨论为什么使用 Buildan 和 Podman 之前，让我先明确指出与 Docker 相比使用 Buildah 和 Podman 的明显的缺点：
目前它们只能在 Linux 上运行。对于 Windows 和 MacOS，没有像 Docker 那样方便的包装器。在 Windows 下可以使用wsl2，所以问题可能会好一些。
Podman 没有 Docker Compose 的替代品。有一种方法可以在本地运行兼容 kubernetes 的 Pod YAMLs，但还不成熟。不过，这种情况可能会改变。我们将在本系列的最后一篇文章中研究 Pod YAML。
它们仍然非常新，还在快速开发中！
如果你是 Windows 或 MacOS 用户，你肯定会怀念 Docker 客户端工具的舒适，因为你可能不得不手动启动一个 Linux 虚拟机来运行 Buildah 和 Podman。
如果你有一个非常复杂的 Docker Compose 设置，或者你使用 Docker Compose 来部署生产环境，那么你就没有新工具集来替换它了。
但是，除了这两点，你几乎不会注意到从 Docker 转换后的差异。你会得到什么样的回报么？
从 Docker 转向 Buildah 和 Podman 的原因
Docker 的替代品
当你开始使用一组新的工具来管理容器时，你很快就会意识到 Docker 只是一个工具。你会看到没有”Docker 容器”，只有”容器”，没有”Docker 镜像”，只有”容器镜像”。能够思考技术和原则的根本，并避免将你的思想锁定在单一的技术中是很重要的。
就像一个优秀的程序员能够意识到他最喜欢的语言只是众多编程语言中的一种，我们应该能意识到 Docker 只是与容器交互的一种方式而已。了解并尝试其他选择是很重要的，它会给你一个不同的视角，丰富你的知识。
了解真正的容器是什么
一旦你停止思考”Docker”并开始思考”容器”，你将不可避免地要学习容器到底是什么，并获得更深层次的知识，也能理解诸如“docker run”或”podman exec”等命令真正做了什么。如果你是一个网页开发者，那么这些知识可能对你的日常工作没有帮助。是否想更深入地挖掘事物运作的底层知识，完全取决于个人。我的观点是，理解所有事物的工作原理和整合对每个工程师来说都是一项非常重要的技能。
为未来做准备
当你试图在大脑中将”Docker”替换为”容器”时，整个行业也在做同样的事情。正如前面提到的，CRI-O 逐渐成为 Kubernetes 的默认运行时，不同的公司也推出了针对容器的不同工具集。Redhat 发起 Buildah，而谷歌推动了Kaniko，总是有一些不太知名的工具会在某个时候成为主流。
你可以在 Docker 身上下大赌注，并且只使用这一个工具。或者，你可以了解行业中正在发生的情况，并做好 Docker 不再是默认工具的准备，它将会被下一代容器技术工具取代。
关于底层工具
你可以越过 Podman 直接使用 runc。就学习容器技术而言，这将会更加有趣，收获也会更大。当你实际上希望将应用程序包装起来并在本地运行时，这也会导致生产效率的下降。Podman 的目标是成为一个用户友好的 CLI，一个 Docker CLI 的完全替代品，所以在实际工作中，使用 Podman 会更好一些。如果你想看一篇关于使用 runc 和其他底层工具来处理容器的文章，请在评论中告诉我！
前瞻
在下一篇文章中，我们将学习如何使用 Buildah 为 Ruby on Rails 应用程序构建容器镜像。我们还将学习容器镜像究竟是什么，也会研究一下 OCI 镜像规格。在最后一篇文章中，我们将使用 Podman 按照类似于 Docker compose 的方式来完全自动化开发环境。
我们不会在这里使用一些虚构的开发实例。通过使用 Buildah 和 Podman，mkdev.me 将核心 Web 应用以及所有的支持服务都转移到了本地开发环境下的容器中。mkdev.me 就是一个很好的例子：我们有一个中等规模的 Ruby on Rails 应用程序，它使用 PostgreSQL 数据库作为主存储，Redis 用于缓存和后台作业。我们还有 Mattermost 作为消息传递平台的核心，它需要自己的数据库。整个项目不像一个 web 应用程序和一个数据库那样枯燥和简单，又不像一个包含十几个应用程序的微服务程序那样复杂。
原文链接：
https：//mkdev.me/en/posts/dockerless-part-1-which-tools-to-replace-docker-with-and-why
评论