探究AWS所提供的针对Docker的EC2容器服务

EC2容器服务(ECS)是亚马逊web服务(AWS)新发布的一款产品。

ECS的目的是让Docker容器变的更加简单，它提供了一个集群和编排的层，用来控制主机上的容器部署，以及部署之后的集群内的容器的生命周期管理。

ECS是诸如Docker Swarm,Kubernetes,Mesos等工具的替代，它们工作在同一个层，除了作为一个服务来提供。这些工具和ECS不同的地方在于，前者需要你自己来部署和管理，而ECS是“作为服务”来提供的。

ECS是基于一种专有的集群技术，而不是通过诸如Docker Swarm,Kubernetes,Mesos等引擎实现的。这可以和Google容器引擎(GCE)作一对比，GCE后台使用的就是基于Kubernetes的。

我们为什么需要容器编排？

由ECS，Swarm，或者Kurbernetes所提供的容器编排这一层，在整个部署和运行基于容器的应用程序的整个蓝图中占有非常重要的位置。

首先，我们为了可扩展性需要容器组成集群。随着我们负载的增长，我们需要增加更多的容器，横向的扩展它们，跨服务器来并行的处理更高的负载。

第二，我们需要组建容器集群来保证健壮性和高可用性。当一台主机或一个容器失效时，我们希望容器可以重新构建，或许是在另外一台健康的主机上重新启动，从而让整个系统不会受到任何的影响。

最后，编排层的工具所提供的一个重要功能就是抽象，让开发者远离具体的底层实现细节。在容器化的世界中，我们毋需关心每个独立的主机，只需要关注我们期望的容器有多少在运行，在‘适当的地方’运行。编排和集群工具为我们做这些，让我们能够轻松的将容器部署到集群中，而且还能够计算出最佳的调度方式，从而决定容器应该运行在哪些主机上。

设计健壮性和高性能分布式集群系统的难度是非常大的。所以诸如Kubernetes和Swarm这样的工具让我们自己毋需去构建集群。ECS借此更进一步，通过简化编排层的设置、运行和管理来实现毋需人工参与。基于此缘故，ECS无疑是哪些使用容器来运行应用的开发者们应该密切关注的项目。

ECS架构

ECS并非是一个黑匣子的服务，它运行在你的EC2服务实例中，你可以使用SSH登录，像管理其它的EC2服务一样进行管理。

在集群中的EC2服务均会运行着一个ECS代理，ECS代理是一个连接主机到中心的ECS服务的轻量级进程。ECS代理响应主机注册到ECS服务，且掌控所有的请求，用于容器的部署或者是诸如启动／停止容器之类的生命周期事件。顺便说一下，使用go实现的ECS代理已经开源。

当创建一个新的服务器时，我们既可以选择手动的配置ECS代理，也可以选择使用预构建的已经配置完毕的AMI镜像。

通过亚马逊CTO Werner Vogels的博客,我们得知集中的服务已经逻辑上分为集群管理和在主机上控制容器部署的调度。这背后的缘由就是让容器的调度成为可插拔式的，所以我们甚至可以使用其它的调度器，例如Mesos或者是其它开发者自定义的调度器。自定义调度器的文档在本文撰写时还在开发当中，但是我们可以阅读此博客以及参考其源代码，这是目前为止最佳的参考实践。

下面的示意图很好的演示了ECS集群的逻辑层次：容器实例包含多个任务，任务包含多个容器，EC2容器实例集群可以分散到多个可用区域中，Elastic Load Balancers可以用于跨任务的动态分布负载。此图可以帮助读者在阅读接下来的内容整理思路。

服务和任务

在ECS中，Docker负载被描述为任务。

一个任务本质上是定义了一个或多个容器，其中包括你打算运行的容器的名称（和Docker Hub的名称保持一致），以及在容器实例启动时相应的端口和磁盘卷的映射信息。

当任务运行时，则启动了底层的容器。当所有的容器进程完成使命时，任务也就结束了。任务既可以是很短的也可以是长时间运行的，举例来说，提供一个数据处理任务的短的事件驱动，或者是一个web服务进程。

这里需要提醒一件事情，那就是架构上给定的一个任务，其所有的容器均运行在同一台主机中。如果我们打算定位容器的话，那么就使用在同一个任务下来组织它们的方法来实现。如果我们打算将服务运行在不同的主机，我们则仅需定义多个任务来实现控制即可。初看这似乎是一种约束，但最终它给我们的和Kubernetes pods一样的对容器定位在一定程度的控制能力。

为了说明上述问题，如下面截图所示，我们可以看到定义了一个特定的任务，此任务拥有一个容器，容器托管nginx web服务。

除了任务之外，服务是ECS概念中排名第二重要的。一个服务是给定一个任务所请求运行的特定的实例数量。举例来说，如果我们有一个如上述所定义的运行nginx web服务容器的任务的话，我们则要定义一个服务，来请求3个或更多的实例组成集群，从而完成web服务的任务。

服务是ECS如何提供弹性的保证。当一个服务启动后，服务就会监控其中的任务是否是活动的，实例的数量是否正确，以及其中容器的数量是否正常。如果任务停止运行了，或者是无响应了，又或者是出现问题了。服务就会请求启动更多的任务，以及必要的话清理任务。

下面截图所示，在集群中一个nginx服务被定义为3个运行的任务。这些任务个个都处于运行状态。