亚马逊AWS官方博客

AWS Fargate – 无服务器化容器解决方案

AWS Fargate 是可以与 Amazon ECS结合使用的技术,让您在运行容器时不需要管理服务器或集群。使用 AWS Fargate,你不需要搭建控制平面,只需选择合适的实例类型,或配置应用程序堆栈的所有其它部分,比如网络、扩展、服务发现、负载均衡,安全组、权限或密钥管理。你只需要构建容器镜像,定义希望它如何运行、在何处运行,并为实际需要的资源付费。Fargate天生与Amazon VPC、自动扩展(Auto Scaling)、弹性负载均衡(ELB)、身份及访问管理(IAM)角色和密钥管理集成起来。AWS花了很多时间让Fargete随时可用于生产环境,制定了确保正常运行时间达到99.99%的服务级别协议(SLA),符合支付卡行业数据安全标准(PCI)、服务组织控制(SOC)、ISO和《健康保险可携性及责任性法案》(HIPAA)等法规或标准。

目前,Amazon ECS 具有两种模式:Fargate 启动类型和 EC2 启动类型。如果使用 Fargate 启动类型,您只需将应用程序打包到容器中,指定 CPU 和内存需求,选择awsvpc网络模型和 IAM 策略,然后直接启动应用程序。如果使用EC2 启动类型,您可以对运行容器应用程序的基础设施进行更精细的服务器级控制。Amazon ECS负责跟踪集群中的所有 CPU、内存及其他资源,并根据您指定的资源要求查找最适合运行容器的服务器。无论你使用Kubernetes、Mesos、Rancher、Nomad、ECS还是其他任何系统,有了Fargate,唯一要管理的是仅仅是应用程序本身的逻辑。AWS Fargate终于让容器在云计算的环境里发挥地淋漓尽致。

本文所涉及到的内容主要是围绕着AWS Fargate 启动类型,我们将演示如何使用AWS Cloud9进行代码编辑和提交,配合CodeCommit、CodeBuild、CodePipeline、Amazon ECS,基于Fargate进行容器应用的持续集成和持续部署,对外暴露ALB负载均衡,Fargate与DynamoDB进行增删改查等数据库操作。

一、使用Fargate运行容器

Fargate可以自定义CPU和内存大小的计算资源,但不需要维护和管理底层的计算实例资源。接下来我们将使用Amazon ECS集群,并用AWS Fargate启动类型来运行容器。 点击: https://console.thinkwithwp.com/ecs/home?region=us-east-1#/firstRun ,如下图所示,一个ECS集群可以启动多个Service,一个Service可以定义多个Task Definition,一个Task里面可以跑一个或者多个Container。

选择现有的sample-app的模板,网络模型选择awsvpc模式,在Task Definition中,你可以指定Task资源CPU和内存的大小。

在这里,我们先不使用ALB负载均衡,后面的实验中我们会加上这部分内容。

输入集群的名字,取名为workshop。审核所有信息之后启动集群。

等待几分钟时间,直至所有状态都变成“complete”。

查看Task状态,从一开始的PROVISIONING,到PENDING,最后变成RUNNING状态。

点击Task ID号: b956092f-4962-4342-bada-8e20802a6c44,在网络部分中可以看到网卡信息、私有IP、公有IP,以及Mac地址。

在浏览器输入公有IP地址,可以查看到httpd所在的应用已经部署成功。

二、启动Cloud9编码和提交代码

Cloud9背后运行的环境是在一台EC2上面的,VPC选择之前启动ECS集群自动创建的VPC。

三、 创建容器镜像仓库(Docker Image Repository)

(1)创建容器仓库Amazon ECR

输入容器仓库Amazon ECR的名字

(2)构建Docker镜像,首先打开Cloud9客户端,下载代码

git clone https://github.com/TerrificMao/fargate-workshop-app.git

cd fargate-workshop-app/

(3)根据下载的Dockerfile构建成docker image

docker build — tag 556776719183.dkr.ecr.us-east-1.amazonaws.com/workshop .

(4)确认构建的image是否成功

docker images 556776719183.dkr.ecr.us-east-1.amazonaws.com/workshop

(5)创建DynamoDB表,Table name取名为quotes,Primary partition key取名为ID。

(6)测试生成的docker image

首先安装 jq,jq 是一款命令行下处理 JSON 数据的开软软件,我们将用它查看返回结果。

sudo yum install -y jq

–detach代表容器将会运行在后台模式,–publish指定容器暴露80端口,–volume将AWS配置挂载到容器,使得应用可以访问AWS credentials,最后是docker镜像的地址,在前面创建Amazon ECR时生成。

docker run –detach –publish 80:80 –volume $HOME/.aws:/root/.aws \

556776719183.dkr.ecr.us-east-1.amazonaws.com/workshop

(7)测试应用

curl -Ss http://127.0.0.1/ | jq

(8)列出所有DynamoDB数据库里面的内容,此时显示是空的,因为里面还没有数据。

curl -Ss http://127.0.0.1/quotes | jq

(9)往DynamoDB里面增加一条数据

curl -Ss http://127.0.0.1/quotes -X PUT -H “Content-Type: application/json” -d ‘{“Text”:”AWS Fargate workshop demo on AWS Global Virginia region,”,”AttributedTo”:”AWS China”}’

(10)再次列出所有数据库里面的内容,可以显示内容了

curl -Ss http://127.0.0.1/quotes | jq

四. 将docker image推送至AWS ECR

首先登录到ecr

aws ecr get-login –no-include-email –region us-east-1

