网站费用单,做网站需要模板吗,网站备案地区名,做网站怎么qq邮箱验证来源 | CSDN编译 | 弯月 责编 | 张文头图 | CSDN下载于视觉中国【编者按】所谓三十年河东#xff0c;三十年河西#xff0c;曾经在容器领域叱咤风云的 Docker 如今已风光不再。抛开情怀#xff0c;我们不得不承认#xff0c;Docker 已经被后浪拍死在沙滩上了……大约 4 年前… 来源 | CSDN编译 | 弯月 责编 | 张文头图 | CSDN下载于视觉中国【编者按】所谓三十年河东三十年河西曾经在容器领域叱咤风云的 Docker 如今已风光不再。抛开情怀我们不得不承认Docker 已经被后浪拍死在沙滩上了……大约 4 年前的容器领域Docker 是唯一的选择。然而如今情况已然大不同Docker 不再是是唯一的选择它只不过是一个容器引擎而已。我们可以用 Docker 构建、运行、拉取、推送或检查容器镜像但是这里的每一项任务都可以用其他工具替代甚至有些工具比 Docker 还好。所以下面就让我们来探索一下这个领域然后卸载和忘记 Docker 吧。为什么说不要用 Docker 了如果长期以来你一直在使用 Docker那么说服你考虑其他工具可能需要多费点唇舌。首先Docker 是一个整体化的工具它试图做好所有的事情但往往只会适得其反。在大多数情况下我们应该选择专门的工具它可能只做一件事情但会做到最好。可能你因为担心需要学习使用不同的 CLI、不同的 API 或接受不同的概念所以会害怕使用其他工具。但是请不用担心。本文介绍的任何工具都可以完美地无缝衔接因为它们包括 Docker都遵循同一个 OCIOpenContainer Initiative开放容器计划规范。OCI 包括容器运行时、容器分发和容器镜像的规范涵盖了使用容器所需的所有功能。因为有了 OCI所以你可以自由选择适合自己的需求的工具与此同时你可以继续使用与 Docker 相同的 API 和 CLI 命令。因此如果你愿意尝试新工具那么我们就来比较一下 Docker 与其竞争对手的优缺点和功能看看是否有必要考虑放弃 Docker并尝试使用一些新鲜出炉的工具。容器引擎 在比较 Docker 与其他工具时我们需要分别讨论它的各个组件首先要讨论的就是容器引擎。容器引擎是一种工具它提供了处理镜像与容器的用户界面这样你就不需要与 SECCOMP 规则或 SELinux 策略苦苦纠缠了。除此之外容器引擎还可以从远程仓库提取镜像并将其解压到本地磁盘上。它似乎也运行容器但是实际上它的工作是创建容器清单以及镜像层的目录。接着它将这些文件传递给 runc 或 crun 等容器运行时。目前有很多容器引擎可供我们使用不过 Docker 最主要的竞争对手是红帽开发的 Podman。与 Docker 不同Podman 不需要运行守护进程也不需要 root 特权这些都是 Docker 长期以来一直备受关注的问题。从名字就可以看出来Podman 不仅可以运行容器还可以运行 pod。如果你不熟悉 pod 的话我可以简单介绍一下pod 是 Kubernetes 的最小计算单元由一个或多个容器 (主容器与负责支持主容器的 sidercar 容器) 组成。因此Podman 用户以后可以很轻松地将他们的工作负载迁移到 Kubernetes。下面我们通过一个简单的演示来说明如何在一个 Pod 中运行两个容器~ $ podman pod create --name mypod~ $ podman pod listPOD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID211eaecd307b 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 NAME3b27d9eaa35c docker.io/library/nginx:latest nginx -g daemon o... 2 seconds ago Up 1 second ago brave_ritchie 211eaecd307b mypodd638ac011412 docker.io/library/nginx:latest nginx -g daemon o... 5 minutesago Up 5 minutes ago cool_albattani 211eaecd307b mypoda901868616a5 k8s.gcr.io/pause:3.2 6 minutesago Up 5 minutes ago 211eaecd307b-infra 211eaecd307b mypod
最后一点,Podman 提供的 CLI 命令与 Docker 完全相同因此你只需执行alias dockerpodman
然后就像什么都没有发生过一样。除了 Docker 和 Podman 之外还有其他容器引擎但我并不看好它们的发展或者不适合用于本地开发。不过如果你想对容器引擎有一个较为完整的了解我也可以介绍一些LXDLXD 是 LXCLinux 容器的容器管理器守护进序。这个工具提供了运行系统容器的能力而这些系统容器提供了类似于虚拟机的容器环境。该工具比较小众没有太多用户所以除非你有非常特殊的用例否则最好还是使用 Docker 或 Podman。CRI-O如果在网上搜索 cri-o 是什么你可能会发现它被描述成了一种容器引擎。但实际上它是一种容器运行时。它既不是容器引擎也不适合“常规”使用。我的意思是说它是专门作为 Kubernetes 运行时CRI而创建的并不是给最终用户使用的。rktrkt读作“rocket”是 CoreOS 开发的容器引擎。这里提到这个项目只是为了清单的完整性因为这个项目已经结束了它的开发也停止了因此你不应该再使用它。构建镜像 对于容器引擎实际上 Docker 的替代品只有一种选择即 Podman。但是在构建镜像方面我们有很多选择。首先我们来看一看 Buildah。这也是一款红帽开发的工具可以很好地与 Podman 协同工作。如果你已经安装了 Podman可能会注意到 podman build 子命令因为它的二进制文件已经包含在 Podman 中了实际上这个命令只是经过包装的 Buildah。至于功能Buildah 沿用了 Podman 的方针没有守护进程不需要 root 特权而且生成的是符合 OCI 的镜像因此你的镜像的运行方式与使用 Docker 构建的镜像完全相同。它还能使用 Dockerfile 或 Containerfile 构建镜像 Dockerfile 与 Containerfile 实际上是同一个东西只是叫法不同罢了。除此之外Buildah 还提供了对镜像层更精细的控制支持提交大量的变更到单个层。我认为它与 Docker 之间有一个出乎意料的区别但这个区别是好事那就是使用 Buildah 构建的镜像特定于用户因此你可以只列出自己构建的镜像。你可能会问既然 Podman CLI 中已经包含了 Buildah为什么还要使用单独的 Buildah CLI 呢其实Buildah CLI 是 podman build 所包含的命令的超集因此你可能不需要直接使用 BuildahCLI但是通过使用它你可能会发现一些额外的功能。下面我们来看一个示例~ $ buildah bud -f Dockerfile . ~ $ buildah from alpine:latest # Create starting container - equivalent toFROM alpine:latestGetting image source signaturesCopying blob df20fa9351a1 doneCopying config a24bb40132 doneWriting manifest to image destinationStoring signaturesalpine-working-container # Name of the temporary container~ $ buildah run alpine-working-container -- apk add--update --no-cache python3 # equivalentto RUN apk add --update --no-cache python3fetchhttp://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gzfetchhttp://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz... ~ $ buildah commit alpine-working-containermy-final-image # Create final imageGetting image source signaturesCopying blob 50644c29ef5a skipped: already existsCopying blob 362b9ae56246 doneCopying config 1ff90ec2e2 doneWriting manifest to image destinationStoring signatures1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c ~ # buildah imagesREPOSITORY TAG IMAGE ID CREATED SIZElocalhost/my-final-image latest 1ff90ec2e26e 22 seconds ago 51.4 MB
从上面的脚本可以看出你可以直接使用 buildah bud 构建镜像其中 bud 代表使用 Dockerfile 进行构建你也可以使用其他脚本化的方法比如使用 Buildahs 的 from、run 和 copy它们分别对应 Dockerfile 中的 FROM、RUN、COPY 命令。接下来是 Google 的 Kaniko。Kaniko 也是利用 Dockerfile 构建容器镜像而且与 Buildah 类似它也不需要守护进程。但它与 Buildah 的主要区别在于Kaniko 更加侧重于 Kubernetes 中的镜像构建。Kaniko 本身也要作为镜像(gcr.io/kaniko-project/executor) 运行这对于Kubernetes 来说是没有问题的但对于本地构建来说不是很方便并且在某种程度上违背了构建镜像的目的因为你需要使用 Docker 运行 Kaniko 镜像才能构建镜像。话虽如此如果你正在寻找在 Kubernetes 集群中构建镜像的工具 (例如在 CI/CD 管道中)那么 Kaniko 可能是一个不错的选择因为它不需要守护进程而且更安全。以我个人的经验来看我认为两者都能很好地完成工作但是使用 Kaniko 时我遇到了一些随机的构建故障而且在将镜像推送到仓库时也出现了失败的情况。我要介绍的第三个工具是 buildkit也可以称之为 docker build 二代。它是 Moby 项目的一部分与 Docker一样只需设置 DOCKER_BUILDKIT1 docker build就可以启动这个工具并作为 Docker 的一个实验性功能使用。那么这个工具究竟能给你带来什么它带来了很多改进和很酷的功能包括并行构建、跳过未使用的阶段、更好的增量构建以及不需要 root 权限等构建。但是它仍然需要运行守护进程 (buildkitd)。因此如果你不想摆脱 Docker同时又想要一些新的功能和改进那么可以考虑一下 buildkit。这里我也会列出一些其他的工具它们有各自的特定用途但不是我的首选Source-To-ImageS2I这是一个不使用 Dockerfile直接根据源代码构建镜像的工具包。这个工具在简单的预期场景和工作流中表现良好但如果你需要多一些自定义如果你的项目的结构不符合预期那么它就变得非常烦人和笨拙。如果你对 Docker 不太满意或者你在 OpenShift 集群上构建镜像则可以考虑使用 S2I因为使用 S2I 构建镜像是它的一个内置功能。Jib这是一款由 Google 开发的工具专门用于构建 Java 镜像。它提供了 Maven 和 Gradle 插件可以让你轻松地构建镜像而无需在意 Dockerfile。Bazel这也是一款由 Google 开发的工具。它不仅可用于构建容器镜像而且是一个完整的构建系统。如果你只是想构建镜像那么使用 Bazel 可能会有点大材小用但绝对是一种不错的学习体验如果你愿意可以先从 rules_docker 着手。容器运行时 最后我们来说说负责运行容器的容器运行时。容器运行时是整个容器生命周期的一部分除非你对速度、安全性等有一些非常特殊的要求否则请不要乱动它。看到这里如果你感到厌倦了则可以跳过这一部分。但是如果你想了解一下在容器运行时方面都有哪些选择则可以看看下面这些runc 是一款流行的容器运行时且符合 OCI 容器运行时规范。Docker(通过containerd)、Podman 和 CRI-O 都在使用它因此无需我多言。它几乎是所有容器引擎的默认设置因此即便你在阅读本文后抛弃了 Docker很可能仍然会使用 runc。runc 的另一种替代品是 crun。这是一款由红帽开发的工具全部用 C 语言编写runc 是用 Go 编写的所以它比 runc 更快内存效率更高。由于它也是兼容 OCI 的运行时所以如果你想试试看的话应该能很快上手。虽然它现在还不是很流行但是它即将作为 RHEL 8.3 版本的备选 OCI 运行时出现在技术预览中而且考虑到它是红帽的产品所以最终很可能会成为 Podman 或 CRI-O 的默认配置。说到 CRI-O前面我说过它并不是容器引擎而是容器运行时。这是因为 CRI-O 没有推送镜像之类的功能但这些功能是容器引擎应该具备的。CRI-O 内部使用 runc 来运行容器。你不应该在自己的机器上尝试使用这个运行时因为它的设计就是 Kubernetes 节点上的运行时而且它是“Kubernetes 所需的唯一的运行时”。因此除非你要建立 Kubernetes 集群否则就不应该考虑 CRI-O。最后一个是 containerd它是云原生计算基金会即将推出的一个项目。它是一个守护进程可作为各种容器运行时和操作系统的 API 接口。它后台依赖于 runc它是 Docker 引擎的默认运行时。Google Kubernetes EngineGKE和 IBM Kubernetes ServiceIKS也在使用它。它是 Kubernetes容器运行时接口的一个实现与 CRI-O 一样因此是 Kubernetes 集群运行时的理想选择。镜像的检查与分发 最后一部分内容是镜像的检查与分发主要是为了替代 docker inspect并增加在远程仓库之间复制镜像的能力可选。在这里我要提到的唯一可以完成这些任务的工具是 Skopeo。它由红帽开发是 Buildah、Podman 和 CRI-O 的附属工具。除了基本的 skopeo inspectDocker 有相应的命令Skopeo 还可以通过 skopeo copy 令来复制镜像因此你可以直接在远程仓库之间复制镜像无需将它们拉取到本地。如果你使用本地仓库那么这个功能也可以作为拉取/推送。另外我还想提一下 Dive这是一款检查、探索和分析镜像的工具。它更加人性化提供了更加方便阅读的输出而且还可以更深入地挖掘镜像并分析和测量镜像的效率。此外它也很适合在 CI 管道中使用用于衡量你的镜像是否“足够高效”或者换句话说是否浪费了太多空间。总结 本文的目的并不是要说服你完全抛弃 Docker而是为了向你展示构建、运行、管理和分发容器及其镜像的整个过程以及所有备选工具。每个工具包括 Docker都有其优缺点因此评估哪些工具最适合你的工作流程和情况才是最重要的希望本文能在这方面为你提供一些帮助。参考链接https://martinheinz.dev/blog/35更多阅读推荐云原生体系下的技海浮沉与理论探索如何通过 Serverless 轻松识别验证码5G与金融行业融合应用的场景探索打破“打工人”魔咒RPA 来狙击使用 SQL 语句实现一个年会抽奖程序
