AWS Copilot

亚马逊弹性容器服务(Amazon ECS)的第一个官方命令行工具创建于2015年。2019年12月，我们共享了全新命令行体验的预览版，重新进行了全新设计，使您可以更轻松地在Amazon ECS上部署应用程序。今天，我们将分享我们在这个命令行工具上的一些进展，以及它的新正式名称：AWS Copilot。

AWS Copilot既面向现有ECS用户，也面向希望超越手动管理较低级别基础设施的ECS新用户，转而开始考虑其应用程序及其生命周期。默认情况下，Copilot基于生产就绪模式创建现代应用程序部署，这些模式包括ECS工程师和客户多年来设计的最佳实践。

如果您正在设计一个新的应用程序，您可能会从一个白板或心理图开始，其中每个服务都有方框，它们之间的对话方式也有线条。但稍后创建此架构时，需要考虑的云组件要多得多：vPC子网、负载均衡器、部署管道和应用程序有状态数据的持久存储。Copilot为您处理所有这些基本细节。您只需提供您的容器，然后让Copilot处理高可用性部署以及负载均衡器的创建和配置。您甚至可以让Copilot创建一个部署管道，每当您将新的提交推送到代码库时，该管道将自动重新部署最新版本的应用程序。

总而言之，如果您使用Copilot，您可以更快地从构想过渡到实施，并确信您部署的基础设施具有生产就绪配置。

您可以通过从GitHub下载最新版本到您的开发计算机来安装Copilot。例如：

Copilot使用与AWS CLI相同的凭证，因此如果您已经在开发计算机上使用了AWS CLI，您就可以开始使用了。如果您尚未安装或配置AWS CLI，可以按照以下说明进行安装或配置。确保在安装AWS CLI后运行AWS Configure。

最后但并非最不重要的一点是，您需要确保开发计算机上安装了Docker。AWS Copilot将使用Docker构建和打包您的应用程序。

首先，让我们快速了解一下Copilot中可用的高级命令：

应用程序-应用程序是系统各部分的分组机制。遵循Conway定律，您可以将组件拆分成对应于组织中不同团队的Copilot应用程序。例如，如果您仍然有一个拥有统一开发团队的小型组织，他们负责所有的工作，那么您可能可以将其组织为由一个或多个服务组成的单个应用程序。但是，如果您有多个团队，每个团队负责一组组件，并且很少跨团队工作，那么每个团队都应该有自己的Copilot应用程序。

环境-环境是应用程序部署的一个阶段。例如，您可以首先将应用程序部署到“QA”环境，以便可以在不影响客户的情况下对其进行测试。一旦验证该应用程序可以按预期工作，您就可以将该版本的应用程序部署到“生产”环境中，以便您的客户可以访问它。

服务-服务是容器内的单个长时间运行的代码进程。应用程序由一个或多个服务组成。如果您使用的是单一架构，那么每个应用程序很可能只有一个服务。更加分布式的架构将为每个应用程序使用多个服务。例如，您可能有一个具有面向Internet的负载平衡器的“网站”服务，一个只能通过服务发现访问的内部“API”服务，以及一个处理队列外作业的“后台工作者”服务。这些服务共同构成了单个应用程序的组件。

任何容器化应用程序的第一步都是它的Dockerfile。Dockerfile是一个小文件，它描述您的应用程序需要哪些依赖项和文件，以及要在容器中运行哪些程序。在本例中，我将使用一个简单的静态Nginx Web服务器作为演示应用程序，因此我的Dockerfile如下所示：

这个Dockerfile告诉Docker从一个已经有Nginx的预先构建的容器开始，然后在容器中添加一些本地HTML文件。我还包含了一条expose语句，让Copilot知道需要通过负载均衡器向世界公开哪些应用程序端口。

Copilot会自动找到我编写的Dockerfile。它会问我几个问题，比如我想给应用程序命名什么。然后，它将创建一个将服务部署到中的环境。它构建容器并将其推送到云中。最后但并非最不重要的一点是，它为我提供了一个可以访问应用程序的URL。

现在应用程序已经启动并运行，我可以在浏览器中加载它的URL并发送一些请求：

在向我的容器化Nginx服务发出几个Web请求之后，我可以使用Copilot通过运行以下命令来查看我的应用程序的日志：

在本例中，我的服务日志只是Nginx访问日志，但是如果我正在运行应用程序，我打印到stdout流的任何调试输出都会显示在这里。

您在Copilot中部署的第一个应用程序将使用默认配置启动，该配置仅将单个小容器部署到Fargate。此设置针对低成本进行了优化，非常适合开发目的，但尚未准备好用于生产流量。

现在，在将服务部署到此生产环境之前，我需要对此生产环境的配置进行一些更改。我可以在nyan/mark.yml找到我的服务的配置清单。

此清单文件包含我的应用程序的所有默认设置，例如它的端口、需要多少CPU和内存以及要运行多少个应用程序副本。具体地说，我希望覆盖生产环境的这些设置，因此我将以下语句添加到清单文件中：

这告诉Copilot，当我将应用程序部署到生产环境时，我希望运行该应用程序的两个副本，每个副本有1个CPU和2 GB内存。

这一次，Copilot将我的应用程序作为跨可用区分布的高可用性副本集部署到生产环境中，每个容器都有更多的CPU和内存。我可以使用ApacheBench运行一个简单的负载测试，以了解此部署可以处理多少流量：

该命令告诉ApacheBench向我的服务发出5000个请求，一次并发25个请求。

最终结果显示非常可接受的每秒353个请求，P99仅为165ms，每个请求的平均时间为70ms。

并发级别：测试花费的时间：25秒完成的请求：14.140失败的请求：0总传输数：7565000字节HTML传输：6395000字节每秒请求：353.60[#/秒](平均)每个请求的时间：70.701[毫秒](平均)每个请求的时间：2.828[毫秒](平均，所有并发请求)传输率：522.46[千字节/秒]最小接收连接次数(毫秒)平均[+/-SD]最大连接数中位数：12 34 15.6 30161处理数中位数最大连接数：12 34 16.1 34 334等待数：14 36 16.1 33 334总计：32 70 23.165 402一定时间内处理的请求百分比(Ms)50%6566%71 75%77 80%80 90%93 95%117 98%143 99%165 100%402(最长请求)。

如果我决定需要为比这更高的流量提供服务，我可以轻松地修改我的应用程序清单以通过增加生产计数来横向扩展，或者通过向我的服务添加更多CPU来纵向扩展，然后再次运行Copilot svc Deploy。

如您所见，Copilot旨在帮助您使用几个命令部署生产就绪的容器化服务。您提供Dockerfile，然后让Copilot在AWS上构建、推送和启动您的容器。

但这只是Copilot强大功能的开始。通过使用Copilot，您还可以轻松实现以下目标：

自动设置CI/CD管道，这样您只需推送到Git存储库即可进行部署。

在以后的文章中，我们将更深入地研究这些强大的功能。同时，请在项目的官方GitHub存储库上给我们任何反馈或功能请求。拉取请求也是受欢迎的！