Docker不再是唯一的选择

ChlatZed 2020-11-11

Docker并不是唯一的容器化工具,可能还有更好的选择……

在容器的早期时代(其实更像是4年前),Docker是容器游戏中唯一的玩家。但现在情况已经不一样了,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管道中使用,它可以测量你的镜像是否“足够高效”,或者换句话说——它是否浪费了太多空间。

相关推荐