![screenshot]( "screenshot")
本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周一、三、五 与您不见不散！
两周前是我们在短短四年内举办的第八个 DockerCon 大会了。我们的贡献者、开发人员、IT用户、企业和生态系统合作伙伴社区已经增长到达数以百万计的规模了，这是基我们的创始人 Solomon Hykes 以民主化为前提实现软件容器的成果。今天如最开始一样，Docker 创建了简单的工具和通用的打包方法，将容器中的所有应用程序依赖关系都捆绑在一起。Docker 引擎使应用程序能够在任何基础设施上一致地运行，从而解决了开发人员和运维团队的依赖性难题，并消除了“它在我的笔记本上的工作！”的问题。
在过去的两年里，Docker 引擎的代码库已经被重构为几个可重用的组件，其中最重要的是“容器”（核心容器运行时）和 BuildKit 工具集（用于构建镜像部分的 Docker 引擎）。在 DockerCon 的贡献和合作中，Michael Crosby 和 Tonis Tiigli 对这两个项目进行了更新，详细的幻灯片请浏览 https://www.slideshare.net/Docker/docker-platform-internals 进行查看。
容器，在 Docker 引擎中的核心容器运行时已经被数以百万计的用户使用，并由成千上万的组织将其运行在生产环境中。18个月前，Docker 从 Docker 引擎中将容器分离出来，并将其捐赠给云原生计算基金会（CNCF）作为一个顶级项目，同时它与 Kubernetes 、 gRPC 和 Prometheus 结合紧密。Docker 与全球最大的五家云提供商 —— 阿里巴巴、AWS、谷歌、IBM和微软进行合作，目标是在所有云计算平台上进行开发，并提供解决方案。
Docker 捐赠的一个目的是通过提供核心容器运行时来促进容器生态系统的进一步创新，该容器运行时可供其他容器系统供应商和编排项目（如Kubernetes、DC / OS等）使用。容器的一个重要设计原则是具有对 Kubernetes 进行一流的支持却又不完全依赖于它，因为将核心容器运行时固定到 Kubernetes 仅将它的使用案例限制在 Kubernetes 上，而不考虑容器的其它用例，例如开发人员桌面、CI / CD、单节点部署、 Edge 和物联网。
今年4月公布的 containerd 1.1 实现了 Kubernetes Container Runtime Interface（CRI），因此它可以直接被 Kubernetes 和 Docker 引擎使用。它实现了命名空间，这样来自不同容器系统（例如 Docker 引擎和 DC/OS）的客户端可以在逻辑上进行分离的同时，在一个系统上利用单一的容器实例。此版本允许您插入任何 OCI 兼容的运行时，如 Kata 容器、 gVisor 等，并包含了许多性能改进，如更好的 pod 启动延迟和显示 cpu/内存使用情况的CRI插件。为了获得额外的性能优势，它用更高效的快照程序取代了图形驱动程序，而 BuildKit 利用了更快的构建。在 CRI 工作的 Kubernetes 社区成员在5月下旬就宣布 Kubernetes 的 containerd 1.1 的普遍可用性。
Michael 的演讲概述了 containerd 1.1 智能客户端的功能：从客户端进行 I / O 重定向、容器命名空间利用单个运行时实例与来自多个客户端（Kubernetes、Docker Engine、其他系统）的逻辑隔离以及当使用容器 Go 客户端函数库时，容器在 Golang 中的类型，（让人想起 Brendan Burn 的 Metaparticle 项目）。
----
Tonis 的演讲讲述了 BuildKit 带来的所有性能改进，以及由于其模块化架构而开放的功能。它使开源开发者能够直接使用 BuildKit 来创建新的构建系统，从而创建新的前端（超越 Dockerfiles）和后端（超越 Docker 镜像）。
BuildKit 将作为实验性功能集成到 Docker 18.06 版本中。这个新的实验性功能将带来 Dockerfile 的可扩展性：开发人员可以使用新的 #syntax 指令来创建 Dockerfile 的解析扩展：＃syntax = registry / user / repo：tag。
他们提供的容器镜像将知道如何解释 Dockerfile 中的新语法。Tonis 展示了一个扩展的例子，它可以理解成“RUN -mount”，并允许您在构建时加载一个卷，比如一个 Maven 仓库缓存，可为您的构建带来高达33倍的性能提升。这是 Docker 构建中最受欢迎的功能请求之一。
容器和 BuildKit 都在容器运行时和构建时间上来推动容器的可能性。事实上，他们已经集成到 Docker 引擎中了，这使得主流开发人员可以在组件项目中实现这些创新，而无需改变他们的工作流程。无论他们是从笔记本电脑中的 Docker Desktop 、用于生产的 Kubernetes 集群、使用容器对传统应用程序进行现代化的大型机、还是用于物联网场景的 Raspberry Pi来使用这些设备。无论他们使用哪种系统，开发人员和运维团队都可以从 Docker 引擎所提供的应用程序工作流程的可移植性中受益，从而可以在任何地方使用相同的可信代码库进行构建和运行容器。
总而言之，如果您想要确保拥有一个核心容器运行时，它可以在所有的编排器（Kubernetes、Swarm、AWS ECS 等）、Linux发行版、Windows和大型机中工作，并且在任何云上、在x86、ARM和 gpu 上运行，那么唯一的解决方案是容器。如果您想用优化的镜像构建解决方案来实现更大的价值，那么在 Docker 引擎中集成 BuildKit 是最好的解决方案。
