Docker并不是唯一的容器化工具，可能还有更好的选择……
在容器的早期时代(其实更像是4年前)，Docker是容器游戏中唯一的玩家。但现在情况已经不一样了，Docker不再是唯一的一个，而只是其中一个容器引擎而已。Docker允许我们构建、运行、拉、推或检查容器镜像，然而对于每一项任务，都有其他的替代工具，甚至可能比Docker做得还要好。所以，让我们探索一下，然后再卸载(只是可能)，直至完全忘记Docker……
那，为什么不再用Docker了?
如果你已经使用Docker很长时间了，估计要真正说服你去考虑其他工具，得先提供些依据。
首先，Docker是一个单体工具。它尝试去涵盖所有的功能，通常这并不是最佳实践。大多数情况下，我们都是只选择一种专门的工具，它只做一件事，并且做得非常好，非常精。
如果害怕切换到不同的工具集是因为将不得不学习使用不同的CLI、API或者说不同的概念，那么这不会是一个问题。本文中展示的任何工具都可以是完全无缝的，因为它们(包括Docker)都遵循OCI (Open Container Initiative)下的相同规范。它们包含了容器运行时、容器分发和容器镜像的规范，其中涵盖了使用容器所需的所有特性。
有了OCI，你可以选择一套最符合你需求的工具，同时你仍然可以享受跟Docker一样使用相同的API和CLI命令。
所以，如果你愿意尝试新的工具，那么让我们比较一下Docker和它的竞争对手的优缺点和特性，看看是否有必要考虑放弃Docker，使用一些新的闪亮的工具。
容器引擎
在比较Docker和其他工具时，我们需要将其分解为组件，首先我们先讨论一下容器引擎。Container Engine是一种工具，它为处理镜像和容器提供用户界面，这样就不必处理SECCOMP规则或SELinux策略之类的事情。它的工作还包括从远程仓库提取镜像并将其扩展到磁盘。它看起来也是运行容器，但实际上它的工作是创建容器清单和带有镜像层的目录。然后它将它们传递到容器运行时，如runC或Crun(稍后我们将讨论这一点)。
目前已经有许多容器引擎，但Docker最突出的竞争对手是由红帽开发的Podman。与Docker不同，Podman不需要Daemon来运行，也不需要root特权，这是Docker长期以来一直关注的问题。基于它的名字，Podman不仅可以运行容器，还可以运行pods。如果你不熟悉pods的概念，其实，简单的概括就是，Pod是Kubernetes的最小计算单元。它由一个或多个容器(主容器和执行支持任务的Sidecar)组成，这使得Podman用户以后更容易将他们的工作负载迁移到Kubernetes。因此，作为一个简单的演示，这是如何在一个Pod中运行两个容器：
~ $ podman pod create --name mypod ~ $ podman pod list POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID 211eaecd307b mypod Running 2 minutes ago 1 a901868616a5 ~ $ podman run -d --pod mypod nginx # First container ~ $ podman run -d --pod mypod nginx # Second container ~ $ podman ps -a --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD POD NAME 3b27d9eaa35c docker.io/library/nginx:latest nginx -g daemon o... 2 seconds ago Up 1 second ago brave_ritchie 211eaecd307b mypod d638ac011412 docker.io/library/nginx:latest nginx -g daemon o... 5 minutes ago Up 5 minutes ago cool_albattani 211eaecd307b mypod a901868616a5 k8s.gcr.io/pause:3.2 6 minutes ago Up 5
最后，Podman提供了与Docker完全相同的CLI命令，因此只需执行alias docker = podman并装作什么都没有改变。
除了Docker和Podman之外，还有其他的容器引擎，但我个人认为它们都是没什么出路的技术，或者都不太适合本地开发和使用。但是，要全面了解，至少要看一下其中的内容：
LXD——LXC (Linux Containers)是一个容器管理器(守护进程)。该工具提供了运行系统容器的能力，这些系统容器提供了更类似于VM的容器环境。它位于非常狭窄的空间，没什么用户，所以除非你有非常具体的实例，否则最好还是使用Docker或Podman。
CRI-O——当你Google什么是CRI-O你可能会发现它被描述为容器引擎。不过，实际上它只是容器运行时。其实它既不是引擎，也不适合“正常”使用。我的意思是，它是专门为Kubernetes运行时(CRI)而构建的，而不是为最终用户使用的。
Rkt——rkt(“火箭”)是由CoreOS开发的容器引擎。这里提到这个项目只是为了完整性，因为这个项目已经结束，开发也停止了——所以也就没必要再使用了。
构建镜像
对于容器引擎来说，一般都只选择Docker。但是，当涉及到构建镜像时，选择的余地还是比较多的。
首先，介绍一下Buildah。Buildah是红帽开发的另一个工具，它与Podman配合使用相当合适。如果已经安装了Podman，你可能会注意到podman build子命令，它实际上只是伪装的Buildah，因为它的二进制文件已经包含在Podman里。
至于它的特性，它遵循了与Podman相同的路线——无守护程序和无根的，并遵循OCI的镜像标准，所以它能保证所构建的镜像和Docker构建的是一样的。它还能够从Dockerfile或更恰当的命名Containerfile来构建镜像，Dockerfile和Containerfile都是相同的，只是命名的区别。除此之外，Buildah还对镜像层提供了更精细的控制，允许在单层中提交更多变更。唯一的例外是(在我看来)与Docker的区别是，由Buildah构建的镜像是基于用户的，因此用户可以只列出自己构建的镜像。
那么，考虑到Buildah已经包含在Podman CLI中，大家可能会问，为什么还要使用单独的Buildah CLI?Buildah CLI是podman build中包含的命令的超集，所以基本不需要单独接触Buildah CLI，但是通过使用它，你可能还会发现一些额外有用的特性(有关podman build和buildah之间的差异的细节，请参阅这个文章)。
现在，我们来看看一个演示：
~ $ buildah bud -f Dockerfile . ~ $ buildah from alpine:latest # Create starting container - equivalent to "FROM alpine:latest" Getting image source signatures Copying blob df20fa9351a1 done Copying config a24bb40132 done Writing manifest to image destination Storing signatures alpine-working-container # Name of the temporary container ~ $ buildah run alpine-working-container -- apk add --update --no-cache python3 # equivalent to "RUN apk add --update --no-cache python3" fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz ... ~ $ buildah commit alpine-working-container my-final-image # Create final image Getting image source signatures Copying blob 50644c29ef5a skipped: already exists Copying blob 362b9ae56246 done Copying config 1ff90ec2e2 done Writing manifest to image destination Storing signatures 1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c ~ # buildah images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/my-final-image latest 1ff90ec2e26e 22 seconds ago 51.4 MB
从上面的脚本可以看到，我们可以只用buildah bud构建镜像，bud代表使用Dockerfile构建，但是你还可以使用更多Buildahs的脚本：from，run和copy，这些命令对应命令Dockerfile的(FROM image，RUN…，COPY…)。
下一个是谷歌的Kaniko。Kaniko也是从Dockerfile构建容器镜像，跟Buildah类似，也不需要守护进程。与Buildah的主要区别在于，Kaniko更专注于在Kubernetes中构建镜像。
Kaniko使用gcr.io/ Kaniko -project/executor作为镜像运行。这对于Kubernetes来说是行得通的，但是对于本地构建来说不是很方便，并且在某种程度上违背了它的初衷，因为我们得先使用Docker来运行Kaniko镜像，然后再去构建镜像。也就是说，如果正在为Kubernetes集群中构建镜像的工具进行选型(例如在CI/CD Pipeline中)，那么Kaniko可能是一个不错的选择，因为它是无守护程序的，而且(可能)更安全。
从我个人的经验来看——我在Kubernetes/OpenShift集群中使用了Kaniko和Buildah来构建镜像，我认为两者都能很好地完成任务，但在使用Kaniko时，我看到了一些将镜像导入仓库时的，会有随机构建崩溃和失败的情况。
第三个竞争者是Buildkit，也可以称为下一代的Docker build。它是Moby项目的一部分。在Docker里可以使用DOCKER_BUILDKIT=1 Docker build…作为实验特性进行启用。那么，它的核心价值到底有哪些?它引入了许多改进和炫酷的特性，包括并行构建、跳过未使用的阶段、更好的增量构建和无根构建。然而另一方面，它仍然需要运行守护进程(buildkitd)才能运行。所以，如果你不想摆脱Docker，但是想要一些新的特性和更好的改进，那么使用Buildkit可能是最好的选择。
和前面一样，这里我们也还有一些“光鲜亮丽的产品”，它们也都有非常具体的场景，虽然并不是我们的首选：
Source-To-Image(S2I)是一个不需要Dockerfile直接从源代码构建镜像的工具包。这个工具在简单的、预期的场景和工作流中运行的很好，但是如果有太多的定制，或者该项目没有预期的布局，你很快就会觉得这个工具很烦人和笨拙。如果你对Docker还不是很有信心，或者如果在OpenShift集群上构建镜像，那么你可以尝试考虑一下使用S2I，因为使用S2I构建是一个内置特性。
Jib是谷歌的另一个工具，专门用于构建Java镜像。它包括Maven和Gradle插件，可以轻松地构建镜像，而不会干扰Dockerfile。
最后一个但并不是不重要的是Bazel，它是谷歌的另一款工具。它不仅用于构建容器镜像，而且是一个完整的构建系统。如果你只是想构建一个镜像，那么钻研Bazel可能有点过头，但绝对是一个很好的学习体验，所以如果你想尝试，rules_docker绝对是一个很好的起点。
容器运行时
最后一个大块儿是容器运行时，它负责运行容器。容器运行时是整个容器生命周期/栈的一部分，除非你对速度、安全性等有一些非常具体的要求，否则一般是不需要对其进行干扰。所以，如果读者看到这里已经厌倦，那么可以跳过这一部分。如果不是，那么有关容器运行时的选择，如下：
runC是基于OCI容器运行时规范创建的，且最流行的容器运行时。Docker(通过containerd)、Podman和crio使用它，所以几乎所有东西都依赖于LXD。它几乎是所有产品/工具的默认首选项，所以即使你在阅读本文后放弃Docker，但你仍然会用到runC。
runC的另一款替代方产品为Crun，名称类似(容易混淆)。这是Red Hat开发的工具，完全用C编写(runC是用Go编写的)。这使得它比runC更快，内存效率更高。考虑到它也是OCI兼容的运行时。所以，如果你想做个测试，切换起来很容易。尽管它现在还不是很流行，但在RHEL 8.3技术预览版中，它将作为一个替代OCI运行时，同时，考虑到它是红帽的产品，我们可能最终会看到它会成为Podman或CRI-O的默认首选项。
说到CRI-O。前面我说过，CRI-O实际上不是一个容器引擎，而是容器运行时。这是因为CRI-O不包括比如推送镜像这样的特性，而这正是容器引擎的特性。作为运行时的CRI-O在内部使用runC运行容器。通常情况下不需要在单机尝试这个工具，因为它被构建为用于Kubernetes节点上的运行时，可以看到它被描述为“Kubernetes需要的所有运行时，仅此而已”。因此，除非你正在设置Kubernetes集群(或OpenShift集群——CRI-O已经是默认首选项了)，否则不大可能会接触到这个。
本节的最后一个内容是containerd，它是CNCF的一个毕业的项目。它是一个守护进程，充当各种容器运行时和操作系统的API。在后台，它依赖于runC，是Docker引擎的默认运行时。谷歌Kubernetes引擎(GKE)和IBM Kubernetes服务(IKS)也在使用。它是Kubernetes容器运行时接口的一个部署(与CRI-O相同)，因此它是Kubernetes集群运行时的一个很好的备选项。
镜像检测与分发
容器栈的最后一部分是镜像的检测与分发。这有效地替代了docker inspect，还(可选地)增加了远程镜像仓库之间复制/映射镜像的能力。
这里唯一要提到的可以完成这些任务的工具是Skopeo。它由红帽公司开发，是Buildah，Podman和CRI-O的配套工具。除了我们都从Docker中知道的基本的skopeo inspect之外，Skopeo还能够使用skopeo copy复制镜像，它允许你在远程镜像仓库之间映射镜像，而无需先将它们拉到本地仓库。如果你使用本地仓库，此功能也可以作为pull/push。
另外，我还想提一下Dive，这是一个检查、探测和分析镜像的工具。它对用户更友好一些，提供了更可读的输出，可以更深入地探测镜像，并分析和衡量其效率。它也适合在CI管道中使用，它可以测量你的镜像是否“足够高效”，或者换句话说——它是否浪费了太多空间。
结论
本文的目的并不是要说服大家完全抛弃Docker，而是向大家展示构建、运行、管理和分发容器及其镜像的整个场景和所有选项。包括Docker在内的每一种工具都有其优缺点，评估哪一组工具最适合你的工作流和场景才是最重要的，真心希望本文能在这方面帮助到你。
