亚马逊AWS官方博客

Category: 计算

新增 – CloudWatch Events 的跨账户传送功能

CloudWatch Events 让您能够跟踪和响应 AWS 资源中的更改。您可以获得几乎实时的事件流,并使用规则将其路由到一个或多个目标 (AWS Lambda 函数、Amazon Kinesis 流、Amazon SNS 主题等)。生成的事件取决于特定的 AWS 服务。例如,以下是为 EC2 实例生成的事件: 或者,对于 S3 (必须启用 CloudTrail 才能创建使用这些事件的规则): 请参见 CloudWatch 事件类型列表,以查看有哪些服务和事件可用。 新的跨账户事件传送客户要求我们扩展 CloudWatch Events,以处理跨多个 AWS 账户的一些有趣且强大的使用案例,我们也很乐意满足这些要求。今天,我们将添加对 CloudWatch Events 的受控、跨账户传送的支持。如您所见,现在您可以安排将事件从一个 AWS 账户路由到另一个账户。与现有的事件传送模式一样,您可以使用 CloudWatch Events 规则来指定要将哪些事件发送到另一个账户。 以下是客户与我们分享的一些使用案例: 隔离问题 – 客户希望在单独的账户中处理和响应事件,以实施高级安全方案。 汇总 – 客户正在使用 AWS Organizations,并希望在整个组织范围内跨多个 AWS 账户跟踪某些类型的事件。 每个 AWS 账户都使用资源事件总线来分发事件。该对象可追溯到 CloudWatch Events 的引入,但从未这样被正式地称呼过。AWS 服务、PutEvents […]

Read More

白皮书:Amazon EC2 Container Service(ECS)上的微服务架构(下篇)

ECS上构建微服务架构 在构建微服务架构时面临的一个主要问题就是,如果减轻运行、维护、扩展和管理微服务架构所需大规模分布式集群资源的工作量和复杂性。目前主流的解决此问题的方案之一就是通过容器化部署和运行服务,降低运维和部署的复杂性。Amazon EC2 Container Service(ECS)是AWS提供的一个容器管理服务,能够应对和解决微服务架构的部署和运维中面临的种种挑战。 本章节首先介绍Amazon ECS及其架构和工作原理,然后介绍利用Amazon ECS及其他相关AWS服务分层构建的一个高可用、高可扩展性、容错的微服务,并讨论该方案中涉及的分布式系统监控、服务发现、异步通信等问题。 Amazon ECS 简介 什么是Amazon ECS Amazon ECS是一个高度可扩展伸缩、高性能容器管理服务,支持Docker容器[vi]并能够让你轻构地在EC2实例构建的集群中运行应用程序。 Amazon ECS能够让你轻松地进行安装、操作和扩展你的集群资源。使用简单的API调用,你就可以启动和停止基于Docker的应用程序、查询你的集群状态、还可以使用其他熟悉的服务,诸如安全组、ELB、EBS卷和AWS IAM角色。 Amazon ECS的特点 与Docker完美兼容:支持 Docker 并使您能够在 Amazon EC2 实例的集群间运行和管理 Docker 容器。Amazon ECS 所管理的集群中的每个 EC2 实例都运行有 Docker 守护程序,所以无论您将何应用程序打包为本地容器,它都将部署和运行在 Amazon ECS 上,无需进行任何配置更改。 内置集群托管:管理自己的容器管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案。这些系统的可用性和可扩展性架构和管理很难。Amazon ECS 消除了容器管理工作的复杂性。使用 Amazon ECS,您只需要启动容器实例集群并指定想要运行的任务即可,所有集群管理工作将由 Amazon ECS 完成。 编程控制:Amazon ECS 为您提供一组简单的 API,方便您集成和扩展服务。使用 API,您可以创建和删除集群、注册和取消注册任务、启动和终止 Docker 容器,并能提供集群及其实例的状态相关详细信息。您还可以使用 AWS CloudFormation[vii] 预置 […]

Read More

白皮书:Amazon EC2 Container Service(ECS) 上的微服务架构(上篇)

