分析AWS所提供的针对Docker的EC2容器服务

EC2容器服务(ECS)是亚马逊web服务(AWS)新发布的产品。ECS的目的是使Docker容器更容易，它提供了一个集群和布局层，用于控制主机上的容器部署，以及部署后集群中容器的生命周期管理。ECS就像DockerSwarm，Kubernetes,代替Mesos等工具，它们在同一层工作，除了作为服务提供。与ECS不同的是，前者需要你自己来部署和管理，而ECS是“作为一种服务”提供的。ECS是基于一种专有的集群技术，而不是通过DockerSwarm，Kubernetes,实现了Mesos等引擎。这可以与Gogle容器引擎相匹配(GCE)相比之下，GCE后台是基于Kubernetes使用的。为什么我们需要容器安排？由ECS，Swarm，或者Kurbernetes提供的容器安排层在整个基于容器应用程序的部署和运行蓝图中占有非常重要的地位。首先，为了可扩展性，我们需要容器组成集群。随着负载的增加，我们需要增加更多的容器，横向扩展它们，跨服务器并行处理更高的负载。第二，我们需要建立一个容器集群，以确保健康和高可用性。当主机或容器出现故障时，我们希望容器能够重建，或者在另一个健康的主机上重新启动，以免影响整个系统。最后，编排层工具提供的一个重要功能就是抽象，让开发者远离具体的底层，实现细节。在容器化的世界里，我们不需要关心每一个独立的主机，只需要关注我们期望的容器在“适当的地方”运行。安排和集群工具为我们做这些事情，这样我们就可以很容易地将容器部署到集群中，并计算出最好的调度方法，以确定容器应该运行在哪些主机上。强度和高性能分布式集群系统的设计非常困难。所以像Kubernetes和Swarm这样的工具让我们不需要建立自己的集群。通过简化编排层的设置、运行和管理，ECS可以进一步实现无需人工参与的目标。因此，ECS无疑是使用容器运行应用程序的开发者应该密切关注的项目。ECS架构ECS不是一个黑匣子服务，它在你的EC2服务实例中运行，你可以像管理其他EC2服务一样使用SSH登录。ECS代理将在集群中运行，ECS代理是连接主机到中心的ECS服务的轻量级过程。ECS代理响应将主机注册为ECS服务，并控制所有容器部署或启动等请求／停止容器等生命周期事件。顺便说一句，使用go实现的ECS代理已经开源了。在创建新服务器时，我们不仅可以选择手动配置ECS代理，还可以选择使用预建的AMI镜像。通过亚马逊CTOWernernervogels的博客，我们了解到集中服务在逻辑上分为集群管理和主机上控制容器部署的调度。这背后的原因是容器的调度是可插入的，所以我们甚至可以使用其他调度器，如Mesos或其他开发人员定制的调度器。在撰写本文时，自定义调度器的文档仍在开发中，但我们可以阅读本博客并参考其源代码，这是迄今为止最好的参考实践。以下示意图很好地展示了ECS集群的逻辑水平：容器实例包含多个任务，任务包含多个容器，EC2容器实例集群可分散到多个可用区域，ElasticloadBalancers可用于跨任务的动态分布负载。这张图可以帮助读者整理阅读下一个内容的想法。Docker负载被描述为ECS中的服务和任务。任务本质上定义了一个或多个容器，包括您计划操作的容器的名称（与DockerHub的名称一致），以及在容器实例启动时相应端口和磁盘卷的映射信息。底层容器在任务运行时启动。当所有容器过程完成任务时，任务就结束了。任务可以很短或很长时间运行。例如，提供数据处理任务或web服务流程的短事件驱动程序。这里有一件事需要提醒，那就是架构上给定的任务，它所有的容器都在同一个主机上运行。如果我们打算定位容器，我们将使用在同一任务下组织它们的方法。如果我们打算在不同的主机上运行服务，我们只需要定义多个任务来实现控制。乍一看，这似乎是一种约束，但最终，它给了我们一定程度的控制容器定位能力，就像Kubernetespods一样。为了解释上述问题，如下面的截图所示，我们可以看到定义了一个具体的任务，该任务有一个容器，可以托管nginxweb服务。除任务外，服务在ECS概念中排名第二。服务是给定任务所要求运行的具体实例数。例如，如果我们有一个运行nginxweb服务容器的任务，我们应该定义一个服务，要求三个或更多的例子组成一个集群，以完成web服务的任务。服务是ECS如何提供弹性的保证。服务启动后，服务将监控任务是否活动，实例数量是否正确，容器数量是否正常。若任务停止运行，或无响应，或出现问题。如有必要，服务将要求启动更多的任务并清理任务。如下截图所示，集群中的nginx服务被定义为三个运行任务。这些任务都处于运行状态。