亚马逊AWS官方博客

Amazon Rekognition 现支持名人人脸识别

AWS在2016年底的re:Invent大会上发布了基于深度学习的图像分析服务Amazon Rekognition, 可以用以检测对象、场景和面孔,可以搜索和比较面孔,还可以识别图像中的不当内容。Amazon Rekognition 通过一系列简单的 API 来提供强大且准确的图像分析功能,消除了在应用程序中构建图像识别功能的复杂性。您无需具备计算机视觉或深度学习专业能力,即可利用 Rekognition 可靠的图像分析功能。借助 Rekognition API,您可以轻松快速地在任何 Web 应用程序、移动应用程序或互联设备应用程序中构建图像分析功能。

最近,AWS又为Amazon Rekognition增加了新的功能——名人识别。这个功能可以识别在政治、娱乐、体育、媒体、商业等各个领域的名人。名人识别是全球性的功能,而名人的名单也会不断增加。

要使用名人识别的功能,只需调用新增的RecognizeCelebrities API。此API首先检测图像中的人脸,然后返回匹配出的名人信息,和该名人在IMDB上的链接(如果有)。

您现在就可以使用AWS管理控制台,通过简单的上传或者拖拽(不会存储您的图像),体验名人识别的功能。

那我们再来看看Amazon Rekognition都能够识别哪些名人吧。

Amazon Rekognition已经能够识别出新科法网冠军,年仅20岁的拉脱维亚新星奥斯塔彭科。

Amazon Rekognition还能够识别出“国民老公”王思聪和他的父亲王健林。

利用Amazon Rekogntion,妈妈再也不用担心我分不清楚王珞丹和白百何了。

如此强大的Rekognition API 让您能够轻松地在应用程序中构建强大的视觉搜索和发现功能。Amazon Rekognition 已经与常用的 AWS 服务 (如 Amazon S3 和 AWS Lambda) 无缝集成,同时能够提供一致的响应时间而无需预置额外的容量;而且您只需为您分析的图像和存储的面孔元数据付费。无最低费用,无预先承诺。

Amazon AI一致致力于构建人人都能使用的人工智能环境,使每一位开发人员都能能找到适合的人工智能解决方案,更多信息,请参见: https://aws.amazon.com/cn/amazon-ai/

(注: 文章中的图片均来自互联网)

 

作者介绍

王宇博

AWS资深产品拓展经理,主要负责AWS大数据、人工智能、高性能计算相关服务和解决方案在中国的业务拓展。 在加入AWS之前,他在IBM担任资深产品经理,主要负责虚拟化、云计算等相关产品线在中国的市场战略推广及业务发展。 他具有近15年的IT行业经验,涉及软件开发、技术咨询、解决方案销售、产品策划与管理等领域。

免费试用 Amazon WorkSpaces 最长达 2 个月时间

我本人极为推崇亲身体验。我通常只在自己使用过所提及的服务后才会撰写博客文章,不过偶尔也有例外。如果您碰巧阅读了我爱 Amazon WorkSpace 这篇博客文章,您就会知道 Amazon WorkSpaces 是我最重要的生产力工具之一。我想告诉您的是,您将有机会免费试用 Amazon WorlSpaces。新的 Amazon WorkSpaces 免费套餐可让您启动两个标准服务包工作区,并在 2 个月的时间内,每月使用最多 40 个小时。您可以选择 Windows 7 或 Windows 10 桌面体验,这两种产品都以 Windows Server 为强大后盾。这两个选项都包含 Internet Explorer 11、Mozilla Firefox、7-Zip 和 Amazon Workdocs,还有 50 GB 存储空间。要使用此免费套餐,您必须在 AutoStop 模式下运行工作区 (默认情况下将为您选择此模式)。未使用的小时数将在第一个日历月结束时过期,而此免费套餐优惠将在第二个日历月结束时过期。之后,将按照 Amazon WorkSpaces 定价页面上列出的小时费率向您收费。要开始免费试用,请完成快速设置中的步骤,并选择有资格享受此免费套餐的服务包:

此优惠适用于提供WorkSpaces的所有 AWS 区域。

-Jeff

云端开发工具:AWS CodeStar

概述

2017年4月旧金山的AWS全球峰会上,一项名为CodeStar的新服务闪亮登场,他帮助您在AWS上快速开发、构建和部署应用程序。从此,AWS对软件开发生命周期的支持,向开发者那端又迈进了一步。

下图为DevOps相关的AWS服务:

AWS CodeStar的主要功能包括:

1. 快速开发:可选多种项目模版和编程语言,快速开发基于Amazon EC2、AWS Lambda 和 AWS Elastic Beanstalk 的Web应用程序、微服务和Alexa技能。

2. CI & CD:与其他AWS DevOps服务或第三方工具集成,您可以在几分钟内建立起持续集成和持续部署工具链,从而以更快的速度发布代码。

3. 团队协作:集中管理项目组成员的权限,这些权限被自动应用到项目中所有使用到的服务,无须额外创建复杂的IAM策略。

4. 项目管理:通过Dashboard可以看到项目的整体状况,最新的项目活动(例如最近一次代码变更、编译和发布的结果),还可以与Atlassian JIRA集成以便跟踪和管理问题。

接下来,我们谈一谈如何快速上手这款好用的服务。

前提条件

使用CodeStar之前,需要做一些准备工作,包括:

1. 用户:创建或使用您已有的一个AWS用户,登录控制台,并确认您拥有该用户的access key和secret key。

2. 权限:如果希望该用户可以创建CodeStar项目,则需要赋予他AWSCodeStarFullAccess权限。如果该用户已经被加入其他CodeStar项目,则他已经被分配了相应的权限。

3. 证书:为了将本地的代码变化递交到CodeStar项目,您需要生成一个HTTPS Git证书,用以连接您在云端的私有Repository。请参阅:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/getting-started.html#git-credentials

4. 密钥对:如您希望访问CodeStar项目创建的EC2资源,则需要创建或使用一个已有的密钥对。

5. Git:在本地安装Git工具。请参阅:https://git-scm.com/downloads

好了,准备工作完毕,现在开始创建您的第一个CodeStar项目吧!

开始使用

目前CodeStar仅在EU (Ireland)、US East (N. Virginia)、US East (Ohio)和US West (Oregon)四个区域可用,选择CodeStar服务后,出现如下画面:

第一次使用时,会提示您创建CodeStar的service role,该服务角色将以您的名义创建、管理所选择的资源,并在仪表板中展示资源的信息。

然后,我们会看到CodeStar提供给您丰富的项目模版。本例选择使用Node.js在EC2上搭建一个Web应用程序。

接下来给项目起个名字(自动生成项目ID);然后勾选“AWS CodeStar would like permission to administer AWS resources on your behalf”,将service role赋予CodeStar,从而创建项目和资源;最后还可以点击“Edit Amazon EC2 Configuration”,选择EC2实例类型、所在VPC和子网。

点击下一步之后,会让您选择一个用于登录EC2的密钥对。

首次使用CodeStar的用户,需要输入昵称和电子邮件。

接下来选择您偏爱的IDE工具,包括:Visual Studio,Eclipse和命令行工具。我们暂时选择Skip略过,在后面的“特点:与IDE集成”中详细介绍。

至此,CodeStar项目创建完毕。您可以在Dashboard右侧的CodePipline窗口中看到,程序被自动递交到CodeCommit做代码管理,并通过CodeDeploy自动部署于EC2实例,同时给出了访问Web应用的Endpoint。关于CodePipline服务,请参考:https://aws.amazon.com/cn/codepipeline/

点击CodeStar左侧菜单栏中的Code选项,转向CodeCommit服务,可以看到代码管理的详细信息。关于CodeCommit服务,请参考:https://aws.amazon.com/cn/codecommit/

点击CodeStar左侧菜单栏中的Deploy选项,转向CodeDeploy服务,可以看到应用部署的详细信息。关于CodeDeploy服务,请参考:https://aws.amazon.com/cn/codedeploy/

在浏览器中通过Endpoint访问Web应用,成功显示如下页面。

若要修改代码,点击CodeStar左侧菜单栏中的Code选项,转向CodeCommit服务。点击Clone URL,选择HTTPS,拷贝Repository链接。

在本地打开命令行窗口,更改至目标目录,运行“git clone 上一步拷贝的链接“将代码复制到本地。然后在本地编辑代码,本例对index.html的Header文字做了修改。最后在命令行窗口中运行下述命令,将变化递交到Repository:

git add index.html

git commit -m "Changed title. "

git push

//注:有两种方法可以递交代码变化,除了这里介绍的Git客户端,还可以通过IDE。第二种方法会在后面的“特点:与IDE集成”中详细介绍。

