本文档介绍了如何将Web应用程序部署到AWS Fargate上，利用Docker容器化技术。通过AWS Fargate，可以轻松运行无服务器容器，无需管理底层基础设施。教程适用于熟悉Docker和想要在云端部署Java或Python应用的开发者。
aws fargate
动机 (Motivation)
Docker is a fantastic tool to encapsulate and deploy applications in an easy and scalable way. Indeed, something I find myself doing very often is wrapping Python libraries into Docker images that I can later use as boilerplates for my projects.
Docker是一种出色的工具，可以轻松，可扩展地封装和部署应用程序。 确实，我发现自己经常做的事情是将Python库包装到Docker映像中，以后可以用作我的项目的样板。
In this post, I will illustrate how to register your Docker images in a container registry and how to deploy the containers in AWS using Fargate, a serverless compute engine designed to run containerized applications. Additionally, we will use Cloud Formation to deploy our stack in a programmatic way. Let’s get started!
在本文中，我将说明如何在容器注册表中注册Docker映像，以及如何使用Fargate(一种旨在运行容器化应用程序的无服务器计算引擎)在AWS中部署容器。 此外，我们将使用Cloud Formation以编程方式部署堆栈。 让我们开始吧！
在容器注册表中注册图像 (Register your images in a container registry)
Container registries are to Docker images what code repositories are to code. In a registry, you create image repositories to push and register your local images, you can store different versions of the same image, and other users can pull and update the image if they have access to the repo.
容器注册表对于Docker映像来说是代码存储库所要编码的代码。 在注册表中，您可以创建映像存储库来推送和注册本地映像，可以存储同一映像的不同版本，并且其他用户(如果他们可以访问该存储库)可以提取和更新该映像。
Now, let’s say you have developed locally an image that you want to deploy to the cloud. To do so, we would need to store our local image in a container registry from which it can be pulled and deployed. In this article, I will be using a fairly simple image that starts a web Python-Dash application on port 80.
现在，假设您已经在本地开发了要部署到云的映像。 为此，我们需要将本地映像存储在容器注册表中，以便从中进行部署和部署。 在本文中，我将使用一个相当简单的图像在端口80上启动Web Python-Dash应用程序。
We will use the ECR (Elastic Container Registry) to register our images. ECR is an AWS service, quite similar to DockerHub, to store Docker images. The first thing we have to do is creating a repository in ECR, we can use the AWS CLI as follows:
我们将使用ECR (弹性容器注册表)注册我们的图像。 ECR是一项与DockerHub非常相似的AWS服务，用于存储Docker映像。 我们要做的第一件事是在ECR中创建存储库，我们可以如下使用AWS CLI：
aws ecr create-repository \
--repository-name \
--image-scanning-configuration scanOnPush=
--region euYou should be able to see the repository in the AWS management console
您应该能够在AWS管理控制台中查看存储库
To push local images to our ECR repository we are required to authenticate our local Docker CLI into AWS:
要将本地映像推送到我们的ECR存储库，我们需要将本地Docker CLI验证到AWS：
aws ecr get-login-password --region region | docker login --username AWS --password-stdin acccount_id.dkr.ecr.region.amazonaws.comJust replace the aws_account_id and region appropriately. You should see the message Login Succeeded in the terminal, which means our local Docker CLI is authenticated to interact with the ECR.
只需适当地替换aws_account_id和region 。 您应该在终端上看到“ Login Succeeded ”消息，这意味着我们的本地Docker CLI已通过身份验证，可以与ECR交互。
Let’s push now our local image to our brand new repository. To do so we must tag our image to point to the ECR repository:
现在让我们将本地图像推送到全新的存储库中。 为此，我们必须标记图像以指向ECR存储库：
docker tag image_id account_id.dkr.ecr.eu-central-1.amazonaws.com/dash-app:latestNow we just have to push it to the ECR:
现在我们只需要将其推送到ECR：
docker push account_id.dkr.ecr.eu-central-1.amazonaws.com/dash-app:latestYou should see the pushed image in the AWS Console:
您应该在AWS控制台中看到推送的图像：
With that we come to the end of the section, let’s summarize: (i) we have created an image repository called dash-app in ECR, (ii) we have authorized our local Docker CLI to connect to AWS, and (iii) we have pushed an image to the repository. In the next section, we will cover how to deploy this image in AWS.
到此为止，我们来总结一下：(i)我们在ECR中创建了一个名为dash-app的映像存储库，(ii)我们已授权本地Docker CLI连接到AWS，并且(iii)已将图像推送到存储库。 在下一节中，我们将介绍如何在AWS中部署该映像。
在AWS中部署Docker容器 (Deploy Docker containers in AWS)
Leaving Kubernetes aside, AWS provides several options to deploy containerized applications:
除了Kubernetes，AWS还提供了几种部署容器化应用程序的选项：
- Deploying containers on EC2, usually within an auto-scaling group of instances. In this scenario we are responsible for patching, securing, monitoring, and scaling the EC2 instances. 通常在自动缩放实例组内在EC2上部署容器。 在这种情况下，我们负责修补，保护，监视和扩展EC2实例。
Deploying containers on AWS Fargate. Since Fargate is serverless, there are no EC2 instances to manage or provision. Fargate manages the execution of our tasks providing the right computing power (a task in this context refers to a group of containers that work together as an application).
在AWS Fargate上部署容器。 由于Fargate无服务器，因此无需管理或配置EC2实例。 Fargate管理我们的任务提供正确的计算能力执行(在这种情况下一个任务是指一组容器一起工作作为一个应用程序)。
In this section, we will focus on the second option, illustrating how to roll out our web application on AWS Fargate. In addition, we will allocate all the necessary resources with AWS Cloud Formation.
在本节中，我们将重点介绍第二个选项，说明如何在AWS Fargate上推出我们的Web应用程序。 此外，我们将通过AWS Cloud Formation分配所有必要的资源。
云的形成 (Cloud Formation)
Cloud Formation is an AWS service to provision and deploy resources in a programmatic way, a technique usually referred to as infrastructure as code or IaC. In IaC, instead of allocating resources manually through the management console, we define our stack in a JSON or YAML file. The file is then submitted to Cloud Formation which automatically deploys all the resources specified in it. This has two main advantages: (i) it makes it easy to automate resources provisioning and deployments, and (ii) the files help as documentation of our cloud infrastructure.
云形成是一项AWS服务，用于以编程方式配置和部署资源，该技术通常称为基础结构，即代码或IaC。 在IaC中，我们通过JSON或YAML文件定义堆栈，而不是通过管理控制台手动分配资源。 然后，该文件将提交给Cloud Formation，后者将自动部署其中指定的所有资源。 这有两个主要优点：(i)使自动化资源配置和部署变得容易，以及(ii)文件帮助作为我们的云基础架构的文档。
Although defining our stack in a JSON/YAML file requires going through a learning curve and forgetting about AWS management console and its truly easy to use wizards, it definitely pays off in the long run. As your infrastructure grows, keeping all the stack as code will be incredibly helpful to scale productively.
尽管在JSON / YAML文件中定义堆栈需要经历学习过程，而忘记了AWS管理控制台及其真正易于使用的向导，但从长远来看，它肯定会有所回报。 随着基础架构的增长，将所有堆栈都保留为代码将非常有助于有效地进行扩展。
堆栈 (The stack)
Now, let’s list the resources we need to run our application:
现在，让我们列出运行应用程序所需的资源：
Task: It describes the group of Docker containers that shape our application. In our example, we simply have one image.
任务 ：它描述了构成我们的应用程序的Docker容器组。 在我们的示例中，我们仅具有一张图像。
ECS Service: It takes care of running and maintaining the desired number of instances of a task. For example, if a task fails or stops, the ECS Service can automatically launch a new instance to keep the desired number of tasks in service.
ECS服务 ：它负责运行和维护所需数量的任务实例。 例如，如果任务失败或停止，则ECS服务可以自动启动新实例，以保持所需数量的任务在服务中。
Fargate: A serverless compute engine for containers. With Fargate there is no need to book and manage servers. It automatically supplies compute power to run our tasks.
Fargate ：一种用于容器的无服务器计算引擎。 使用Fargate，无需预订和管理服务器。 它自动提供计算能力来运行我们的任务。
Network resources: we need as well a VPC, a public subnet connected to an internet gateway through a routing table (don’t forget we are deploying a web application that should be reachable from the internet), and a security group to run our containers securely. You don’t need to set up those resources if you already have a network configuration in place, although I include them in the Cloud Formation script.
网络资源 ：我们还需要一个VPC，一个通过路由表连接到Internet网关的公共子网(不要忘记我们正在部署应该可以从Internet访问的Web应用程序)以及一个安全组来运行我们的容器安全地。 尽管我已经将它们包括在Cloud Formation脚本中，但是如果您已经有了网络配置，则无需设置这些资源。
Now, without further ado, let’s jump into the stack. The Gist below contains all the resources required. Let’s explain them in details:
现在，不用多说，让我们跳入堆栈。 下面的要点包含所有必需的资源。 让我们详细解释一下：
VPC-FARGATE: This is the VPC. It is important enabling DNS support and DNS Hostnames to reach the ECR and pull the images.VPC-FARGATE：这是VPC。 使DNS支持和DNS主机名到达ECR并提取图像非常重要。INT-GATEWAY: This is an internet gateway, it is needed to expose the subnet to the internet.INT-GATEWAY：这是一个Internet网关，需要将子网公开到Internet。ATTACH-IG: This attaches the internet gateway to the VPC.ATTACH-IG：这会将Internet网关连接到VPC。ROUTE-TABLE: This is a routing table, to which we will add the rules to expose the subnet to the internet gateway.ROUTE-TABLE：这是一个路由表，我们将在其中添加规则以将子网公开到Internet网关。ROUTE: This adds a rule to the routing table previously described. It forwards traffic to the internet gateway.ROUTE：这会将规则添加到前面描述的路由表中。 它将流量转发到Internet网关。SUBNETFARGATE: This is the subnet to host our services. We define the availability zone and the VPC to which it belongs.SUBNETFARGATE：这是托管我们的服务的子网。 我们定义可用性区域及其所属的VPC。SUBNETROUTE: This associates the routing table to the subnet.SUBNETROUTE：这会将路由表与子网关联。SGFARGATE: This is the security group to be applied to our services. It allows traffic on ports 443 and 80 over HTTPS and HTTP protocols.SGFARGATE：这是将应用于我们的服务的安全组。 它允许通过HTTPS和HTTP协议在端口443和80上进行通信。FARGATECLUSTER: It defines the Fargate cluster to host our services.FARGATECLUSTER：它定义了Fargate集群来托管我们的服务。ECSTASK: Determines the tasks to be executed. It includes the list of Docker images that make the task. For each container, it registers ports mapping, starting commands, and logging options. Images are pulled from the ECR repository set up before.ECSTASK：确定要执行的任务。 它包括执行任务的Docker映像列表。 对于每个容器，它都注册端口映射，启动命令和日志记录选项。 图像是从之前设置的ECR存储库中提取的。SERVICE: Defines the ECS Service that will launch and maintain our tasks. If you already have a network configuration in place and don’t need to create a new subnet and security group, just reference those existing resources in theNetworkConfigurationsection of the ECS Service.SERVICE：定义将启动和维护我们的任务的ECS服务。 如果你已经有到位的网络配置，不需要创建一个新的子网和安全组，只是引用这些现有资源在NetworkConfiguration的ECS服务的部分。
{
"Resources": {
"VPCFARGATE": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "10.0.0.0/16",
"InstanceTenancy": "default",
"EnableDnsSupport": "true",
"EnableDnsHostnames" : "true"
}
},
"INTGATEWAY": {
"Type": "AWS::EC2::InternetGateway"
},
"ATTACHIG": {
"Type": "AWS::EC2::VPCGatewayAttachment",
"DependsOn": ["VPCFARGATE", "INTGATEWAY"],
"Properties": {
"InternetGatewayId" : {"Ref": "INTGATEWAY"},
"VpcId" : {"Ref": "VPCFARGATE"}
}
},
"ROUTETABLE": {
"Type" : "AWS::EC2::RouteTable",
"DependsOn": ["VPCFARGATE"],
"Properties" : {
"VpcId" : {"Ref": "VPCFARGATE"}
}
},
"ROUTE": {
"Type": "AWS::EC2::Route",
"DependsOn": ["VPCFARGATE", "INTGATEWAY", "ROUTETABLE"],
"Properties": {
"RouteTableId": {"Ref": "ROUTETABLE"},
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": {"Ref": "INTGATEWAY"}
}
},
"SUBNETFARGATE": {
"Type": "AWS::EC2::Subnet",
"DependsOn": ["VPCFARGATE"],
"Properties": {
"AvailabilityZone" : "eu-central-1a",
"CidrBlock" : "10.0.0.0/24",
"MapPublicIpOnLaunch" : "true",
"VpcId" : {"Ref": "VPCFARGATE"}
}
},
"SUBNETROUTE": {
"Type" : "AWS::EC2::SubnetRouteTableAssociation",
"DependsOn": ["SUBNETFARGATE", "ROUTETABLE"],
"Properties" : {
"RouteTableId" : {"Ref": "ROUTETABLE"},
"SubnetId" : {"Ref": "SUBNETFARGATE"}
}
},
"SGFARGATE": {
"Type": "AWS::EC2::SecurityGroup",
"DependsOn": ["VPCFARGATE"],
"Properties": {
"GroupDescription" : "Fargate Security Group",
"GroupName" : "Fargate-SG",
"SecurityGroupIngress" : [
{
"CidrIp" : "0.0.0.0/0",
"Description" : "Allow HTTP traffic on port 80",
"FromPort" : 80,
"IpProtocol" : "tcp",
"ToPort" : 80
},{
"CidrIp": "0.0.0.0/0",
"Description": "Allow HTTPS traffic on port 443",
"FromPort": 443,
"IpProtocol": "tcp",
"ToPort": 443
}
],
"VpcId" : {"Ref": "VPCFARGATE"}
}
},
"FARGATECLUSTER": {
"Type": "AWS::ECS::Cluster",
"Properties": {
"ClusterName": "Cluster-CF"
}
},
"ECSTASK": {
"Type": "AWS::ECS::TaskDefinition",
"Properties": {
"ContainerDefinitions": [
{
"Name": "dash-container",
"Image": "account_id.dkr.ecr.eu-central-1.amazonaws.com/dash-app:1.0",
"PortMappings": [
{"ContainerPort": 80, "HostPort": 80, "Protocol": "tcp"}
],
"LogConfiguration": {
"LogDriver": "awslogs",
"Options": {
"awslogs-group": "/ecs/task-medium",
"awslogs-region": "eu-central-1",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"Cpu": 512,
"Memory": 1024,
"NetworkMode": "awsvpc",
"RequiresCompatibilities": ["FARGATE"],
"TaskRoleArn": "ecsTaskExecutionRole",
"ExecutionRoleArn": "ecsTaskExecutionRole",
"Tags": [
{
"Key": "created_by",
"Value": "CloudFormation"
}
]
}
},
"SERVICE": {
"Type": "AWS::ECS::Service",
"DependsOn": ["ECSTASK", "FARGATECLUSTER", "SUBNETFARGATE", "SGFARGATE"],
"Properties": {
"Cluster" : "Cluster-CF",
"DeploymentConfiguration" : {
"MaximumPercent": 200,
"MinimumHealthyPercent": 100
},
"DeploymentController" : {"Type": "ECS"},
"DesiredCount" : 1,
"LaunchType" : "FARGATE",
"NetworkConfiguration" : {
"AwsvpcConfiguration": {
"AssignPublicIp" : "ENABLED",
"Subnets": [{"Ref": "SUBNETFARGATE"}],
"SecurityGroups": [{"Ref": "SGFARGATE"}]
}
},
"SchedulingStrategy" : "REPLICA",
"ServiceName" : "Service-CF",
"TaskDefinition" : {"Ref": "ECSTASK"}
}
}
}
}Once your file is ready, upload it to Cloud Formation to create your stack:
准备好文件后，将其上传到Cloud Formation创建您的堆栈：
Follow the steps in the management console to launch the stack. Once finished, Cloud Formation will automatically start provisioning the services. You can follow its progress in the events tab:
按照管理控制台中的步骤启动堆栈。 完成后，Cloud Formation将自动开始供应服务。 您可以在事件标签中关注其进度：
And more importantly, when ready, you can access your web application at the public IP address assigned to the running task!
更重要的是，准备就绪后，您可以使用分配给正在运行的任务的公共IP地址访问Web应用程序！
注意用户的政策 (Note on the user’s policies)
If you are following best practices, you are not creating resources with your AWS root account. Instead, you should be using a non-root user. However, you should note that to pass a role to a service, AWS requires the user who creates the service to have “Pass Role” permissions. In our example, we need our user to pass the role ecsTaskExecutionRole to the TaskDefinition service, and therefore we must grant the user permissions to do so. This is something to be done from the root account in the IAM or any account with IAM privileges. Simply add the policy bellow, and attach it to the user who will allocate all the resources.
如果您遵循最佳实践，则不会使用您的AWS root帐户创建资源。 相反，您应该使用非root用户。 但是，您应注意，要将角色传递给服务，AWS要求创建服务的用户具有“传递角色”权限。 在我们的示例中，我们需要用户将角色ecsTaskExecutionRole传递给TaskDefinition服务，因此我们必须授予用户权限。 这可以通过IAM中的根帐户或具有IAM特权的任何帐户来完成。 只需添加以下策略，然后将其附加到将分配所有资源的用户即可。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::account_id:role/ecsTaskExecutionRole"
}
]
}结论 (Conclusions)
We’ve covered a lot in this article. We’ve seen how to create an ECR repository and how to push Docker images to it. We’ve also had a brief introduction to CloudFormation and IaC. I would like to restate the importance of specifying your infrastructure and stack as code. As your infrastructure grows, having the stack defined in JSON or YAML files will make it easier to automate deployments, scale in a productive manner, and will provide certain documentation on your infrastructure. Finally, we used AWS Fargate to deploy docker containers in a serverless way, which spared us the burden of provisioning and managing servers.
我们在本文中介绍了很多内容。 我们已经看到了如何创建ECR存储库以及如何将Docker映像推送到其中。 我们还简要介绍了CloudFormation和IaC。 我想重申一下指定基础结构和堆栈作为代码的重要性。 随着基础架构的增长，在JSON或YAML文件中定义堆栈将使自动化部署，以高效的方式扩展规模变得更加容易，并将提供有关基础架构的某些文档。 最后，我们使用AWS Fargate以无服务器方式部署docker容器，从而减轻了配置和管理服务器的负担。
I hope you find this article helpful, thank you for reading.
希望本文对您有所帮助，感谢您的阅读。
翻译自: https://towardsdatascience.com/deploying-web-applications-with-docker-in-aws-fargate-bb942de733a4
aws fargate
扫一扫
2748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
