Docker 1.12迎来内置编排机制

三年前，Docker公司建立起一套深奥玄妙的Linux内核技术，而这一名为容器化的技术成果如今已经被行业所广泛接纳。今天，我们正积极在容器编排领域实现同样的飞跃。

容器编排的意义极为重大，在它的帮助下我们得以将容器从只能部署在单一主机之上，升级为能够将多种复杂的容器应用广泛部署于大量设备当中。要实现编排方案，我们需要一套独立于基础设施之外的分布式平台，贯穿整个应用生命周期始终，且能够在硬件发生故障或软件更新时继续正常起效。如今的编排方案与三年前的容器技术处于同样的发展阶段。目前大家面临着两种选项：要么组织起强大的技术专家团队共同构建一套复杂的特定系统，要么依赖外包服务商利用其技术资源帮助自己打理一切——但这也意味着我们需要从其手中购买全部硬件、服务、支持与软件。而后者正是大家无法回避的难题，即供应商锁定。

Docker用户一直在与我们进行讨论，并强调这两种选项都不够理想。相反，大家需要的是一套可供任何人使用的编排平台，且不会带来任何锁定状况。事实上，如果能将相关方案内置于平台当中，那么容器编排将因此变得更易于实现、更具可移植性、安全性、弹性且速度更快。

自Docker 1.12开始，我们已经向核心Docker Engine内添加了大量新功能，旨在进一步简化多主机与多容器编排流程。我们添加了新的API对象，包括Service与Node，允许大家利用Docker API在Swarm（即Docker Engine群组）之上部署并管理应用。而在Docker 1.12当中，我们将用事实证明，最理想的Docker编排方案正是Docker自身！

Docker 1.12的设计基于以下四项原则：

• 简单但强大——编排可谓现代分布式应用的核心所在；其如此重要，意味着我们必须以无缝化方式将其内置于核心Docker Engine当中。我们的编排方案遵循了容器设计理念，即无设置过程、只需学习少数简单概念且提供“还算不错”的使用体验。
• 弹性——设备时刻可能发生故障。对于现代系统而言，采用无单点故障设计以确保故障出现时不会导致应用停机已经成为一种必要。
• 安全性——安全性又是另一项默认要求。一切可能有碍安全性的因素，包括证书生成以及了解PKI等，都需要被移除。不过高级用户仍然能够从细处着手，更为全面地实现控制与审计。
• 可选功能与向下兼容性——作为拥有数百万用户的解决方案，向下兼容性是Docker Engine必须具备的能力。所有新功能以可选方式提供，大家可根据需要选择并为其分配对应的日常运行资源（内存与CPU等）。Docker Engine内的编排机制就像是我们这套平台内置的电池，但允许用户随意更换为使用其它第三方编排方案。

下面来看看Docker 1.12中新功能是如何起效的。

利用单一分散化构建块打造Swarm

一起的根源来自Swarm的创建——这是一套自组织与自修复引擎集合，能够极为便捷地实现节点：

docker swarm init

在引擎盖之下，这条命令会创建一个Raft节点协作组。作为首个节点，其负责实现管理功能，意味着它可以接收命令并调度任务。随着向Swarm中添加更多节点，后续节点将默认作为工作节点存在，分别执行由管理节点分派的任务。管理节点属于Raft协作组的组成部分。我们利用一套经过优化的Raft存储体系，其直接读取内存内容以提升调度工作的性能表现。

服务的创建与规模扩展

正如使用docker run命令运行单一容器，现在大家可以利用docker service命令在Engine Swarm上启动一个经过复制、分布与负载均衡的进程：

docker service create –name frontend –replicas 5 -p 80:80/tcp nginx:latest

这条命令声明了必要状态，即将由5套Nginx容器构成的Swarm作为单一内部负载均衡型服务，且于Swarm内任意节点的端口80上进行交付。从内部角度看，我们可以使用Linux IPVS实现这一效果——这是一套内核内4层多协议负载均衡机制，早在15年之前就已经登陆Linux内核。在IPVS负责于内核中路由各数据包的前提下，Swarm的路由方案能够提供高性能容器感知型负载均衡效果。

在创建服务时，我们可以选择创建复制型或者全局服务。复制型服务意味着我们定义的任意数量的容器都可扩散至全部可用主机。相比之下，全局服务则代表调度Swarm当中每台主机上同一容器的一个实例。