回到CodeStar Dashboard,在右侧可以看到代码已成功递交到CodeCommit,同时自动部署到EC2。

重新刷新页面,我们发现Header文字已变更。细心的观众还注意到,这个页面的背景颜色会随时间变化。怎么样,CodeStar的使用是不是很简单呢?

特点

最后,说几个AWS CodeStar为人称道,也非常实用的特性。

1. 快速开发:提供给您多种项目模板(Web应用程序、微服务和Alexa技能),您可以选择自己喜爱的编程语言(Java、JavaScript、PHP、Ruby 和 Python),CodeStar会帮助您在Amazon EC2、AWS Lambda 和 AWS Elastic Beanstalk上搭建起相应的运行时环境和应用程序框架。

2. CI & CD:与AWS或第三方DevOps工具集成,迅速搭建持续集成和持续部署工具链。AWS的DevOps服务包括:

与AWS紧密合作的第三方DevOps工具包括:

本文的CI & CD流程和使用的服务如下图所示:

3. 与IDE集成:CodeStar可以与您喜爱的IDE集成,在IDE中进行开发,代码变化将被递交到CodeStar项目中,并自动触发CI & CD流程。接下来以Eclipse为例说明;关于与Visual Studio的集成,请参阅:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/setting-up-ide-vs.html

推荐使用Neon/Mars/Luna版本的Eclipse IDE for Java EE Developers,他包含了Elastic Beanstalk 需要的Eclipse Web Tools,以及Amazon SimpleDB需要的Eclipse Data Tools。

在Eclipse中安装AWS Toolkit for Eclipse插件。

输入URL:https://aws.amazon.com/eclipse,选择所有插件,点击Next后按提示安装。

安装完毕后,在偏好设置中输入您的access key和secret key(如果曾用AWS CLI设置过,则自动显示于此),以便Eclipse可以访问您的AWS资源。

导入CodeStar项目。

导入时需要指定用户和区域,选择项目,输入用于HTTPS登录CodeCommit的用户名和密码。点击Next后按提示完成。

开始编辑代码,完成后对修改的文件右键,选择Team->Commit。

在弹出的Git Staging窗口中输入递交信息,然后点击Commit and Push,确认无误后点击OK。

返回CodeStar,从左侧菜单栏中打开CodePipline,可以看到修改后的代码已被递交到云端Repository,应用程序被自动部署到EC2实例。通过Endpoint访问网页,发现修改成功。

4. 团队协作:您可以将团队成员添加到项目中,并通过指定他们的角色,轻松管理访问权限。一共有三种角色可供选择:

角色名称 项目仪表盘和状态 访问或修改项目资源 增加或删除团队成员 删除项目
所有者 X X X X
贡献者 X X
观察者 X

在Dashboard左侧菜单栏中点击Team,即可增加团队成员。

您可以随时调整他们的角色,例如:张三离开项目组,改去做PMO;通过控制台或CLI,可将张三从贡献者改为观察者,并拒绝张三远程访问。此外,一个团队成员可以同时属于多个项目,在不同项目内可以拥有不同角色。

5.       项目管理:Dashboard中,除了右侧的CI & CD信息,还提供Team Wiki、代码变更履历、应用程序性能监控等信息。

还可以与大名鼎鼎的Atlassian JIRA集成,实现问题跟踪功能,您可以轻松跟踪项目进度、待办事项和最新发布。关于Atlassian JIRA软件,请参阅:https://www.atlassian.com/software/jira

先在JIRA中创建项目。

然后将JIRA与CodeStar相关联,即可在Dashboard中进行问题管理。

6. 成本:使用AWS CodeStar不收取任何额外费用。您只需为用于开发和运行应用程序所预置的 AWS 资源付费。

参考

官方文档:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/welcome.html

作者介绍

何鹏

AWS解决方案架构师,14年软件开发、系统集成、移动应用和云计算解决方案经验。曾任NEC中国高级项目经理、摩托罗拉系统中国有限公司高级解决方案架构师。多年为国内外零售与物流行业大客户构筑其IT系统,此外还拥有丰富的面向金融服务、HFT(高频交易)初创企业的IT解决方案设计经验。目前在AWS中国负责推广针对初创企业的最佳云计算架构实践。

Amazon EC2 Container Service – 发布回顾、客户案例和代码

今天似乎是回顾在过去一年左右的时间里我们添加到 [madison] 的一些功能,以及与您分享一些客户成功案例和代码的大好时机!该服务使您可以轻松地在托管的 EC2 实例群集上运行任意数量的 Docker 容器,并获得完整的控制台APICloudFormationCLIPowerShell 支持。您可以将您的 Linux 和 Windows Docker 镜像存储在 EC2 容器注册表中以方便访问。

发布回顾

我们先来看一些最新的 ECS 功能和一些演示如何使用这些功能的有用的操作方法博客文章:

应用程序负载均衡 – 去年我们添加了对应用程序负载均衡器的支持。这一高性能的负载均衡选项在应用程序级别运行,允许您定义基于内容的路由规则。它支持动态端口,并且可以跨多个服务共享,使您更容易在容器中运行微服务器。要了解更多信息,请阅读有关服务负载均衡的信息。

任务的 IAM 角色 – 您可以通过向 ECS 任务分配 IAM 角色来保护您的基础设施。这允许您基于每个任务精细地授予权限,从而可根据每个任务的需要自定义权限。阅读任务的 IAM 角色,了解更多信息。

服务 Auto Scaling – 您可以定义扩展策略,以根据需求的变化来扩展和缩减您的服务 (任务)。您只需设置所需的最小和最大任务数,并创建一个或多个扩展策略,服务 Auto Scaling 将负责其余的工作。服务 Auto Scaling 的文档可帮助您使用此功能。Blox – 在基于容器的环境中,调度是将任务分配给实例的过程。ECS 为您提供三个选项:自动 (通过内置的服务计划程序)、手动 (通过RunTask 函数) 和自定义 (通过您提供的计划程序)。Blox 是一个开源计划程序,支持每个主机一个任务模型,并留有适应将来的其他模型的空间。它监控群集的状态,非常适合运行监控代理、日志收集器和其他守护程序风格的任务。

Windows – 我们推出了支持 Linux 容器的 ECS,随后又增加了支持范围以支持运行 Windows Server 2016 Base with Containers

容器实例耗尽 – 有时您可能需要从正在运行的群集中删除一个实例,以便缩减群集规模或执行系统更新。今年早些时候,我们添加了一组生命周期挂钩,以便您可以更好地管理实例的状态。请阅读博客文章如何在 Amazon ECS 中自动实现容器实例耗尽,以了解如何使用生命周期挂钩和 Lambda 函数来自动执行耗尽实例的现有工作,同时防止为其安排新工作的过程。

CI/CD 管道与代码* – 容器可简化软件部署,是 CI/CD (持续集成/持续部署) 管道的理想目标。使用 AWS CodePipeline、AWS CodeBuild、Amazon ECR 和 AWS CloudFormation 对 Amazon ECS 进行持续部署一文显示了如何使用多个 AWS 服务构建和运行 CI/CD 管道。

CloudWatch 日志集成 – 此次发布使您能够配置运行任务的容器,以将日志信息发送到 CloudWatch 日志进行集中存储和分析。您只需安装 Amazon ECS 容器代理并启用 awslogs 日志驱动程序即可。

CloudWatch 事件 – 当任务或容器实例的状态更改时,ECS 会生成 CloudWatch 事件。这些事件允许您使用 Lambda 函数监控群集的状态。要了解如何捕获事件并将其存储在 Elasticsearch 群集中,请阅读使用 Amazon ECS 事件流监控群集状态

任务放置策略 – 此次发布使您能够精细控制群集中容器实例上的任务放置。它允许您构建包括群集约束、自定义约束 (位置、实例类型、AMI 和属性)、放置策略 (分散或装填) 的策略,并在无需编写任何代码的情况下使用它们。请阅读 Amazon ECS 任务放置策略简介,了解如何做到这一点!

EC2 Container Service 实际运用

我们的许多客户都使用 Amazon ECS 在生产环境中运行他们的微服务应用程序,这些客户既包括大型企业,也包括炙手可热的初创公司,并且身处各行各业,例如金融服务、酒店和消费电子等行业。Capital One、Expedia、Okta、Riot Games 和 Viacom 等公司都依靠 Amazon ECS。

