Docker不再是唯一的选择

文章转自：分布式实验室

原文链接：https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833

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 minutes ago         211eaecd307b-infra  211eaecd307b  mypod 

最后，Podman提供了与Docker完全相同的CLI命令，因此只需执行alias docker = podman并装作什么都没有改变。

除了Docker和Podman之外，还有其他的容器引擎，但我个人认为它们都是没什么出路的技术，或者都不太适合本地开发和使用。但是，要全面了解，至少要看一下其中的内容：

• LXD——LXC （Linux Containers）是一个容器管理器（守护进程）。该工具提供了运行系统容器的能力，这些系统容器提供了更类似于VM的容器环境。它位于非常狭窄的空间，没什么用户，所以除非你有非常具体的实例，否则最好还是使用Docker或Podman。

• CRI-O——当你Google什么是CRI-O你可能会发现它被描述为容器引擎。不过，实际上它只是容器运行时。其实它既不是引擎，也不适合“正常”使用。我的意思是，它是专门为Kubernetes运行时（CRI）而构建的，而不是为最终用户使用的。

• Rkt——rkt（“Rocket”）是由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之间的差异的细节，请参阅这个文章[1]）。

现在，我们来看看一个演示：

\~ \$ 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在内的每一种工具都有其优缺点，评估哪一组工具最适合你的工作流和场景才是最重要的，真心希望本文能在这方面帮助到你。