下面来谈谈Docker如何实现弹性。Swarm模式下的引擎拥有自组织与自修复特性，意味着它们能够识别我们定义的应用，并在出现差错时持续检查并修复环境。举例来说，如果大家关闭某台运行有Nginx实例的设备，则另一节点上会自动启动一套新的容器。如果关闭Swarm内半数设备所使用的网络交换机，则另外一半设备会顶替而上，接管对应工作负载。而在更新流程中，现在大家能够更为灵活地选定如何在做出变更后对服务进行重新部署。大家可以为Swarm上的各容器设定滚动或者并发更新模式。

希望将业务规模扩展至上百个实例？同样非常简单：

docker service scale frontend=100

常见的双层（web+db）应用可按以下方法创建：

docker network create -d overlay mynet
docker service create –name frontend –replicas 5 -p 80:80/tcp \
–network mynet mywebapp
docker service create –name redis –network mynet redis:latest

以下为此应用的基本架构示意图：

安全性

Docker 1.12的一大核心原则就是为Docker平台建立起一套完整的无配置、默认安全且开箱即用的使用体验。由于管理员们在向生产环境部署应用时，首先考虑的就是安全问题，因此Docker 1.12允许管理员利用与演示集群同样的步骤设置出安全的生产集群。

安全性需要事前考量而非事后补救，因此Docker 1.12提供经过严格认证的TLS、身份验证、授权与加密机制来保护Swarm中的各相关节点，且全部采取开箱即用的实现方式。

在建立首个管理节点时，Docker Engine会生成新的认证中心（简称CA）以及一组初始证书。在这一初始步骤完成后，加入该Swarm的每个节点都会自动被分配予一份新证书、随机生成的ID以及Swarm中的当前角色（管理节点或者工作节点）。这些证书将被作为其加密安全节点的身份且贯穿于整个生命周期，而管理节点则利用证书确保任务与更新以安全方式进行。

采纳TLS机制的一大阻力在于，我们一直很难创建、配置并维护必要的公钥基础设施（简称PKI）。在Docker 1.12中，一切设置与配置工作不仅以默认方式安全提供，我们还以自动化方式解决了TLS证书中最难搞定的部分：证书轮换。

从深层角度看，参与至Swarm内的各个节点都会持续不断地刷新自身证书，确保可能存在的泄露或者违规证书不会长久有效。用户可以对各证书的轮换频率进行设定，且最高可设置为每30分钟更换一次。

如果大家希望使用自己的认证中心，我们也支持外部CA模式，其中Swarm内的各管理节点会将各节点的证书签名请求转发至远程URL以完成集群加入流程。

Bundle

Docker 1.12引入了一种新的文件格式，名为Distributed Application Bundle（即分布式应用包，目前尚处于实验阶段）。Bundle是一种立足于服务之上的新型抽象机制，主要面向全堆栈应用。

一个Docker Bundle文件属于一组服务的声明性规范，负责说明：

• 运行哪套具体镜像版本
• 创建怎样的网络
• 各服务中的容器如何联网并运行

Bundle文件具备全面的可移植性，且可通过软件交付通道实现部署，这是因为其允许大家对多容器Docker应用进行规范指定与版本控制。

另外，Bundle文件规格简单且开放，大家可以随意根据需要创建Bundle。作为起步，Docker Compose以实验性方式支持Bundle文件的创建，大家也可以在Docker 1.12与Swarm中部署Bundle文件。

Bundle是一种非常高效的机制，能够将多服务应用从开发者的笔记本设备通过CI移动至生产环境。

Docker 1.12深度剖析

Docker 1.12还利用一系列有趣的新技术。节点间通信利用gRPC实现，其能够实现连接复用与标题压缩等HTTP/2出色特性。归功于protobufs，我们的传输结构效率也得到了显著提升。

感兴趣的朋友可以参阅Docker 1.12的其它说明资源：

• 为Mac或Windows平台下载Docker 1.12
• 在AWS或者Azure上进行尝试
• 参阅我们的教程：docs.docker.com/engine/swarm/swarm-tutorial/
• 关于Swarm的更多信息：docs.docker.com/engine/swarm/
• 体验Bundle：github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md

原文链接：Docker 1.12: Now with Built-in Orchestration!