Mapbox 是用于设计和发布自定义地图的平台。该公司使用 ECS 为整个批处理架构提供技术支持,以收集和处理他们用来为其地图提供支持的每天超过 1 亿英里的传感器数据。他们还使用竞价型实例在 ECS 上优化其批处理架构。Mapbox 平台为 5,000 多个应用程序提供支持,每个月覆盖超过 2 亿的用户。它的后端运行在 ECS 上,这使它每天能够处理超过 13 亿个请求。要了解有关他们最近迁移到 ECS 的事宜的更多信息,请阅读他们最近的博客文章,我们已切换到 Amazon ECS,接下来发生的事情让人难以置信旅游公司 Expedia 使用微服务架构设计了他们的后端。随着 Docker 的普及,他们决定采用 Docker 来实现更快的部署和环境可移植性。他们选择使用 ECS 来安排其所有容器,因为它与 AWS 平台完美集成,从 ALB 到 IAM 角色再到 VPC 集成,一应俱全。这使得 ECS 能够非常容易地与他们现有的 AWS 基础设施配合使用。ECS 确实减少了部署和运行容器化应用程序的繁重工作。Expedia 在 ECS 中的 AWS 上运行 75% 的应用程序,这使它每小时能够处理 40 亿个请求。请阅读 Kuldeep Chowhan 的博客文章,Expedia 如何使用 Amazon ECS 在生产环境中运行数以百计的应用程序,以了解更多信息。

Realtor.com 为购房者和卖房者提供当前待售物业的综合数据库。通过迁移到 AWS 和 ECS,他们的业务得以迅速增长,现在每个月的唯一用户数高达 5000 万个,高峰时段每秒可处理 25 万个请求。ECS 帮助他们更快地部署代码,同时提高其云基础设施的利用率。请阅读 Realtor.com 案例研究,以了解有关他们如何使用 ECS、Kinesis 和其他 AWS 服务的更多信息。

Instacart 介绍了他们如何使用 ECS 来为他们的当日杂货配送服务提供支持:Capital One 介绍了他们如何使用 ECS 实现其运营和基础设施管理自动化:Code

Clever 开发人员使用 ECS 作为他们自己工作的基础。例如:

Rack 是一个开源 PaaS (平台即服务)。它专注于基础设施自动化,在隔离的 VPC 中运行,并使用单租户构建服务来实现安全性。

Empire 也是一个开源 PaaS。它提供一个类似 Heroku 的工作流程,针对的是中小型初创公司,重点是微服务。

Cloud Container Cluster Visualizer (c3vis) 有助于直观地显示 ECS 群集中的资源利用率:

请保持关注

ECS 还有许多新功能正在准备阶段,敬请保持关注!

-Jeff