简介 微服务是一种软件开发的组织和架构方法,它可以加快软件交付周期、增强创新和自主性,提高软件的可维护性和可伸缩、可扩展性,同时也提高了企业开发和发布软件服务的能力。使用微服务架构,软件产品将由多个独立的、可通过API进行交互的服务组成。这些服务将由各个小团队独自负责。 通过本白皮书,我们将首先总结一下微服务架构的特性,讨论构建微服务架构面临的挑战和难题,然后介绍AWS的ECS容器集群服务,以及如何利用ECS结合其他AWS提供的服务解决微服务架构中遇到的难题。 什么是微服务架构 微服务架构的特性 近些年,微服务架构的概念变得越来越火[i],事实上微服务并非某项具体的技术或框架,它也不是软件工程学中新的概念,而是一些成功的,经过实践论证的概念的组合,比如面向对象方法论、敏捷开发、面向服务架构、API-first设计、以及持续集成。 “微服务”这个名词是一个概括性的术语,很难对其进行精确的定义。但是所有微服务架构方法都具有以下共同特性: 去中心化:微服务架构是由去中心化数据管理的分布式系统组成。它不依赖中心数据库上统一的数据库模式。每一个服务都有自己独立的数据模型。去中心化的另一个含义是,每个服务在开发、部署、管理和维护过程中也是相互独立的,不依赖某个中心系统。 独立:微服务架构中各个服务组件都可以独立进行更改、升级和替换,而不会影响其他服务组件的正常功能。同样,负责各个服务组件的团队之间也都是相互独立的,互不干扰的。 专注做好一件事:每个服务组件都是专注于某个问题域的功能集合,一旦某个服务复杂度到达一定程度,则应该考虑将其进行服务切分或对其进行再次微服务架构。 多语种:微服务并不是“一体通用”的方法,它允许各个团队根据自己的喜好选择最适合自己问题域的开发语言、开发工具。因此,微服务无论在操作系统、开发语言、数据存储还是工具,都是兼容的。也就是说,微服务是“多语种”的。 黑盒子:微服务中的服务都是按照“黑盒”设计的,也就是说,它们将内部逻辑对外隐藏进来,各个服务间通过定义良好的API进行通信,避免了暗含的相互依赖。 谁构建,谁运行:通常情况下,在生产环境中,构建了某个服务的团队负责该服务的运行和维护。这条规则也称之为DevOps[ii]。DevOps除了能让各个团队按照自己的安排独立工作外,还可以让开发人员更贴近软件产品的真正使用者,能帮助他们更好地了解用户的需求。微服务对于企业组织架构上的影响也是不容忽视的,正如康威定律所言,系统架构是公司组织架构的反映[iii]。 图1:微服务架构的特征 单体型架构 vs. SOA vs. 微服务架构 技术为业务而生,架构也为业务而出现,无论传统单体型架构、SOA和微服务都是因为业务的发展而出现。出现SOA以及微服务框架与业务的发展、平台的壮大密不可分。 单体型架构 当网站或者应用流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本,简化开发流程,适合于个人开发或者小团队开发一些功能单一的小产品使用。这是最传统的架构模式,一般整个系统都是有一个统一的数据中心,各个功能模块显式进行相互依赖(比如直接调用模块公开的方法)。当网站流量随着业务发展不断变大时,这种架构的应用在可扩展性、容错性(一旦某个功能模块被流量击溃,整个系统瘫痪)上存在致命性的缺陷。 SOA 当网站或者应用流量变大,单体型架构无法招架之时,可以采取面向服务架构方式,将应用根据系统维度、功能维度、读写维度或者模块维度进行划分成各个独立的服务组件,服务组件间通过某个约定的方式(比如Web Service或者HTTP REST API)进行通信。当服务越来越多,容量的难以准确评估,小服务导致资源浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率,这种架构一般仍然存在一个统一的数据中心或者调度中心。整个系统的可维护性、可扩展性相对于单体型架构得到提高,但在服务细粒度、隔度性、去中心化方面仍与微服务有差,另外就是SOA架构常常依赖于总线结构,利用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦,对于总线结构的依赖也使得服务的独立性并没有被完全剥离。 微服务架构 在微服务架构中,每个服务都要去中心化,不存在单点故障问题。每个服务都要实现高可用、高负载,不会因为一个服务不可用而影响整套业务流。每个服务细粒度,专注于自己的问题域,与别的服务采用更好的Restful或者良好定义的API进行通信。服务都要高度通用化,即多种终端都可调用,不分语言和平台服务部署或升级简单,不会消耗大量人力并且部署过程不易出现人为错误,同时还具有快速注册与自动服务发现功能。 微服务的益处 许多AWS客户选择微服务架构来解决传统单体型架构中存在的敏捷性和可扩展性限制的问题。让我们来看看选择微服务架构能够带来哪些方面的益处吧。 敏捷 使用微服务的组织由多个负责运维独立服务的小团队组成。各个团队都是在界限明确的小范围内独立、快速地工作,从而起到减小迭代时间的效果。各个小团队效率的提升将使整个企业组织工作效率进行很大程序地提高。 图2标示由多个小团队组成的企业组织架构与由一个大团队组成的企业组织架构,在发布部署一个应用时的工作效率区别。 图2:部署微服务 创新 小团队可以独立自主地针对自己负责的问题域选择相关的技术、框架和工具,这就是创新的体现。职责与义务,让团队产生对自己的服务的责任感。 DevOps通过将开发与运维人员结合到一个团队中,让他们能更早地、更好地沟通,解决了开发部署过程中没必要的摩擦和矛盾。当应用程序部署时,敏捷的处理流程可以让开发和运维工作不再需要暂停下来,相反,整个软件交付周期,从提交代码到发布版本,整个流程将变成自动化的。测试一个新的想法,或者当新功能出现问题时及时回滚,将变得更加轻松。因为失败成本的降低,团队将更加乐于更改和创新。 质量 使用微服务架构您的应用程序,将一定程度上提高代码质量。这跟面向对象设计中提出的分模块开发有同样的效果:提高代码的可重用性、封装性和可维护性。 伸缩性 细粒度解耦的微服务架构另一个好处就是,它非常适合构建大规模系统。它允许针对不同的服务选择最适合的技术,这也是性能优化的体现。每个服务都可以使用最合适的开发语言和框架来实现,利用最优的数据持久化解决方案,并通过各自独立的服务配置进行调优。 合理解耦的微服务架构,可以独立地进行水平伸缩扩展。这相对于传统架构中使用的垂直伸缩有很大的优势。垂直伸缩指的是当业务量、流量增大时,升级硬件资源,将应用部署到“更大的机器”上,这会导致“机器硬件资源上限”和伸缩时宕机的问题。水平伸缩,通过将更多的服务部署到服务池(多个机器组成的集群)中,可以动态地适配流量,并且不会陷入单个机器资源上限问题。整个水平伸缩的过程将会是自动化的。另外,应用程序的可靠性将得到增加,因为出现问题的服务可以自动地被健康的服务替换掉,而不影响整个应用的运行。 可用性 微服务架构可以轻松实现故障隔离。通过健康检查、缓存、隔离仓、断路器等技术,可以减小当某个组件出现故障时的影响,从而保证应用的高可用性。 微服务架构面临的挑战 尽管拥有前面提到的那么多优点,但是微服务架构和所有其他架构一样,都不是解决所有问题的“银弹”。使用微服务架构也会面临一些挑战和难题。比如: 微服务架构都是分布式的,也就会存在所有“分布式计算误区”中提到的问题[iv]。 从单体型架构迁移至微服务架构,需要您准确地划分好各个服务间的界限,并且从应用层到数据库层松耦合代码依赖。 除此之外,在组织管理方面还存在着一些挑战,比如如何组建一个高效的团队,如何将团队转变成DevOps的生产模式,如何合理化开发团队与运维团队的沟通等。 本白皮书主要关注的是架构和运维方面遇到的挑战,如果想了解更多关于AWS如何运用DevOps的知识,请访问https://aws.amazon.com/devops[v] 架构复杂度 在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中。而对于微服务架构而言,复杂度变成了各个服务间的交互。 在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授权认证等问题。 运维复杂度 […]