使用docker push推送

docker push 556776719183.dkr.ecr.us-east-1.amazonaws.com/workshop

五、创建Task Definition

(1)首先创建所需的AWS Role,选择Elastic Container Service,再选择Elastic Container Service Task,

(2)选择“创建策略”

(3)配置Fargate访问DynamoDB时所需的策略。

(4)输入名字“WorkshopAppPolicy”,Policy创建成功

(5)创建Task Definitions

(6)选择Fargate启动类型

(7)选择Task memory (GB),比如0.5GB;选择Task CPU (vCPU),比如0.25vCPU。然后选择“Add container”。

(8)点击“Add Container”,增加一个自定义容器,输入具体信息

点击“Create”

(9)使用自定义的docker image,增加container成功。

六、创建应用层负载均衡ALB

(1)选择应用层负载均衡ALB

(2)输入Load Balancer的名字“workshop”,选择对应的VPC。

(3)创建ALB的安全组

(4)由于Fargate底层不需要考虑计算资源,所以Target Type不需要选择instance,而是选择ip。

(5)注册Targets这块先不选择,可以利用ECS为我们去管理Target Group。

(6)ALB创建成功,记录DNS Name,比如: workshop-1435838475.us-east-1.elb.amazonaws.com

七、创建services选择Fargate启动类型

现在之前创建的VPC和对应的子网,并启动自动分配IP。

配置ALB负载均衡,配置侦听端口和Target Group。

暂时不选Auto Scaling

启动成功

使用命令行检查负载均衡器是否生效

curl -Ss http://workshop-1435838475.us-east-1.elb.amazonaws.com/quotes | jq

在浏览器输入ALB公网域名地址,可以通过Container查询到DynamoDB里面的内容。

或者可以选择常用的Postman进行调试

使用HTTP PUT方式,新增一条信息,插入到DynamoDB

查看HTTP PUT的执行结果

再次查看结果

从控制台检查DynamoDB中的内容

至此,Amazon ECS采用Fargate启动类型,已经在VPC内部部署了Container应用,Container对外暴露了ALB负载均衡地址,应用和DynaomDB数据库完成了交互,应用可以通过负载均衡直接对外访问。接下去,我们将介绍如何利用AWS开发运维相关的服务,基于Container进行持续集成和持续部署的方案。

八、基于容器的持续集成/持续部署方案

接下来我们将采用CodeCommmit托管代码,CodeBuild进行容器应用的构建,利用Amazon ECS进行容器编排调度和部署。整个流程如下所示

首先创建CodeCommit代码仓库,取名workshop

Event type可以先不填写。

利用命令行将代码推送到CodeCommit

git config –global credential.helper ‘!aws codecommit credential-helper $@’

git config –global credential.UseHttpPath true

git remote set-url origin https://git-codecommit.us-east-1.amazonaws.com/v1/repos/workshop

git push origin master

刷新AWS CodeCommit的控制台,发现代码已经上传。

接下去创建CodePipeline。在创建CodePipeline之前,先创建所需要的Role,选择CodeBuild。

复制如下Policy的内容,注意将resource内容替换成自己Account ID。

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:CompleteLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:InitiateLayerUpload",
                "ecr:BatchCheckLayerAvailability",
                "ecr:PutImage"
            ],
            "Resource": "arn:aws:ecr:us-east-1:556776719183:repository/workshop"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "ecr:GetAuthorizationToken",
            "Resource": "*"
        }
    ]
}
输入policy的名字WorkshopBuildPolicy

当然,在测试阶段,可以赋予一个Admin的权限。(选做)

接着创建CodePipeline

配置CodeBuild

配置CodeBuild的环境变量,Name: REPOSITORY_URI,Value: 556776719183.dkr.ecr.us-east-1.amazonaws.com/workshop

看到保持成功信息,接着点击“下一步”。Build provider选择AWS CodeBuild进行构建。

部署方式选择Amazon ECS,输入之前创建的集群名字workshop以及Service名字。

至此,CodePipeline创建完毕。

客户端更改代码

推送至AWS CodeCommit仓库

CodePipeline自动检测到代码更新

自动进入到代码构建阶段

自动使用Amazon ECS部署Fargate

不到一杯咖啡的时间,通过CodePipeline自动完成整个过程。

通过Postman测试新增加的delete方法,首先使用HTTP PUT新增一条记录到DynamoDB。

查看HTTP GET刚刚插入的里面的数据,记录返回的ID号: 46311760-3ac9-11e8-82b5-9ba0642ae25e。ID是DynamoDB数据库的主键,根据主键进行HTTP DELETE测试。

执行HTTP DELETE接口

刷新DynamoDB控制台

此时记录被成功删除。

至此,通过CodeCommit, CodeBuild, CodePipeline, Amazon ECS在Fargate中部署的代码已经生效,对外暴露负载均衡AWS ALB,并成功与DynamoDB数据库完成了增删改查等基本操作。整个流程大致如下。

附: 解决微服务系统的服务发现,可以基于ECS + Route53方案,请参考:

https://thinkwithwp.com/cn/blogs/china/ecsroute-53solve-micro-sevice-problem/

 

毛郸榕

AWS 解决方案架构师。负责基于 AWS 的云计算方案的架构设计,同时致力于 AWS 云服务在国内和全球的应用和推广,毕业于北京航空航天大学云计算专业,硕士,毕业后直接加入 AWS 中国。在大规模并发后台架构、物联网、DevOps 以及 Serverless 无服务器架构等领域有着广泛的设计与实践经验。