(原文链接:/cn/https://aws.amazon.com/blogs/aws/amazon-ec2-container-service-launch-recap-customer-stories-and-code/

深入Serverless—让Lambda 和 API Gateway支持二进制数据

1.概述

Serverless即无服务器架构正在迅速举起,AWS Lambda 和AWS API Gateway作为Serverless 架构主要的服务,正受到广泛关注,也有越来越多用户使用它们,享受其带来的便利。传统上来说,Lambda 和API Gateway主要用以实现RESTful接口,其响应输出结果是JSON数据,而实际业务场景还有需要输出二进制数据流的情况,比如输出图片内容。本文以触发式图片处理服务为例,深入挖掘Lambda 和 API Gateway的最新功能,让它们支持二进制数据,展示无服务器架构更全面的服务能力。

先看一个经典架构的案例——响应式主动图片处理服务。

Lambda配合 S3 文件上传事件触发在后台进行图片处理,比如生成缩略图,然后再上传到 S3,这是Lambda用于事件触发的一个经典场景。

http://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html

在实际生产环境中这套架构还有一些局限,比如:

  • 后台运行的图片处理可能无法保证及时完成,用户上传完原图后需要立即查看缩略图时还没有生成。
  • 很多图片都是刚上传后使用频繁,一段时间以后就使用很少了,但是缩略图还不能删,因为也可能有少量使用,比如查看历史订单时。
  • 客户端设备类型繁多,一次性生成所有尺寸的缩略图,会消耗较多Lambda运算时间和 S3存储。
  • 如果增加了新的尺寸类型,旧图片要再生成新的缩略图就比较麻烦了。

我们使用用户触发的架构来实现实时图片处理服务,即当用户请求某个缩略图时实时生成该尺寸的缩略图,然后通过 CloudFront缓存在CDN上。这其实还是事件触发执行Lambda,只是由文件上传的事件主动触发,变成了用户访问的被动触发。但是只有原图存储在S3,任何尺寸的缩图都不生成文件不存储到S3。要实现此架构方案,核心技术点就是让Lambda和API Gateway可以响应输出二进制的图片数据流。

总体架构图如下:

主要技术点:

  • 涉及服务都是AWS完全托管的,自动扩容,无需运维,尤其是 Lambda,按运算时间付费,省去 EC2 部署的繁琐。
  • 原图存在 S3 上,只开放给 Lambda 的读取权限,禁止其它人访问原图,保护原图数据安全。
  • Lambda 实时生成缩略图,尽管Lambda目前还不支持直接输出二进制数据,我们可以设置让它输出base64编码后的文本,并且不再使用JSON结构。配合API Gateway可以把base64编码后的文本再转换回二进制数据,最终就可以实现输出二进制数据流了。
  • 用 API Gateway 实现 图片访问的URL。我们常见的API Gateway用来做RESTful 的API接口,接口的 URL形式通常是 /resource?parameter=value,其实还可以配置成不用GET参数,而把URL中的路径部分作参数映射成后端的参数。
  • 回源 API Gateway,缓存时间可以用户自定义,建议为24小时。直接支持 HTTPS,支持享用AWS全球边缘节点。
  • CloudFront 上还可使用 Route 53 配置域名,支持用户自己的域名。

相比前述的主动生成,被动触发生成有以下便利或优势:

  • 缩略图都不存储在S3上,节省存储空间和成本。
  • 方便给旧图增加新尺寸的缩略图。

2.部署与配置

本例中使用的 Region 是Oregon(us-west-2),有关文件从以下链接下载:

https://s3.amazonaws.com/snowpeak-share/lambda/awslogo.png

2.1 使用IAM设置权限

打开控制台:

https://console.aws.amazon.com/iam/home?region=us-west-2

创建一个 Policy,名叫CloudWatchLogsWrite,用于确保Lambda运行的日志可以写到 CloudWatch Logs。内容是

{
"Version":
"2012-10-17",
"Statement": [
{
"Effect":
"Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}

 

创建 一个Role,名叫 LambdaReadS3,用于Lambda访问S3。Attach Poilcy选AmazonS3ReadOnlyAccess 和刚刚创建的CloudWatchLogsWrite。

记下它的ARN,比如arn:aws:iam::111122223333:role/LambdaReadS3

2.2 使用S3 配置原图存储

打开控制台

https://console.aws.amazon.com/s3/home?region=us-west-2

创建 Bucket,Bucket Name需要填写全局唯一的,比如 img201703,Region 选 US Standard。通常图片的原图禁止直接访问,这里我们设置权限,仅允许 Lambda 访问。

Permissions 下点 Add bucket policy,使用AWS Policy Generator :

Select Type of Policy 选 S3 bucket policy,

Principal 填写前述创建的LambdaReadS3 的 ARN arn:aws:iam::111122223333:role/LambdaReadS3

Actions 下拉选中 GetObjext,

Amazon Resource Name (ARN) 填写刚刚创建的bucket 的ARN,比如arn:aws:s3:::image201703/*

然后点Add Statement,最后再点 Generate Policy,生成类似

{
"Id": "Policy1411122223333",
"Version":
"2012-10-17",
"Statement": [
{
"Sid": "Stmt1411122223333",
"Action": [
"s3:GetObject"
],
"Effect":
"Allow",
"Resource":
"arn:aws:s3:::img201703/*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/LambdaReadS3"
]
}
}
]
}

复制粘贴到Bucket Policy Editor里 save即可。

验证S3 bucket配置效果。把前下载图片文件awslogo.png 下载到自己电脑,然后把它上传到这个 bucket里,测试一下。直接访问链接不能下载,需要右键菜单点“Download”才能下载,说明权限配置已经成功。

2.3 创建Lambda函数

AWS Lambda 管理控制台:

https://us-west-2.console.aws.amazon.com/lambda/home?region=us-west-2#/

点击Create a Lambda function 按钮

Select runtime 菜单选Node.js 4.3,然后点Blank Function。

Configure triggers页,点Next。

Configure function 页,在 Name 栏输入ImageMagick,Description 栏输入

Uses ImageMagick to perform simple image processing operations, such as resizing.

 

Lambda function code 里填写以下代码:

'use strict';

var AWS = require('aws-sdk');
const im = require('imagemagick');
const fs = require('fs');

const defaultFilePath = 'awslogo_w300.png';
// 样式名配置,把宽高尺寸组合定义成样式名。
const config = {
'w500':{'width':500,
'height':300},
'w300':{'width':300,
'height':150},
'w50':{'width':50,
'height':40}
};
// 默认样式名
const defaultStyle = 'w50';
// 完成处理后把临时文件删除的方法。
const postProcessResource = (resource, fn) => {
let ret = null;
if (resource) {
if (fn) {
ret = fn(resource);
}
try {

fs.unlinkSync(resource);
} catch (err) {
// Ignore
}
}
return ret;
};
// 生成缩略图的主方法
const resize = (filePathResize, style, data, callback) => {
// Lambda 本地写文件,必须是 /tmp/ 下
var filePathResize =
'/tmp/'+filePathResize;
// 直接用 Buffer 操作图片转换,源文件不写到本地磁盘,但是转换成的文件要写盘,所以最后再用 postProcessResource 把临时文件删了。
var resizeReq = {
srcData: data.Body,
dstPath: filePathResize,
width: style.width,
height: style.height
};
try {
im.resize(resizeReq,
(err) => {
if (err) {
throw err;
} else {

console.log('Resize ok: '+ filePathResize);
// 注意这里不使用JSON结构,直接输出图片内容数据,并且要进行base64转码。
callback(null,
postProcessResource(filePathResize, (file) => new
Buffer(fs.readFileSync(file)).toString('base64')));
}
});
} catch (err) {
console.log('Resize
operation failed:', err);
callback(err);
}
};

exports.handler = (event, context, callback) => {
var s3 = new AWS.S3();
//改成刚刚创建的 bucket 名字,如 img201703
var bucketName = 'image201702';
// 从文件 URI 中截取出 S3 上的 key 和尺寸信息。
// 稳妥起见,尺寸信息应该规定成样式名字,而不是直接把宽高参数化,因为后者会被人滥用。
// 使用样式还有个好处,样式名字如果写错,可以有个默认的样式。
var filepath = (undefined ===
event.filepath ? defaultFilePath:event.filepath);
var tmp =
filepath.split('.');
var fileExt = tmp[1];
tmp = tmp[0].split('_');
var fileName = tmp[0];
var style = tmp.pop();
console.log(style);
var validStyle = false;
for (var i in config)
{
if (style == i)
{
validStyle = true;
break;
}
}
style = validStyle ? style :
defaultStyle;
console.log(style);
var fileKey =
fileName+'.'+fileExt;
var params = {Bucket:
bucketName, Key: fileKey};

// 从 S3 下载文件,成功后再回调缩图
s3.getObject(params,
function(err, data) {
if (err)
{
console.log(err,
err.stack);
}
else
{
resize(filepath,
config[style], data, callback);
}
});
};

注意一定要把

var bucketName = ‘image201702’;

改成刚刚创建的 bucket 名字,如

var bucketName = ‘img201703’;

这个 Lambda 函数就可以运行了。

Lambda function handler and role 部分的Role 选择 Choose an existing role,然后Existing role 选择之前创建的LambdaReadS3。

Advanced settings:Memory (MB)* 选 512,Timeout 选30 sec。

其它保持默认,点 Next;最后一页确认一下,点Create Function。

提示创建成功。

点击 Test 按钮,测试一下。第一次测试时,会弹出测试使用的参数值,这些参数其实我们都不用,也不用管它,点击 Save and test 按钮测试即可。以后再测试就不会弹出了。

显示“Execution result: succeeded”表示测试成功了,右边的 Logs 链接可以点击,前往 CloudWatch Logs,查看详细日志。右下方的Log output是当前测试执行的输出。

可以看到这里 Execution result 下面显示的结果是一个长字符串,已经不是我们以往普通Lambda函数返回的JSON结构了。想做进一步验证的,可以把这个长字符串 base64 解码,会看到一个尺寸变小的图片,那样可以进一步验证我们运行成功。

2.4 配置API Gateway

管理控制台

https://us-west-2.console.aws.amazon.com/apigateway/home?region=us-west-2#

2.4.1 配置API

点击 Create API

API name 填写ImageMagick。
Description 填写Endpoint for Lambda using ImageMagick to perform simple image processing operations, such as resizing.

这时左侧导航链接会显示成 APIs > ImageMagick > Resources。点击 Actions 下拉菜单,选择Create Resource。

Resource Name* 填写filepath

Resource Path* 填写 {filepath},注意要包括大括号。然后点击Create Resource按钮。

这时刚刚创建的{filepath}应该是选中状态,再点击Actions 下拉菜单,选择Create Method,在当时出现的方法菜单里选择GET,然后点后面的对号符确定。

然后在/{filepath} – GET – Setup 页,Integration type 保持Lambda Function 不变,Lambda Region 选 us-west-2,在Lambda Function 格输入ImageMagick,下拉的备选菜单中点中ImageMagick,点击 Save。弹出赋权限提示,点击“OK”。

这时会显示出完整的“/{filepath} – GET – Method Execution”配置页。

点击右上角“Integration Request”链接,进入配置页,点击“Body Mapping Templates”左边的三角形展开之。

Request body passthrough 选择When there are no templates defined (recommended)。

点击最下面“add mapping template”链接,“Content-Type”格,注意即使这里已经有提示文字application/json,还是要自己输入application/json,然后点击右边的对勾链接,下面会弹出模板编辑输入框,输入

{“filepath”: “$input.params(‘filepath’)”}

完成的效果如下图所示:

最后点击“Save”按钮。点击左上角 “Method Execution”链接返回。

点击左下角“Method Response”链接,HTTP Status 下点击第一行200左边的三角形展开之,“Response Headers for 200” 下点击add header链接,Name格输入Content-Type,点击右边的对勾链接保存。Response Body for 200 下已有一行application/json,点击其右边的笔图标编辑,把值改成image/png,点击右边的对勾链接保存。点击左上角 “Method Execution”链接返回。

点击右下角“Integration Response”链接,点击第一行 “- 200 Yes”左边的三角形展开之,“Content handling”选择 Convert to binary(if needed),然后点击“Save”按钮。这项配置是把Lambda返回的base64编码的图片数据转换成二进制的图片数据,是此架构的另一个技术重点。

Header Mappings 下已有一行Content-Type,点击其右边的笔图标编辑,在“Mapping value”格输入’image/png’,注意要带上单引号,点击右边的对勾链接保存。

点击“Body Mapping Templates”左边三角形展开之,点击“application/json”右边的减号符,把它删除掉。点击左上角 “Method Execution”链接返回。

点击最左边的竖条Test链接,来到“/{filepath} – GET – Method Test”页,“{filepath}”格输入awslogo_w300.png,点击 Test 按钮。右侧显示类似下面的结果

Request: /awslogo_w300.png

Status: 200

Latency: 247 ms

Response Body是乱码是正常的,因为我们的返回内容就是图片文件本身。可以查看右下角Logs 部分显示的详细执行情况,显示类似以下的日志表示执行成功。

Thu Mar 09 03:40:11 UTC 2017 : Method response body
after transformations: [Binary Data]

Thu Mar 09 03:40:11 UTC 2017 : Method response
headers: {X-Amzn-Trace-Id=Root=1-12345678-1234567890abcdefghijlkln,
Content-Type=image/png}

Thu Mar 09 03:40:11 UTC 2017 : Successfully completed
execution

Thu Mar 09 03:40:11 UTC 2017 : Method completed with
status: 200

2.4.2 部署API

点击Actions按钮,在下拉菜单中点选Deploy API,Deployment stage 选择[New Stage],Stage name 输入 test,注意这里都是小写。

Stage description 输入 test stage

Deployment description 输入 initial deploy to test.

点击Deploy按钮。然后会跳转到Test Stage Editor 页。

复制Invoke URL: 后面的链接,比如

https://1234567890.execute-api.us-west-2.amazonaws.com/test

然后在后面接上awslogo_w300.png,组成形如以下的链接

https://1234567890.execute-api.us-west-2.amazonaws.com/test/awslogo_w300.png

输入浏览器地址栏里访问,可以得到一张图片,表示 API Gateway已经配置成功。

2.5 配置CloudFront分发

我们在API Gateway前再加上CloudFront,通过 CDN 缓存生成好的图片,就可以实现不需要把缩略图额外存储,而又不用每次都为了图片处理进行计算。这里使用了CDN和其它使用CDN的思路一样,如果更新图片,不建议调用清除CloudFront的API,而是从应用程序生成新的图片标识字符串,从而生成新的URL让CloudFront成为无缓存状态从而回源重新计算。

由于API Gateway仅支持HTTPS访问,而CloudFront同时支持HTTP和HTTPS,所以我们可以配置成CloudFront前端同时支持HTTP和HTTPS,但是实测发现CloudFront前端使用HTTP而回源使用HTTPS时性能不如前端和回源同为HTTPS。所以这里我们也采用同时HTTPS的方式。

我们打开CloudFront的管理控制台

https://console.aws.amazon.com/cloudfront/home?region=us-west-2#

点击Create Distribution按钮,在 Web 下点击Get Started。

Origin Domain Name,输入上述部署出来的 API Gateway 的域名,比如 1234567890.execute-api.us-west-2.amazonaws.com

Origin Path,输入上述 API Gateway 的 Stage 名,如 /test

Origin Protocol Policy 选择HTTPS Only

Object Caching 点选Customize,然后Maximum TTL输入86400

Alternate Domain Names (CNAMEs) 栏本例使用自己的域名,比如img.myexample.com。SSL Certificate选择Custom SSL Certificate (example.com),并从下面的证书菜单中选择一个已经通过 ACM 管理的证书。

注意,如果填写了自己的域名,那么下面的SSL Certificate就不建议使用默认的Default CloudFront Certificate (*.cloudfront.net),因为很多浏览器和客户端会发现证书的域名和图片 CDN 的域名不一致会报警告。

其它项保持默认,点击Create Distribution按钮,然后回到CloudFront Distributions列表,这里刚刚创建的记录Status会显示为 In Progress,我们点击ID的链接,前进到详情页,可以看到Domain Name 显示一个CloudFront分发的URL,比如cloudfronttest.cloudfront.net。大约 10 多分钟后,等待Distribution Status 变成Deployed,我们可以用上述域名来测试一下。注意测试用的URL不要包含API Gateway 的 Stage 名,比如

https://1234567890.execute-api.us-west-2.amazonaws.com/test/awslogo_w300.png

那么 CloudFront 的URL 应该是

https://cloudfronttest.cloudfront.net/awslogo_w300.png

尽管我们已经配置了自己的域名,但是这时自已的域名还未生效。我们还需要到Route 53 去添加域名解析。

2.6  Route 53

最后我们使用Route 53 实现自定义域名关联CloudFront分发。访问 Route 53 管制台

https://console.aws.amazon.com/route53/home?region=us-west-2

在Hosted Zone 下点击一个域名,在域名列表页,点击上方Create Record Set 按钮,页面右侧会弹出创建记录集的面板。

Name 栏输入 img。

Type 保持默认 A – IP4 Address不变。

Alias 点选 Yes,在Alias Target输入前述创建的CloudFront分发的URL cloudfronttest.cloudfront.net。

点击右下角Create按钮完成创建。

3. 效果验证     

现在我们回到CloudFront控制台,等到我们的Distribution 的Status变成Deployed,先用CloudFront自身的域名访问一下。

https://cloudfronttest.cloudfront.net/awslogo_w300.png

顺利的话,会看到咱们的范例图片。再以自定义域名访问一下。

http://img.myexample.com/awslogo_w300.png

还是输出这张图片,那么到此就全部部署成功了。现在可以在S3的bucket里上传更多其它图片,比如 abc.png,然后访问时使用的URL就是

http://img.myexample.com/abc_w300.png

用浏览器打开调试工具,可以看到响应头里已经有

X-Cache: Hit from cloudfront

表示已经经过CloudFront缓存。

4. 监控

这个架构方案使用的服务都可以通过CloudTrail记录管理行为,使用CloudWatch记录用户访问情况。

4.1 Lambda 监控

在Lambda控制台点击我们的ImageMagick 函数,然后点击选项卡最末一个Monitoring,可以看到常用指标的简易图表。

点击任何一个图表,都可以前进到CloudWatch相关指标的指标详细页。然后我们还可以为各个指标配置相关的CloudWatch Alarm,用以监控和报警。

点击View logs in CloudWatch链接,可以前往CloudWatch Log,这里记录了这个Lambda函数每次执行的详细信息,包括我们的函数中自已输出的调试信息,方便我们排查问题。

4.2 API Gateway 监控

在API Gateway控制台找到我们的API ImageMagick,点击它下面的 Dashboard。

如果部署了多个Stage,注意左上角 Stage 菜单要选择相应的Stage。同样下面展示的是常用图表,点击每个图表也可以前往CloudWatch显示指标监控详情。

4.3 CloudFront日志

我们刚刚配置CloudFront时没有启用日志。如果需要日志,可以来到CloudFront控制台,点击我们刚刚创建的分发,在General选项页点击Edit按钮。在Edit Distribution 页找到Logging项,选择On,然后再填写Bucket for Logs和Log Prefix,这样CloudFront的访问日志就会以文件形式存储在相应的S3的bucket 里了。

5. 小结

我们这样一个例子使用了Lambda和API Gateway的一些高级功能,并串联了一系列AWS全托管的服务,演示了一个无服务器架构的典型场景。虽然实现的功能比较简单,但是 Lambda函数可以继续扩展,提供更丰富功能,比如截图、增加水印、定制文本等,几乎满足任何的业务需求。相比传统的的计算能力部署,不论是用EC2还是ECS容器,都要自己管理扩容,而使用 Lambda无需管理扩容,只管运行代码。能够让我们从繁琐的重复工作中解脱,而把业务集中到业务开发上,这正是无服务器架构的真正理念和优势。

作者介绍:

薛峰

AWS解决方案架构师,AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍

相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC(Infrastructure as Code)自动化运维的一项重要服务,可以帮助用户对 AWS资源进行建模和设置,以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项:Mappings段和Parameters段,可以帮助用户组织模板里的参数和映射,让用户更好地自定义堆栈,以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID,或者管理企业内部的不同部门。

但是当用户所在的组织越来越多地采用IAC自动化时,mappings和parameters的数量也会急剧增长,给CloudFormation模板的编写和维护带来复杂度。

解决方案

本文里我们介绍一种方法:用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。

本文中主要用到了以下几种 AWS服务:

1、DynamoDB表:Amazon DynamoDB是一个NoSQL数据库,这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放,而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中,整个企业采用这样一张表:partition key包括组名(比如说team1、team2等)和环境(比如说development、test、production等),sort key保存应用的名字。这个表里的数据类似这样:

当我们把这些数据都insert到DynamoDB中后,可以在AWS console里看到表中的内容是这样的:

2、Lambda方法:AWS Lambda又称为Serverless的计算,通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联,它从CloudFormation模板接收primary key和sort key作为输入,查找DynamoDB表,并且返回所有的key-value数据。

3、Custom lookup resource:这是CloudFormation里的一个自定义资源,与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源,还支持几种自定义资源,包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时,CloudFormation自动地向Lambda API发起请求,引发方法并将请求的数据传给Lambda方法,本例中所请求的数据是primary key,返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource,所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource:

让我们将这几种服务组合起来,并且定义好它们之间的交互顺序,整个解决方案就是下图展示的这样:

那么整个的交互顺序如下:

1、用户创建DynamoDB表,插入所需的mappings和parameters数据。

2、CloudFormation模板中的custom resource调用Lambda方法,用组名和环境名称(“teamname-environment”)作为partition key,用应用名称(”appname”)作为sort key。

3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。

4、DyanamoDB将结果返回给Lambda方法。

5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。

6、custom resource拿到数据后,堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。

结论

通过这种方式,可以将我们创建堆栈所需的固定部分保存在模板中,而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中,用Lambda实现两者之间的关联。对于大型组织来说,这样可以提高运维效率,也是使用CloudFormation的一种最佳实践。

参考

可以在我们的网站上下载到相关的sample code:https://github.com/awslabs/custom-lookup-lambda

关于AWS Lambda的更多内容请参考网站:https://aws.amazon.com/lambda/

关于CloudFormation自定义资源的更多内容请参考网站:http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

作者介绍

张芸

AWS云架构咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,为企业客户和合作伙伴提供迈向云端的专业服务。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移、应用优化、架构设计等咨询设计和实施服务。在加入AWS之前有近10年的云计算和大数据开源技术研究和开发经验,拥有多项美国和中国专利及专利申请,涉及云计算及服务,分布式系统,软件定义数据中心和自动化运维等领域,合作编著图书《大数据–战略·技术·实践》。

 

使用AWS Application Load Balancer实现基于主机名的路由分发

负载均衡器在应用架构设计中是重要的组件,负责接收来自客户端的流量,将流量按一定的算法转发给后端的一组实例,并将后端实例的响应再返回给客户端。AWS提供一款托管的负载均衡服务, Elastic Load Balancer(简称ELB),ELB除了能够做负载均衡分发流量之外,还能对后端的实例健康检查,并将流量仅转发给通过健康检查的实例,同时ELB还能与自动扩展组(Auto Scaling Group)以及监控服务(CloudWatch)配合,设置根据后端实例CPU使用率的高低,流量大小,处理时间长短等指标,自动完成添加或缩减实例数量。

ELB又分两种,Classic ELB和Application Load Balancer(简称ALB),ELB的一个重要组件是侦听器,前者支持4层和7层的协议和端口(TCP,SSL,HTTP,HTTPS),对后端实例按轮询(TCP协议)或者最少未完成请求数(HTTP协议)的算法对后端实例进行流量转发。

ALB是应用层负载均衡器,支持HTTP/HTTPS的协议,与Classic ELB不同的是,ALB支持基于请求路径的分发,即根据HTTP标头的请求URL路径的不同,分发给后端不同的目标组(Target Group)。目标组是一个或多个目标(这里的“目标”可以是EC2实例)的集合,通常一组目标运行相同的应用或服务,一个目标可以注册到一个或多个目标组中。在目标组中可以配置运行状况检查,实例监控,等待连接耗尽及粘性会话等等。ALB中的规则决定了如何将流量路由到后端不同的目标组,每条规则对应一个目标组、条件及优先级,一旦匹配规则,则执行相应的流量路由,比如将请求URL中路径是/api的请求路由给运行api服务的目标组,将请求URL中路径是/mobile的访问路由给mobile的目标组。

两者的转发模型可见下图。

过去ALB仅支持基于请求路径的流量分发,客户为了实现基于主机名的分发往往使用多组Classic ELB或Classic ELB + Nginx集群的方式,现在ALB提供了新功能,即可以基于主机名进行路由分发,详情请参考:

https://aws.amazon.com/cn/elasticloadbalancing/applicationloadbalancer/

接下来,我们将详细介绍如何使用ALB完成基于主机名的流量分发。

本例中我们将创建以下资源:

(1)1个ALB;

(2)5个目标组,分别为api-prod,api-sandbox,mobile-prod,mobile-sandbox,default;

(3)每个目标组注册不同的EC2实例,其中api-prod目标组将注册两个EC2实例;

(4)一个侦听器;

(5)创建基于主机名和路径的分发规则,实现流量的分发。

1、创建目标组

2、输入目标组名称,选择协议(HTTP/HTTPS)及端口,ALB所在的VPC,配置运行状况检查(协议,路径,阈值等)。此处我们选择了默认HTTP,路径/。

3、注册实例

目标组的重要实体是目标(比如说EC2实例),在此将实例注册到目标组下面,注意选中实例后点击”添加到已注册”,然后保存。此处我们选中了该目标组对应的实例ALBDemo_api_prod,ALBDemo_api_prod_2两个实例。您可以向一个或多个目标组注册多个目标实例以便满足需求。只要注册过程完成且新注册的目标实例通过初始运行状况检查,负载均衡器就会开始将请求路由至此目标。同样,您也可以从目标组取消目标注册。

同理创建api-sandbox,mobile-prod,mobile-sandbox,default目标组,此处省略创建过程。

创建完成后,选中目标组,在目标页我们可以看见注册到该目标组的实例的状态,healthy表示实例正常,另外该状态还有unhealthy(实例未通过健康检查),initial(实例注册中),unused(无流量传入,该目标组未注册到ALB)等。

4、创建负载均衡器

下面我们来创建ALB

5、选择ELB类型

这里我们选择应用程序负载均衡器ALB

6、配置负载均衡器

输入ALB名称,模式可选择该ALB面向Internet或是内部使用;配置侦听器协议,端口,根据需要可以配置多个侦听器,此处我们选择HTTP/80;同时选择ALB部署在哪个可用区及子网,建议多可用区方式部署,同样将应用部署在多可用区,达到高可用的设计目标。

7、配置安全设置

如果侦听器配置了HTTPS,需要配置证书。使用HTTPS,ELB可以完成与客户端的SSL安全连接的建立与SSL卸载,减轻后端服务器的压力。

如果从ACM(AWS Certificate Manager)申请过证书,则可以直接选择该证书,也可以自己上传证书到IAM或者在此上传证书。由于此次我们仅配置了HTTP 80端口侦听器,此处将不配置证书。配置安全证书的截图如下:

8、配置安全组

安全组的概念及用法此处不做复述,我们可以为ALB配置安全组,仅允许指定的协议、端口及来源的流量进入ALB

9、配置路由

这里可以选择”现有目标组”,选择我们前面的创建的default目标组。此处只能选择一个目标组,我们可以在创建完成后,对此ALB添加编辑规则的时候对应路由规则添加目标组。

10、注册目标

11、审核

创建完成后,可以在负载均衡器的控制台看到该ALB的相关描述与信息。

12、配置规则

选中该ALB,在页面下方的侦听器下按端口选择“查看/编辑规则”。

13、添加/编辑规则

与之前不同的是,现在ALB提供了一个规则编辑器。进入规则编辑器后,我们看到的是一条默认规则,并看到目标组是我们前面创建过程中选择的default组。点击左上方”+”,可以添加规则。

目前路由规则支持三种方式:

a.基于URL路径;

b.基于主机名(New Feature);

c.基于主机名+路径(New Feature);

点击&,可以实现基于主机名+路径的规则;

添加了4条规则,将不同主机及路径的流量分发到不同的目标组,如下:

规则 规则(if) 目标组(then)
1 路径/sandbox/* &主机名为api.shishuai.tech api-sandbox
2 主机名为api.shishuai.tech api-prod
3 路径/sandbox/* &主机名为mobile.shishuai.tech mobile-sandbox
4 主机名为mobile.shishuai.tech mobile-prod

通过左上角的添加、编辑、排序、删除可以对规则进行相应的修改与排序,需要注意的是,流量路由匹配规则的时候按规则的顺序匹配,并按最先匹配到的规则执行相应的路由。最多可以添加75条规则。每条规则在主机名处支持最多3个通配符(”*”或者”?”)。

最后规则配置完成,我们检查下规则是否生效。使用Route53 DNS解析服务,将相应的域名(本例中为api.shishuai.tech和mobile.shishuai.tech)CNAME到该ALB的域名(本例中为ALBDemo-2043343612.us-west-2.elb.amazonaws.com,可在选中该ALB,在描述页中看到该DNS地址)。

本例中每个EC2有一个简单的页面,表明自己主机名,以及instance-id,以此区分是否按规则路由到相应的EC2。

http://api.shishuai.tech

在api-prod目标组,我们注册了两台机器,刷新几次会出现另一台EC2的页面。

http://api.shishuai.tech/sandbox/

http://mobile.shishuai.tech

http://mobile.shishuai.tech/sandbox/

综上所述,使用应用负载均衡器基于主机名/路径的流量分发特性,客户可以仅用一组应用负载均衡器就可实现将流量路由给多个后端服务,这可以大大简化客户的架构、减轻运维负担以及优化成本。

作者介绍

王世帅

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内教育、医疗行业的应用和推广。在加入AWS之前曾在国航担任系统工程师,负责存储方案的架构设计,在企业私有云方面有丰富经验。

 

在Virtual Private Cloud中自建基于BIND的DNS服务器

Amazon Virtual Private Cloud (Amazon VPC) 是 AWS 提供的虚拟私有网络服务,允许您在 AWS 云中预配置出一个采用逻辑隔离的部分,让您在自己定义的虚拟网络中启动 AWS 资源。您可以完全掌控您的虚拟联网环境,包括选择自有的 IP 地址范围、创建子网,以及配置路由表和网关。

除了提供IP资源及网络连接,Amazon VPC还提供DNS及DHCP等基础设施服务。当您将实例启动到默认 VPC 中时,我们为实例提供与其公有 IPv4 和私有 IPv4 地址对应的公有和私有 DNS 主机名。当您在非默认 VPC 中启动实例时,我们会为实例提供私有 DNS 主机名,并根据您为 VPC 和实例指定的设置来决定是否提供公有 DNS 主机名。

对于 us-east-1 区域,公有 (外部) DNS 主机名采用 ec2-<public-ipv4-address>.compute-1.amazonaws.com 形式,对于其他区域,则采用 ec2-<public-ipv4-address>.region.amazonaws.com 形式。例如,公有IP为54.222.212.110的EC2实例,其公有DNS名为ec2-54-222-212-110.cn-north-1.compute.amazonaws.com.cn。我们将公有 DNS 主机名解析为该实例在所在网络外的公有 IPv4 地址及其在所在网络内的私有 IPv4 地址。

私有 (内部) DNS 主机名解析为实例的私有 IPv4 地址,并对 us-east-1 区域采用 ip-<private-ipv4-address>.ec2.internal 形式,对其他区域采用 ip-<private-ipv4-address>.region.compute.internal 形式 (其中 private.ipv4.address 是反向查找 IP 地址)。例如,私有IP地址为10.206.2.239的EC2实例,其私有DNS名为ip-10-206-2-239.cn-north-1.compute.internal。您可以使用私有 DNS 主机名在同一网络中实现实例之间的通信,但我们无法解析实例所在网络之外的 DNS 主机名。要解析实例所在网络之外的主机名,可自建DNS服务器来为VPC及外部网络提供DNS服务。

常见的应用场景是在混合IT架构下,客户数据中心通过VPN或是Direct Connect专线连接到AWS上的VPC,在VPC中配置1台DNS服务器,在客户数据中心也配置1台DNS服务器,服务器的主从角色客户可自行定义。通过多台DNS服务器为不同位置的客户端提供DNS服务,即能保证服务的高可用,又能就近提供服务,减少DNS查询延迟。

接下来,我将基于上述架构图一步一步说明如何使用BIND搭建DNS服务器。本文不会涉及BIND的高级配置,如需了解BIND的高级配置,可参考BIND官方网站

安装配置DNS主服务器

首选需要准备一台EC2实例用于安装BIND软件,如何创建EC2实例可参考Amazon EC2入门指南。本次示例选用Amazon Linux操作系统的AMI来创建实例,实例类型选用了通用型实例类型: m4.large。BIND对服务器硬件资源要求不高,在不启用DNSSEC的情况下(不在本文讨论范围),普通配置的服务器即可承载DNS服务。m4.large配置有2颗vCPU和8G内存,运行DNS服务能够支持中等规模的DNS请求,当请求增加时,也可方便的调整实例类型到更大的配置。

创建EC2实例时需要指定安全组来开放服务端口,DNS服务通过UDP 53端口提供DNS查询相应,通过TCP 53端口提供区域传送。因此,安全组队VPC网段开放UDP 53端口,对客户数据中心的DNS服务器开放TCP 53端口,如下图所示:

DNS服务器作为基础设施服务的重要性无须多言,Amazon EC2持续监控EC2实例的状态以及底层硬件的状态,分别称为实例状态检查和系统状态检查。我们可创建状态检查报告,当任一状态检查失败时,执行重启操作,并将警报发送至指定邮箱。

创建好警报之后,通过SSH登陆至EC2实例,并yum命令安装bind软件:

yum install bind-utils bind

安装好之后,我们接下来将创建一个示例的DNS域:aws.local,我们首先需要编辑/etc/named.conf文件,修改以下内容:

listen-on 缺省配置为127.0.0.1,DNS服务只会绑定到系统的环回接口,其他客户端无法访问,需要添加EC2实例的私有IP地址,才能提供外部访问

allow-query缺省配置为localhost,即只允许DNS服务器所在的EC2实例对自己进行DNS查询,添加VPC的网段可允许来自VPC内部的主机进行DNS查询。注:也可将此参数设置为0.0.0.0/0,因为前面安全组设置里只允许了VPC内的IP访问UDP 53端口。

此外,还需要增加对aws.local这个域的定义,在/etc/named.conf中增加以下内容,allow-transfer指定了只允许从DNS服务器进行区域传送,限定允许区域传送的范围颗可提高DNS服务的安全性:

上述配置说明aws.local域的具体解析配置在文件/var/named/aws.local.db 里,其内容如下,在这个示例配置中,定义了两条A记录,分别是dns.aws.local对应10.206.0.212和www.aws.local对应10.206.0.213

配置Amazon VPC使用自建DNS服务器

Amazon VPC通过DHCP服务为VPC中的EC2及其他连网组件动态分配IP地址,动态主机配置协议 (DHCP) 提供了将配置信息传递到 TCP/IP 网络中主机的标准。DHCP 消息中的options字段包含配置参数。这些参数包括域名、域名服务器以及“netbios-node-type”。接下来我们将创建一个新的DHCP选项集,并在选项集中将域名服务器指向刚才创建的DNS服务器。

在AWS控制台中选择VPC服务,并在左边的菜单中选择“DHCP选项集”,点击“创建DHCP选项集”按钮,输入以下信息,域名服务器可指定多个DNS服务器,按照顺序第一个为VPC内的DNS服务器,第二个为客户数据中心的DNS服务器:

创建好DHCP选项集之后选择左边菜单中“您的VPC”选项,选中要修改的VPC,从“操作”下拉菜单中选择“编辑DHCP选项集”

选择刚才创建的DHCP选项集并保存:

在您将新的 DHCP 选项集与 VPC 关联之后,任何现有实例以及您在 VPC 内启动的所有新增实例都将使用这些选项。 无需重新开始或重新启动实例。根据实例更新 DHCP 租赁权的频率,它们会在几个小时内自动拾取更改。如果您愿意,您也可以使用实例上的操作系统,直接更新租赁权。

安装配置DNS从服务器

在客户数据中心安装配置DNS服务器的步骤与在Aamazon EC2中安装配置DNS服务器的步骤相同,除了/etc/named.conf的配置稍有差别:

从服务器的type类型为slave,file参数对应的域配置文件会自动根据从主DNS服务器接收到的更新来进行创建和更新,masters指定aws.local域的主域名服务器,最后一个参数allow-transfer禁用了区域传送。

配置好从DNS服务器之后,可将客户数据中心内的连网设备设置为从DNS服务器,第二DNS服务器设置为AWS上的主DNS服务器。

总结

Amazon VPC提供DHCP服务和DNS服务,为VPC中的EC2实例提供IP地址分配和域名解析服务,为每个EC2实例创建特定格式的DNS域名。如果用户希望使用自定义域名,或者希望使用一套域名统一管理云上和云下的资源,可自行搭建DNS服务器来提供DNS解析服务,Amazon VPC能够支持客户。

作者简介

刘旭东,AWS解决方案架构师 。负责基于AWS的云计算方案的咨询和架构设计,具有超过十年以上企业客户服务经验,同时致力于AWS云服务在国内和全球的应用和推广。在大数据解决方案、企业级解决方案,混合云架构,基础设施运维管理,以及Serverless无服务器架构及IoT等领域有着广泛的设计与实践经验。在加入AWS之前曾任职HPE技术顾问,有超过十年的虚拟化/云计算架构设计经验, 始终推动技术实现商业价值。

AWS 使用 Twitch 进行实时流媒体播放

Twitch 是当今面向开发人员、玩家和艺术家的领先社区流媒体视频平台之一。每天有数百万人在访问 Twitch,通过与其他热情洋溢的在线流媒体参与者一起加入实时研讨会,观看他人的媒体并讨论他们的爱好。Amazon Web Services 也融入到这股潮流中,于去年 11 月份增设了 AWS Twitch 频道,将最新的 AWS 技术带给众多 Twitch 粉丝。AWS Twitch 频道每周都会开展各种实时互动式编程和制作者研讨会,专门面向不同等级的云爱好者。有关即将进行的研讨会系列和以前广播的详细信息,或者希望见到我们的团队,请访问 https://aws.amazon.com/twitch/

AWS Twitch 频道在全年将会有许多节目,每个节目都有不同的主题、主持人和话题。目前,有两个节目可供您收看:使用 AWS 实时编写代码AWS Maker Studio 节目。在使用 AWS 实时编写代码节目中,技术传播者 Randall HuntJulio FaermanAbby Fuller 从开发人员的角度构建几乎涵盖所有 AWS 服务的应用程序和解决方案。作为一名 Twitch 粉丝,您在观看节目时能够利用一项非常好的功能,也就是可以确定播放的位置。此外,来自 Amazon、AWS 和社区的贵宾将加入到我们的 Twitch 主讲人队伍中,讨论如何在 AWS 平台上构建非常棒的新项目和实施。AWS Maker Studio5 月 17 日首次播出节目,并为我们的所有人介绍专门面向制作者的项目和解决方案。主讲人 Todd VarlandTrevor HykesAnupam Mishra 将在第一季的课程中介绍如何构建连接到云的机器人。观看第一集节目可了解前几个步骤,并考虑继续追随并构建自己的机器人。在这个五月会有几个令人兴奋的 Twitch 节目,我们邀请您加入我们,构建机器人,编写代码,并与我们一起制作。本月的日程安排如下:使用 AWS 实时编写代码 5 月 10 日星期三 演讲者:Randall Hunt,太平洋时间下午 2:00 – 使用 Lex 构建聊天机器人 5 月 11 日星期四 演讲者:Julio Faerman,太平洋时间上午 8:00 – 机器学习 5 月 19 日星期五 演讲者:Julio Faerman,太平洋时间上午 8:00 – 云概念回顾   AWS Maker Studio 5 月 17 日星期三 太平洋时间下午 4:30 – 构建您的第一个连接云的机器人 5 月 24 日星期三 太平洋时间下午 4:30 – 让您的第一个机器人感受环境 5 月 31 日星期三 太平洋时间下午 4:30 – 将您的机器人连接到云。如果您对最新的 AWS 技术感兴趣,或者有兴趣与社区中的其他开发人员联系,请每周在 https://twitch.tv/aws 上与 AWS 专家一起进行互动式实时编写代码。另外,如果您错过了某个研讨会,完全不用担心,许多节目提供点播。我们非常希望您加入 Twitch 社区。您只需要访问 TwitchAWS Twitch 频道,即可与其他开发人员、玩家和制作者一起观看我们的节目并开展互动交流,还可以与我们一起在云中构建作品!希望与您在流媒体中相会!

Tara

EC2 内存中处理更新:具有 4 到 16 TB 内存 + SAP HANA 横向扩展到 34 TB 的实例

我每个月都会多次在西雅图的执行简报中心与 AWS 客户畅谈。我会介绍我们的创新过程,并讨论如何根据客户的要求和反馈更好地制定每个 AWS 产品的路线图。一个很好的例子就是,在我们的努力下,AWS 已经成为 SAP 业务解决方案产品组合的理想平台。多年来,我们的客户向我们透露,他们在 AWS 中运行大规模 SAP 生产应用程序,而我们一直努力为他们提供旨在满足其工作负载的 EC2 实例。由于 SAP 安装始终是任务关键型应用产品,因此 SAP 对其产品可以在特定类型和大小的 EC2 实例上使用进行认证。我们直接与 SAP 合作以取得认证,并使 AWS 成为运行其产品的强大可靠的平台。下面快速回顾我们在这个领域的一些最重要的公告:

2012 年 6 月 – 我们扩大了在 AWS 上提供的经过 SAP 认证的解决方案系列。2012 年 10 月 – 我们宣布 SAP HANA 内存中数据库现在可以在 AWS 上开展生产运行。2014 年 3 月 – 我们宣布,SAP HANA 现在可以在具有高达 244 GB 内存的 cr1.8xlarge 实例上开展生产运行,并且能够创建比以往更大的测试集群。2014 年 6 月 – 我们发布了“SAP HANA 部署指南”和一套 [cloudformation] 模板,并且宣布 r3.8xlarge 实例获得 SAP 认证。2015 年 10 月 – 我们宣布推出配备 2 TB 内存的 x1.32xlarge 实例,这些实例旨在运行 SAP HANA、Microsoft SQL Server、Apache Spark 和 Presto。2016 年 8 月 – 我们宣布,X1 实例集群现在可用于创建具备高达 7 个节点或 14 TB 内存的生产 SAP HANA 集群。2016 年 10 月 – 我们宣布推出具有 1 TB 内存的 x1.16xlarge 实例。2017 年 1 月 – 经过认证,SAP HANA 可在 r4.16xlarge 实例上运行。今天,来自各行各业的客户在 AWS 上运行生产 SAP 应用程序 (SAP 和 Amazon Web Services 页上提供了一个非常长的客户成功案例列表)。我的同事 Bas Kamphuis 最近撰写了一篇文章:借助 SAP 和云开启数字化之旅 (要求注册)。他介绍了 SAP 在数字化转型中的作用,并探讨了提供底层支持的云基础设施的关键特征,并且指出了云相比其他托管选项可提供的众多优势。他在文章中阐述了下面这些优点:我们会继续努力,让 AWS 成为运行生产 SAP 应用程序的更好平台。下面是我们正在大力改进的几个方面:

  • 更大的 SAP HANA 集群 – 您现在可以使用高达 17 个节点 (34 TB 内存) 构建横向扩展 SAP HANA 集群。
  • 4 TB 实例 – 即将推出的 x1e.32xlarge 实例将提供 4 TB 内存。
  • 8 到 16 TB 实例 – 最高具有 16 TB 内存的实例正在开发中。

我们来深入探讨一下!构建更大的 SAP HANA 集群 – 我非常高兴地宣布,我们一直在与 SAP 合作进行认证,以便将 x1.32xlarge 实例用于高达 17 个节点 (34 TB 内存) 的横向扩展集群。这是目前在所有云提供商中能够提供的最大横向扩展部署,这让我们的客户能够在 AWS 上部署超大型 SAP 工作负载 (请访问 x1.32xlarge 实例的 SAP HANA 硬件目录认证来了解更多信息)。要了解如何设计和部署自己的横向扩展集群,请参阅 AWS 上的 SAP HANA 快速入门扩展内存密集型 X1 系列 – 我们将继续投资完善这个实体系列和其他实例系列,以满足您的需求并为您提供一个平坦的发展途径。今年晚些时候,我们计划在多个 AWS 区域中提供 x1e.32xlarge 实例,同时推出按需实例和预留实例两种形式。这些实例将提供 4 TB DDR4 内存 (x1.32xlarge 实例的两倍)、128 个 vCPU (4 个 2.3 GHz Intel® Xeon® E7 8880 v3 处理器)、高内存带宽以及大型 L3 缓存。这些实例将是仅 VPC 实例,可以使用 Elastic Network Adapter 提供高达 20 Gbps 的网络带宽,同时最大限度地减少延迟和抖动。默认情况下对这些实例进行了 EBS 优化,可提供高达 14 Gbps 的专用 EBS 吞吐量。下面是来自外壳程序的一些屏幕截图。在第一个截图中, dmesg 显示了引导时的内核消息:

在第二个截图中, lscpu 显示了 vCPU 数和插槽数量,还有许多其他值得关注的信息:

此外, 顶部 显示有接近 900 个进程:

下面是来自 HANA Studio 中的视图:

通过这个新实例以及针对更大集群的认证,扩大了您在 EC2 上运行 SAP 的横向扩展和纵向扩展选项集,从下图中可以看出这一点:

长期内存密集型路线图 – 因为我们知道规划大规模 SAP 安装可能需要相当长的时间,所以我还想与您分享一下我们路线图的一部分。今天,客户能够在第三方托管数据中心运行更大的 SAP HANA 认证服务器,并通过 [dc] 将它们连接到自己拥有的 AWS 基础设施,但客户告诉我们,他们真的希望像现在的 X1 实例一样使用云原生解决方案。为了满足这种需求,我们正在开发具有更多内存的实例!在 2017 年和 2018 年,我们计划推出内存在 8 TB 和 16 TB 之间的 EC2 实例。利用这些即将推出的实例以及 x1e.32xlarge,您可以创建更大的单节点 SAP 安装和多节点 SAP HANA 集群,并运行其他内存密集型应用程序和服务。它还将为您提供一些纵向扩展的余地,当您开始达到较小实例的极限时,这对您会非常有用。我会尽早分享有关我们计划的更多信息。来自 SAPPHIRE 大会上的问候 – AWS 团队将在 SAPPHIRE 的展台 539 上与大家相见;届时我们的团队、客户以及合作伙伴将在展台演讲厅中主持一系列研讨会。我们也将在整个展会期间参加许多研讨会。下面列举了一些研讨会 (有关完整清单,请参阅 SAP SAPPHIRE NOW 2017):AWS 上适用于大型企业和大型工作负载的 SAP 解决方案 – 时间:5 月 17 日星期三中午。主讲人:Bas Kamphuis (AWS 的 SAP 业务部总经理) 和 Ed Alford (BP 业务应用程序服务副总裁)。通过迁移到 AWS 上的 SAP HANA 在速度方面实现质的飞跃 – 时间:5 月 17 日星期三中午 12:30 – 主讲人:Paul Young (SAP 副总裁) 和 Saul Dave (Zappos 企业系统高级主管)。Zappos 主持的 AWS 炉边谈话 (快速 SAP HANA 迁移:真实效果) – 时间:5 月 18 日星期四上午 11:00 – 主讲人:Saul Dave (Zappos 企业系统高级主管) 和 Steve Jones (AWS 的 SAP 解决方案架构高级经理)。[jeffsig] PS – 如果您具有一些 SAP 使用经验,并希望将这些经验带到云中,请考虑下主产品经理 (AWS 快速入门)SAP 架构师职位。