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
fetch
...
~ $ 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中构建镜像。
(责任编辑：admin)