Read More

Amazon EC2 Container Service打造容器化的SaaS应用

概述 在SaaS化应用的改造中,容器技术的应用越来越广泛。相对于传统的虚拟机模式,容器化模式的隔离技术“更轻量”,“ 更快速”,“ 更便捷”. 目前业界越来越广的使用“容器”技术用于应用的微服务化改造,将自己产品的一些服务“微服务”化,构建基于云平台的SaaS化应用。 容器技术改造的难点 1. 技术的复杂性 容器技术应用的难点在于生产环境的实施及部署, 一般需要解决 容器资源编排调度 服务的自动发现及注册 容器的监控及报警 容器的扩展及收缩 这只是解决的部分问题,用户还必须去解决生产环境部署中怎样实现高可用部署及与公有云平台的集成问题。这使得Docker的生产化部署变得困难。 2. Docker编排框架的选型 许多人认为容器技术的价值在编排层,目前在容器的编排框架上主要的流派正在上演 “三国演义”包括,Google Kubernetes、Apache Mesos、Docker  DockerSwarm. Kubernetes,Mesos是目前市场上比较成熟的解决方案,占有较大的市场份额。DockerSwarm的优点是与Docker平台中的许多功能的集成,因为它平滑地内置于Docker平台中。上述三个编排框架都开放源代码,用户只需为技术支持服务付费。除了这些标准外还有许多初创公司也推出了自有的编排框架, 如Rancher使用Java语言开发了Cattle,它是Rancher实现的自有的一套基于Docker的编排引擎。众多的开源或自有的编排框架在不断发展,演进。这给客户的技术平台选型也带来极大的挑战。 Amazon EC2 Container Service(ECS) 为了降低容器平台生产部署的复杂性,Amazon ECS提供了一个平台来管理Docker容器。Amazon ECS是一项高度可扩展的高性能容器管理服务,您将不再需要安装、运维、扩展自己的群集管理基础设施。只需进行简单的 API 调用,您便可以启动和停止支持 Docker 应用程序,查询群集的完整状态,使用各种熟悉的功能,包括安全组、Elastic Load Balancing、EBS 卷和 IAM 角色。您可以使用 Amazon ECS 根据您的资源需求和可用性要求在您的群集中安排容器的置放。您还可以集成自己的或第三方的计划程序,以满足业务或应用程序的特定要求。Amazon EC2 Container Service 没有任何附加费用。您只需为您创建的用于存储和运行应用程序的 AWS 资源 (例如 EC2 实例或 EBS 卷) 付费。Amazon […]

