声明：我并不会在本系列中重复已有的主题，如容器以及容器标准化的内容，之前已经有很多也很棒的文章和视频，我会链接一些个人觉得最有用的内容。如果你不理解本文的某些部分，那么就参照文章中放置的链接。如果你仍然不理解某些东西，那就在文章下面留言，我会在回复中详细解答你的问题，或者会重新扩展这篇文章。

为什么选择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

创作场景

Dockerless 系列文章（一）：为什么我们要替换 Docker？