副标题#e#
对于已经用了很久docker的人，可能需要花费些功夫去说服自己去考虑转换使用不同的工具。
Docker是一个庞大单一的工具，它尝试做任何事，但通常没有用最好的方法去做。我们最好选择只做一件事，但确实做得很好的专门工具。如果害怕切换不同的工具集，担心不得不学习使用不同的命令行界面(CLI)、不同的API或通常使用不同的概念，那么现在这将不再是问题。
选择本文中显示的任何工具都是完全无缝衔接的，因为它们(包括Docker)都遵循开放容器计划(OCI)下的相同规范。该计划包含有关容器运行时、容器分发和容器镜像的规范，涵盖了使用容器所需的所有功能。借助OCI，你可以选择最符合需求的一组工具，与此同时仍然可以使用与Docker相同的API和CLI命令。
因此，如果你愿意尝试新工具，那么请比较一下Docker及其竞争对手的优势、劣势和功能，看看是否有必要考虑放弃Docker，试试某些新工具。
容器引擎
在将Docker与其他任何工具进行比较时，我们需要按组件对其进行分类，并且首先要谈的是容器引擎。
容器引擎是一种工具，提供了用于处理图像和容器的用户界面，因此不必担心扰乱SECCOMP规则或SELinux策略。它的工作还包括从远程存储库中提取图像并将其扩展到磁盘，似乎也在运行容器，但它实际上的工作是创建带有图像层的容器清单和目录，然后将它们传递到容器运行时，如runc或crun。
目前有许多可用的容器引擎，Docker最主要的竞争对手是Red Hat开发的Podman。与Docker不同，Podman不需要运行守护进程，也不需要root特权，这是Docker长期以来一直关注的问题。
顾名思义，Podman不仅可以运行容器，还可以运行pods。pod是Kubernetes的最小计算单元。它由一个或多个容器组成，执行支持任务。这使Podman用户以后可以更轻松地将其工作负载迁移到Kubernetes。以下是如何在单个pod中运行2个容器的方法：
~ $ podman podcreate –name mypod
~ $ podman podlist
POD ID NAME STATUS CREATED # OFCONTAINERS INFRA ID
211eaecd307b mypod Running 2 minutes ago 1 a901868616a5
~ $ podman run -d–pod mypod nginx # Firstcontainer
~ $ podman run -d–pod mypod nginx # Secondcontainer
~ $ podman ps -a–pod
CONTAINERID 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
最后，Podman提供了与Docker完全相同的CLI命令，只需执行alias Docker=Podman并假装没有任何更改。
除了Docker和Podman，还有其他的容器引擎，但是笔者认为它们都没有出路，或者都不适合本地开发和使用。具体原因如下：
LXD——LXD是用于LXC(Linux容器)的容器管理器(守护进程)。这个工具提供了运行系统容器的能力，这些容器提供了更类似于VMs的容器环境。它位于非常狭窄的空间中，用户不多，所以除非有非常具体的用例，否则最好使用Docker或Podman。
CRI-O——当搜索什么是CRI-O时，可能会发现它被描述为容器引擎。不过，它实际上是容器运行时。此外，它也不适合“正常”使用。笔者的意思是，它是专门为Kubernetes运行时(CRI)而构建的，而不是供最终用户使用。
rkt——rkt(“火箭”)是CoreOS开发的容器引擎。这里提到这个项目只是为了文章的完整性，因为项目结束了，它的开发也停止了，所以趁早别用它。
构建镜像
容器引擎中，Docker只有一个替换项,但当谈到构建镜像，我们有更多的选择。
#p#副标题#e##p#分页标题#e#
首先来介绍Buildah。Buildah是redhat开发的另一个工具，它可以很好地与Podman配合使用。如果已经安装了Podman，可能会注意到Podman build子命令，它实际上只是伪装的Buildah，其二进制文件包含在Podman中。
#p#副标题#e#
它的功能遵循与Podman相同的路线，是无守护程序和无根的，并且可以生成OCI兼容的镜像，可以确保你的镜像与Docker构建镜像的运行方式相同。除此之外，Buildah还提供了对图像层的更精细的控制，允许将许多更改提交到单个层中。与Docker相比，Buildah构建的镜像是特定于用户的，因此只能列出自己构建的镜像。
那么，既然Buildah已经包含在podman CLI中，为什么还要使用单独的Buildah CLI?原因在于，buildahcli是podman build中包含的命令的超集，可能不需要接触buildah CLI，但是通过使用它，可能还会发现一些额外有用的特性。
可以看一个小型过程展示：
~ $ buildah bud-f Dockerfile .
~ $ buildah from alpine:latest # Create starting container – equivalentto "FROM alpine:latest"
Getting image source signatures
Copying blobdf20fa9351a1 done
Copying configa24bb40132 done
Writing manifest toimage destination
Storing signatures
alpine-working-container # Name of the temporary container
~ $ buildah runalpine-working-container — apk add –update –no-cache python3 # equivalent to "RUN apk add–update –no-cache python3"
fetch
fetch
…
~ $ buildahcommit alpine-working-container my-final-image # Create final image
Getting image source signatures
Copying blob50644c29ef5a skipped: already exists
Copying blob362b9ae56246 done
Copying config1ff90ec2e2 done
Writing manifest toimage destination
Storing signatures
1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c
~# buildah images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/my-final-imagelatest 1ff90ec2e26e 22 seconds ago 51.4 MB
从上面的脚本可知，可以仅使用buildah bud来构建镜像，其中bud代表使用Dockerfile进行构建，但是还可以使用更多的脚本化方法，通过Buildahs的from、run和copy，这与Dockerfile中的命令等效。
接下来是Google的Kaniko。Kanik也与Dockerfile构建容器镜像，类似于Buildah，它也不需要守护进程。其与Buildah的主要区别在于，Kaniko更专注于在Kubernetes中构建镜像。
Kanik使用gcr.io/kaniko-project/executor作为镜像运行，这对于Kubernetes有意义，但对于本地构建而言并不方便，且无法达到目的，因为需要使用Docker运行Kaniko镜像来构建新镜像。
话虽如此，如果正在寻找用于在Kubernetes集群中构建镜像的工具(例如在CI/CD管道中)，无守护进程并且(也许)更安全，Kaniko可能是一个不错的选择。
#p#副标题#e##p#分页标题#e#
不过，根据笔者的个人经验，同时使用Kaniko和Buildah在Kubernetes/OpenShift集群中构建镜像，笔者认为两者都可以很好地完成工作，但是使用Kaniko时，笔者看到了一些随机的构建崩溃，并且在将镜像推送到注册表时失败了。
Docker的第三个竞争者是buildkit，也可以称为下一代docker build。它是Moby项目的一部分(与Docker一样)，可以使用DOCKER_BUILDKIT = 1 dockerbuild作为实验特性启用Docker。
它引入了许多改进和功能，包括并行构建步骤、跳过未使用的阶段、更好的增量构建和无根构建。但另一方面，它仍然需要运行守护程序(buildkitd)。因此，如果不想摆脱Docker，但是想要一些新功能和不错的改进，那么使用buildkit可能是理想选择。
除此之外，还有一些值得一提的内容，但不是笔者的最佳选择：
Source-To-Image(S2I)是一个工具包，可直接从源代码构建镜像，而无需Dockerfile。该工具非常适合简单的预期场景和工作流程，但如果不需要太多自定义或项目的布局不理想，那么它很快就会变得笨拙。如果对Docker不太有把握，或者在OpenShift集群上构建镜像，则可以考虑使用S2I，因为使用S2I进行构建是内置功能。
Jib是Google的另一种工具，专门用于构建Java镜像。它包括Maven和Gradle插件，可以轻松构建镜像而不会扰乱Dockerfile。
最后是Bazel，它是Google的另一种工具，不仅用于构建容器镜像，而且是一个完整的构建系统。如果只想构建镜像，那么钻研Bazel可能会有些过头，但绝对会是一种不错的学习体验。