Read More

AWS Lambda 对 AWS X-Ray 的支持

今天,我们宣布全面推出 AWS Lambda 对 AWS X-Ray 的支持。您可能已经从 Jeff 的 GA 文章中了解到,X-Ray 是 AWS 推出的一项服务,用于分析分布式应用程序的执行和性能行为。传统调试方法对于基于微服务的应用程序效果不佳,在这些应用程序中,有多个独立的组件在不同的服务上运行。利用 X-Ray,您可以通过对应用程序中的延迟进行细分,来快速诊断错误、速度下降和超时问题。稍后我将详细介绍如何构建和分析一个基于 Lambda 的简单应用程序,以演示您如何能够在自己的应用程序中使用 X-Ray。如果您想立即开始使用,可以通过导航到现有 Lambda 函数的配置页面并启用跟踪,来轻松地为函数启用 X-Ray: 或者在 AWS 命令行界面 (CLI) 中更新函数的 tracing-config (请务必同时传入 –function-name ): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ 如果激活跟踪模式,Lambda 将尝试跟踪您的函数 (除非上游服务明确说明不跟踪)。如果不激活跟踪模式,仅当上游服务明确说明需要跟踪时,才跟踪您的函数。一旦启用跟踪,您将开始生成跟踪,并将获得应用程序中资源的可视化表示形式以及它们之间的联系 (边缘)。需要注意的一点是,X-Ray 守护进程会占用 Lambda 函数的一些资源。如果您已接近内存限制,Lambda 将尝试终止 X-Ray 守护程序,以免引发内存不足错误。 下面让我们通过快速构建一个使用几种不同服务的应用程序来测试这种新的集成。 作为一个二十多岁且拥有智能手机的年轻人,我有大量 图片 自拍照 (一万多张!),我想如果能够分析所有这些照片,那就太棒了。我们将使用 Java 8 运行时编写一个简单的 […]

Read More

免费试用 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

Read More

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

今天似乎是回顾在过去一年左右的时间里我们添加到 [madison] 的一些功能,以及与您分享一些客户成功案例和代码的大好时机!该服务使您可以轻松地在托管的 EC2 实例群集上运行任意数量的 Docker 容器,并获得完整的控制台、API、CloudFormation、CLI 和 PowerShell 支持。您可以将您的 Linux 和 Windows Docker 镜像存储在 EC2 容器注册表中以方便访问。 发布回顾 我们先来看一些最新的 ECS 功能和一些演示如何使用这些功能的有用的操作方法博客文章: 应用程序负载均衡 – 去年我们添加了对应用程序负载均衡器的支持。这一高性能的负载均衡选项在应用程序级别运行,允许您定义基于内容的路由规则。它支持动态端口,并且可以跨多个服务共享,使您更容易在容器中运行微服务器。要了解更多信息,请阅读有关服务负载均衡的信息。 任务的 IAM 角色 – 您可以通过向 ECS 任务分配 IAM 角色来保护您的基础设施。这允许您基于每个任务精细地授予权限,从而可根据每个任务的需要自定义权限。阅读任务的 IAM 角色,了解更多信息。 服务 Auto Scaling – 您可以定义扩展策略,以根据需求的变化来扩展和缩减您的服务 (任务)。您只需设置所需的最小和最大任务数,并创建一个或多个扩展策略,服务 Auto Scaling 将负责其余的工作。服务 Auto Scaling 的文档可帮助您使用此功能。Blox – 在基于容器的环境中,调度是将任务分配给实例的过程。ECS 为您提供三个选项:自动 (通过内置的服务计划程序)、手动 (通过RunTask 函数) 和自定义 (通过您提供的计划程序)。Blox […]

Read More

深入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 […]

Read More

使用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 […]

Read More

在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 地址,并对 […]

Read More