Add orchestration

mozhuli <[email protected]>

orchestration/Docker.md

@@ -1,2 +1,21 @@
 # 4.2 Docker
 
+  在编写本文时，Docker在分布式环境中使用所谓的swarm模式，而在Docker 1.12之前，使用了独立的Docker Swarm模型。我们将在这里进行讨论。
+
+## Swarm模式
+
+  自Docker 1.12以来，[swarm模式](https://docs.docker.com/engine/swarm/)已与Docker Engine集成。嵌入在Docker Engine中的编排功能是使用[SwarmKit](https://github.com/docker/swarmkit/)构建的。
+
+  Docker中的Swarm由多个运行在swarm模式下的主机组成，充当manager和worker角色（主机可以是manager，worker或同时充当这两种角色）。想对于独立的容器，任务就是一个正在运行的容器，它是swarm服务的一部分，由swarm manager进行管理。Docker swarm模式中的服务定义为要在manager或worker上执行的任务。Docker的工作内容是维持所期望的状态; 例如，如果一个工作节点变得不可用，Docker会将这些任务调度到另一个主机上。
+
+  以swarm模式运行的Docker不会阻止您在组成群集的任何主机上运行独立的容器。独立容器和群集服务之间的本质区别是，只有群集管理员可以管理群集，而独立容器可以在任何主机上启动。
+
+  要详细了解Docker的swarm模式，请查看官方的“[Swarm模式入门](https://docs.docker.com/engine/swarm/swarm-tutorial/)”教程或在Katacoda上的“[Docker Orchestration - Swarm模式入门](https://katacoda.com/courses/docker/getting-started-with-swarm-mode)”在线进行实践。
+
+## Docker Swarm
+
+  Docker历史上有一个名为[Docker Swarm](https://docs.docker.com/swarm/)的本地集群管理工具。Docker Swarm[基于Docker API构建的](https://www.slideshare.net/Docker/2015-dockercon-orchestrationsysadmins)，其工作方式如下：有一个Swarm manager负责调度，以及负责本地资源管理的代理运行的每个主机上（图4-3）。
+
+![图4-3 Docker Swarm架构，基于T-Labs演示[PPT](https://www.slideshare.net/snrism/swarm-container-cluster-service)](../images/4-3.png)
+
+  Docker Swarm支持不同的[存储后端](https://docs.docker.com/swarm/discovery/)：etcd，Consul和ZooKeeper。您还可以使用静态文件通过Swarm捕获您的群集状态，最近引入了一个名为[wagl](http://ahmetb.github.io/wagl/)的基于DNS的Swarm服务发现工具。

orchestration/Mesos.md

@@ -1,2 +1,31 @@
 # 4.3 Apache Mesos
 
+  [Apache Mesos](http://mesos.apache.org)（图4-4）是一个通用的集群资源管理器，对于开发人员来说就像是抽象出来的一台巨大的计算机资源。 从某种意义上讲，Mesos就像是分布式操作系统的核心。因此，它永远不会被单独使用，而是总是与所谓的框架一起使用，例如Marathon（用于Web服务器等长时后台运行服务）或Chronos（用于批处理作业），或者大数据和快速数据框架（如Apache Spark或 Apache Cassandra）。
+
+![图4-4 Apache Mesos架构](../images/4-4.png)
+
+  Mesos支持容器化的工作负载（即运行Docker容器）和简单的可执行文件（例如，用于无状态和有状态服务的bash脚本或Linux ELF格式的二进制文件）。
+
+  在下面的讨论中，我假设您熟悉Mesos及其相关术语。如果您是Mesos新手，我建议您阅读David Greenberg的图书[Building Applications on Mesos（O'Reilly）](http://shop.oreilly.com/product/0636920039952.do)，它作为分布式应用程序开发人员的入门介绍特别有用。
+
+  Mesos网络的特点和能力主要取决于您所使用的Mesos容器：
+
+- 对于Mesos容器，有一些先决条件，比如需要使用Linux内核大于3.16的版本和并且安装了libnl。然后，您可以构建启用了网络隔离器的Mesos agent。在启动时，您可以使用类似下面的命令：
+
+```bash
+$mesos-slave --containerizer=mesos
+         --isolation=network/port_mapping
+         --resources=ports:[31000-32000];ephemeral_ports:[33000-35000]
+```
+
+上面这条命令将配置Mesos agent使用范围从31,000到32,000的非临时端口和从33,000到35,000范围内的临时端口。所有容器共享主机的IP，并且端口范围分布在这些容器上（目标端口和容器ID之间1：1的映射）。通过网络隔离器，您还可以进行性能限制，比如带宽限制；并且可以对每个容器执行网络流量的监控。参见Jie Yu在MesosCon 2015上的演讲“[Mesos中的每个容器网络监控和隔离](https://www.youtube.com/watch?v=ZA96g1M4v8Y)”了解更多关于这方面的内容。
+
+- 对于Docker容器，请参阅[第2章](../introduction/index.md)。
+
+  请注意，自0.23版开始，Mesos支持[IP-per-container](https://mesosphere.com/blog/ip-per-container-mesos/)。如果您想了解更多关于Mesos网络的信息，请查看MesosCon 2015上Christos Kozyrakis和Spike Curtis关于“[Mesos Networking](https://events.static.linuxfound.org/sites/events/files/slides/mesos-networking.mesoscon2015.pdf)”的演讲。
+
+  尽管服务发现不是Mesos的主要功能，但实际中经常使用Mesos特定的解决方案：Mesos-DNS（详见服务发现章节），同时还有许多新兴的解决方案，比如traefik（详见服务发现章节）。
+
+  *由于Mesos-DNS是Mesos推荐的默认服务发现机制，因此关注Mesos-DNS如何[表示任务](http://mesosphere.github.io/mesos-dns/docs/naming.html)是很重要的。例如，正在运行的任务可能具有（逻辑）服务名称webserver.marathon.mesos，您可以通过DNS SRV记录找到分配的端口。*
+
+  如果您想免费在线试用Mesos，可以使用Katacoda上的“[将容器部署到DC/OS](https://katacoda.com/courses/dcos/getting-started)”在线环境。

orchestration/Nomad.md

@@ -1,2 +1,23 @@
 # 4.4 Hashicorp Nomad
 
+  [Nomad](https://www.nomadproject.io)是研发Vagrant的HashiCorp公司所研发的集群调度工具。它于[2015年9月推出](https://news.ycombinator.com/item?id=10291777)，主要关注简单易用。据报道，其[scheduler](https://www.nomadproject.io/docs/internals/scheduling.html)的设计灵感来自谷歌的omega，它借鉴了诸如具有集群的全局状态以及采用乐观的并发调度等概念。
+
+  Nomad拥有一个基于代理的[架构](https://www.nomadproject.io/docs/internals/architecture.html)，具有一个可以承担不同角色的单一二进制文件，支持滚动升级以及驱逐节点进而重新调度等功能。Nomad对所有状态复制和调度都使用一致性协议，并使用gossip协议来管理服务器的地址以实现群集自治和多区域联合。 如图4-5中，您可以看到Nomad的架构：
+
+![图4-4 Nomad架构](../images/4-5.png)
+
+- server端负责接受来自用户的作业，管理客户端和计算任务的调度。
+
+- 客户端（每个VM实例一个客户端）负责与作业中的任务或应用程序进行交互。他们以pull的方式工作; 也就是说，他们在服务器上注册，然后他们定期轮询它以观察待处理的工作。
+
+  Nomad中的[作业](https://www.nomadproject.io/docs/job-specification/index.html)采用名为HCL的HashiCorp专有格式或JSON定义，Nomad提供命令行界面以及HTTP API与服务器进程进行交互。Nomad将基础设施抽象为区域和数据中心。区域可能包含多个数据中心，具体取决于您在何种规模上运行。您可以将AWS，Azure或Google Cloud中的zone（比如us-central1-b）看作数据中心，region看做区域（比如us-central1）。
+
+  我假定您熟悉Nomad及其术语。如果不是的话，我建议你看看“[Nomad：一种分布式，乐观并发的调度器：Armon Dadgar，HashiCorp](https://www.youtube.com/watch?v=YTmtBi3uNVU)”，它是对Nomad的一个很好的介绍，以及[Nomad官方文档](https://www.nomadproject.io/docs/)。
+
+  要尝试下Nomad，可以使用HashiCorp的[UI演示](https://demo.nomadproject.io/ui/jobs)或者使用Katacoda上的“[Nomad介绍](https://katacoda.com/hashicorp/scenarios/nomad-introduction)”免费的在线环境。
+
+  Nomad配备了几个所谓的任务驱动程序, 从通用执行程序到java, 再到qemu，最后到docker。对于Nomad所要求的[docker驱动程序](https://www.nomadproject.io/docs/drivers/docker.html)，在撰写本文时，Docker版本为1.10或更高版本中，使用端口绑定的方式来暴露Docker容器中服务。它为Docker提供了自动和手动端口映射方案。
+
+  有关网络功能的更多详细信息，例如映射端口和标签的使用，请参阅[文档](https://www.nomadproject.io/docs/jobspec/networking.html)。
+
+  在[v0.2](http://blog.xebia.com/scheduling-containers-and-more-with-nomad/)版本中，Nomad引入了基于Consul的服务发现机制（详见服务发现章节）。它包括健康检查，并假定在Nomad内部运行的任务也需要能够连接到Consul代理，Consul代理对使用桥接网络模式的容器环境提出了挑战。

orchestration/community.md

@@ -1,2 +1,11 @@
 # 4.5 社区很重要！
 
+  选择编排系统时需要考虑的一个重要方面那就是编排系统后面的社区。可以从以下几点进行考虑：
+
+- 社区的管理是否由正式的组织支持，如Apache软件基金会（ASF）或Linux基金会（LF）？
+
+- 邮件列表，IRC频道，bug/issue tracker, Git仓库（补丁或pr的数量）等方面看社区活跃程度如何？
+
+- 这个编排系统是由单个实体控制（或者隐式的）的吗？ 例如，Nomad由HashiCorp控制，Apache Mesos主要是Mesosphere（以及某种程度上是Twitter）控制的。
+
+- 是否有多个独立的云服务商和channel的支持？ 例如，您可以在许多[不同的环境中运行Kubernetes](https://blog.openshift.com/kubernetes-little-guide-install-options/)，并可以从许多组织以及Slack，邮件列表或论坛上获得帮助。

orchestration/index.md

@@ -1,2 +1,28 @@
 # 4. 编排
 
+  利用“牲畜模式”来管理基础架构，您不需要手动分配某些机器来运行应用程序。相反，您将利用编排系统来管理容器的生命周期。在图4-1中，您可以看到容器业务流程包含一系列功能，包括但不限于：
+
+- 组织原语：（如Kubernetes中的标签用于查询和分组容器）
+
+- 调度容器以在合适的主机上运行。
+
+- 自动健康检查：以确定容器是否存活，并准备好为流量提供服务并在必要时重新启动。
+
+- 自动调节（根据利用率或更高级别的指标增加或减少容器数量）
+
+- 升级策略，从滚动更新到更复杂的技术，如[A/B测试和金丝雀部署](http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/)
+
+- 服务发现，以确定具体提供本次服务的一个容器，通常也包括DNS的支持
+
+![图4-1 编配及其组成部分](../images/4-1.png)
+
+  配置升级功能（在节点上安装或升级本地操作系统或设置容器运行时）有时候被认为是编排的一部分，但不在本书的讨论范围之内。
+
+  服务发现（第5章详细介绍）和调度实际上是同一枚硬币的两面。调度程序决定容器在集群中的位置，并在`容器 - >位置`表单中为其他部分组件提供最新的映射关系。我们可以用各种方式表示映射，例如在etcd等分布式键值存储中，通过DNS或通过环境变量。
+
+  在本章中，我们将从以下容器编排解决方案的角度讨论网络和服务发现：Docker Swarm和swarm模式，Apache Mesos和HashiCorp Nomad。您的公司可能已经在使用这三种方案中的一个（我们将在第7章中详细介绍Kubernetes），因此，为了完整起见，这里还是值得探讨。尽管如此，截至2018年初，Kubernetes已经成为容器编排领域的事实标准。
+
+  *除了本章讨论的三种容器编排系统之外，还有其他（封闭源代码）解决方案可供您了解，其中包括Facebook的[Bistro](https://facebook.github.io/bistro/)，以及像[Amazon ECS](https://aws.amazon.com/cn/ecs/features/)之类的托管的解决方案。*
+  *如果您想更全面地探讨分布式系统调度方面的主题，我建议您阅读Google关于[Borg](https://research.google.com/pubs/pub43438.html)和[Omega](https://research.google.com/pubs/pub41684.html)的研究论文*
+
+  然而，在我们深入到容器编排系统之前，让我们回顾一下调度器（编排系统的核心组件）在集容器化工作负载的情况下实际是怎么执行调度的。

orchestration/scheduler.md

@@ -1,2 +1,11 @@
 # 4.1 scheduler实际上是做什么的？
 
+  分布式系统的调度程序根据用户的请求应用容器调度到一台或多台可用的主机上。例如，用户可能请求运行100个应用程序实例，因此调度程序需要找到可用主机来运行这100个实例。
+
+  我们来看一个具体的例子。 在图4-2中，您可以看到用户请求在集群中运行三个应用程序实例。调度程序根据对集群状态的了解以决定容器实例的放置位置。群集状态可能包括机器的使用情况，成功启动应用程序所需的资源以及限制，例如仅在支持SSD的计算机上启动此应用程序。
+
+![图4-2 分布式系统调度程序的行为](../images/4-2.png)
+
+  此外，在进行调度时，服务质量有时候也需要考虑在内; 有关更多详细信息，请参阅Michael Gasch的文章“[QoS，节点可分配和Kubernetes调度程序](https://embano1.github.io/post/sched-reconcile/)”。
+
+  如果您想了解更多有关在分布式系统中进行调度的内容，我建议您查看John Wilkes的一篇文章“[Google集群管理](https://www.infoq.com/presentations/cluster-management-google)”。

orchestration/summary.md

@@ -1,2 +1,5 @@
 # 4.6 本章小结
 
+  截至2018年初，Kubernetes（我们将在第7章中讨论）可以被认为是事实上的容器编排领域的标准。所有主要的云提供商，包括Docker和DC/OS（Mesos）都支持Kubernetes。
+
+  接下来，我们将继续讨论服务发现，这是容器编排系统的重要组成部分。