Amazon Web Services – AWS 上的部署选项 2015 年 3 月

1 / 21

AWS 部署选项概述

Peter Dalbhanjan

2015年 3月

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

2 / 21

© 2015 年，Amazon Web Services 有限公司或其附属公司版权所有。

通告

本文档所提供的信息仅供参考，且仅代表截至本文件发布之日时 AWS 的当前产品与实践情况，若有变更恕不

另行通知。客户有责任利用自身信息独立评估本文档中的内容以及任何对 AWS 产品或服务的使用方式，任何

“原文”内容不作为任何形式的担保、声明、合同承诺、条件或者来自 AWS 及其附属公司或供应商的授权保

证。AWS 面向客户所履行之责任或者保障遵循 AWS 协议内容，本文件与此类责任或保障无关，亦不影响 AWS

与客户之间签订的任何协议内容。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

3 / 21

目录

简介 5

AWS 部署服务 6

AWS Elastic Beanstalk 6

AWS CloudFormation 6

AWS OpsWorks 7

AWS CodeCommit 7

AWS CodePipeline 7

AWS CodeDeploy 7

Amazon EC2 容器服务 7

常见功能 8

设置 10

部署 10

配置 10

规模 10

监控 10

日志记录 10

实例配置 11

自定义变量 11

其它 AWS 服务集成 11

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

4 / 21

标签 11

堆栈更新策略 12

预置 AMI 12

原状对一次性方法 12

蓝-绿方法 14

混合部署模型方法 15

总结 18

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

5 / 21

摘要

Amazon Web Services 提供多种选项，帮助大家配置自己的 IT 基础设施并完成应用程序部署。无论是简单的

三层应用程序还是更为复杂的工作负载集合，其部署方法都会由客户的不同而有所区别。不过利用正确的技术

手段，AWS 能够帮助大家选取最佳策略与工具集合，顺利部署负责处理工作负载的基础设施。

本白皮书的目标在于帮助大家在 AWS 当中找到适合自己的部署服务相关信息。其中包括这些部署服务所提供

的常见功能、阐述了更新应用程序堆栈所需要的策略同时提供多个面向复杂工作负载混合部署模式示例。

简介

AWS 能够迎合各类客户的多种特定要求。如果您已经是 AWS 平台的老用户，那么可能早已意识到不可能存在

能够“以不变应万变”的解决方案。无论您需要的是企业级计算方案，还是希望建立起庞大的社交媒体或者游

戏业务，AWS 都能够提供多种定制化选项，帮助大家实现广泛的用例类型。AWS 平台的设计目标在于解决可

扩展性、性能、安全性、易于部署性以及相关工具，帮助客户随着自身产品与服务的发展完成应用及开发者与

架构师生态系统的迁移。

举例来说，AWS 提供多种选项帮助大家在 Amazon Elastic Compute Cloud（即 Amazon 弹性计算云，简称 EC2）

实例之上推出应用程序，同时提供多种用于添加计算与存储资源的规模伸缩机制。1对于持久性数据存储需求，

Amazon Elastic Block Store（即 Amazon 弹性块存储，简称 EBS）则提供多川分层方案，具体包括通用型（SSD）、

配置 IOPS（SSD）以及磁性 EBS 分卷 2。对于那些天然具备静态属性的数据，大家可以使用 Amazon Simple

Storage Service（即 Amazon 简单存储服务，简称 S3）3与 Amazon Glacier4进行数据归档。对于那些天然具

备关系型特征的数据，大家可以使用 Amazon Relational Database Serivce（即 Amazon 关系型数据库服务，

简称 RDS）5;而在数据仓库方面，大家可以选择 Amazon Redshift6。如果大家需要对存储的吞吐能力进行预配

置，则可使用 Amazon DynamoDB7; 而在实时处理方面，大家可以选择 Amazon Kinesis。8

同样的，在部署服务时，AWS 亦提供多种选项。以下示意图汇总了 AWS 当中的各类不同部署服务。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

6 / 21

图一：部署服务概览

AWS 部署服务

AWS 提供多项策略进行基础设施配置。大家可以利用这些构建单元（包括 Amazon EC2、Amazon EBS、Amazon

S3 以及 Amazon RDS 等）并结合第三方工具部署自己的应用程序。不过要实现更为突出的灵活性，大家可以

考虑利用各项 AWS 部署服务提供的自动化要素。

AWS Elastic Beanstalk

AWS Elastic Beanstalk 能够以最快速且最简单的办法将一款应用程序启动并运行在 AWS 之上。9其非常适合

那些希望部署代码，但却又不想费神管理底层基础设施的开发人员。Elastic Beanstalk 非常适合那些可配合一

套数据库运行在应用服务器之上的标准三层式 PHP、Java、Python、Ruby、Node.js、.NET、Go 或者 Docker

应用程序。10Elastic Beanstalk 利用 Auto Scaling11与 Elastic Load Balancing12以轻松支持高度波动的流量，并

能够根据需求轻松实现规模的自由伸缩。其常见用例包括 Web 应用、内容管理系统（简称 CMS）以及 API

后端。

AWS CloudFormation

AWS CloudFormation 能够为系统管理员、网络架构师以及其他 IT 人员提供充分的灵活性，帮助其利用源自

基础设施架构模型的模板配置并管理 AWS 资源堆栈 13。大家能够利用其管理任意对象，从简单的单一 Amazon

EC2 实例到复杂的多层多服务区应用皆涵盖其内。利用这些模板，大家能够在基础设施之上实现版本控制并轻

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

7 / 21

松以可重复方式复制基础设施堆栈。AWS CloudFormation 非常适合那些希望利用一款工具对自身基础设施进

行细化配置与管理的客户。而 AWS CodeDeploy 则适合作为 AWS CloudFormation 的辅助方案，负责管理应

用程序的部署与更新。14

AWS OpsWorks

AWS OpsWorks 是一项应用程序管理服务，旨在简化开发人员与运维人员部署及运营各类规模应用程序的过

程 15。AWS OpsWorks 非常适合那些希望部署代码、对底层基础设施进行一定程度抽象且应用程序本身的复

杂度高于标准三层架构的用户。AWS OpsWorks 同样适合那些希望利用 Chef 等配置管理系统对基础设施加以

管理的朋友。

AWS CodeCommit

AWS CodeCommit 是一项高可用性、高可扩展性托管源控制服务，其能够托管各类专有 Git 库 16。在 AWS

CodeCommit 的帮助下，大家能够将从代码到二进制数据再到任务的多种资产以无缝化方式存储在现有 Git 类

工具当中。CodeCommit 在结合 AWS CodePipeline 与 AWS CodeDeploy 之后，则可显著简化大家的开发与发

布流程。

AWS CodePipeline

AWS CodePipeline 是一项持续交付与发布自动纪服务，旨在帮助用户快速完成新功能发布。17在 AWS

CodePipeline 的帮助下，大家可以设计自己的开发工作流，从而完成代码检查、代码构建、应用程序分段部署、

测试以及面向生产环境的发布等工作。AWS CodePipeline 还能够被轻松集成或者摭至第三方工具当中，从而

接入发布流程中的任意环境。另外，大家也可以利用 AWS CodePipeline 作为端到端解决方案。为了最大程度

实现其优势，大家可以将 AWS CodeCommit 与 AWS CodePipeline 配合使用，从而简化整个开发与发布周期。

AWS CodeDeploy

AWS CodeDeploy 是一项负责对各 Amazon EC2 实例上的应用程序部署机制进行协调的服务。18AWS

CodeDeploy 能够与现有应用程序文件及部署脚本相配合，同时可轻松复用各类现有配置管理脚本。该服务可

与您的基础设施实现同步规模伸缩，这意味着大家能够部署从单一 EC2 实例到数千实例的各类规模水平工作

负载。如果大家希望将代码部署至自行管理或者由企业中其它部门管理的基础设施当中，那么 AWS

CodeDeploy 同样是个理想的选择。利用 AWS CodeDeploy 将代码部署至基础设施当中，而后利用 AWS

CloudFormation 对基础设施其进行配置与管理。即使大家没有使用 AWS CloudFormation，仍然可以利用

Amazon EC2 配合其它第三方工具，而 AWS CodeDeploy 可在这类场景下帮助我们管理应用程序部署。

Amazon EC2 容器服务

Amazon EC2 容器服务 19 是一项具备高可扩展性与高性能水平的容器管理服务，其能够显著简化 Docker 容器

在 Amazon EC2 实例集群上的运行、停止与管理等任务。在 Amazon EC2 容器服务的帮助下，大家可以利用

简单的 API 调用管理容器类应用、从集中式服务内获取集群状态，同时从 Amazon EC2 处获取安全组 20、

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

8 / 21

Amazon EBS 分卷以及 AWS 身份与访问管理（简称 IAM）角色 21等多种功能。Amazon EC2 容器服务适合那

些利用 Docker 作为构建与部署方式的用户，特别是希望改进 EC2 实例使用方式、或者将其作为高复杂度分布

式系统的朋友。

常见功能

AWS 提供多种针对各项部署服务的关键性功能。然而，也有部分功能适用于全部服务项目。每项功能都能够

以自己的方式对各服务产生影响。以下为部署服务当中的几项常见功能：

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

9 / 21

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

10 / 21

设置

正如之前所提到，大家可以利用 Amazon EC2、Amazon EBS、Amazon S3 以及 Amazon 虚拟专有云（简称

VPC）等构建单元完成部署工作 22，或者利用由各部署服务提供的自动化机制设置基础设施组件。使用这些服

务的优势多种多样，包括提供丰富的功能集以实现应用程序部署与配置、监控、可扩展性乃至与其它 AWS 服

务间的集成等等。下面具体对各项功能进行阐述。

部署

部署服务也能够简化底层基础设施之上的应用程序部署流程。大家可以创建一款应用程序，为所需要的部署服

务分配源，而后允许该工具处理运行应用程序所需要的各 AWS 资源的配置复杂性元素。尽管在部署层面其提

供的功能比较类似，但每项服务都拥有自己独特的应用程序部署与管理方法。

配置

除了部署应用程序，大家还可以使用各项部署服务以定制并管理应用程序配置。其底层任务可通过为定制化

Web 应用或者应用所需要的更新包（例如 yum 与 apt-get 库）进行定制配置文件替换实现（例如 httpd.conf）。

大家可以对 Amazon EC2 实例上的软件进行定制，亦可对堆栈配置内的基础设施资源做出调整。

规模

在需求提升的过程中，对应用程序进行规模扩展不仅能够带来更出色的最终用户使用体验，同时亦能够维持低

廉的运营成本。大家可以配置 Auto Scaling 从而立足动态方式基于 Amazon CloudWatch 内的触发指标（CPU、

内存、磁盘 I/O 以及网络 I/O 等）添加或者移除 Amazon EC2 实例。23这种 Auto Scaling 配置类型能够无缝

化接入 Elastic Beanstalk 以及 AWS CloudFormation。同样的，大家可以利用 AWS OpsWorks 自动根据时间

或者负载进行规模管理。

监控

监控功能可帮助大家对云环境下所启动的资源加以观察。无论大家希望对整体堆栈的资源利用率进行监控，还

是对应用程序运行状态加以查看，各项部署服务都能够帮助大家通过单一窗口完成信息收集。另外，大家也可

以导航至 CloudWatch 控制台获取与全部资源及运作状态相关的系统层视图。大家能够利用同样的技术手段创

建出指标警报机制，利用通知实现监控。警告机制可以在超出特定阈值或者发生严重问题时发送提醒信息。举

例来说，大家可以在某 EC2 未能成功完成状态检查或者 CPU 利用率超出特定阈值时给出提醒。

每项部署服务负责对部署流程中的对应环节进行处理。大家可以经由 AWS 管理控制台 24、CLI25或者 API26

追踪资源的添加或者移除。

日志记录

日志记录属于应用程序部署周期当中的一项重要元素。日志记录可提供重要的调试信息，或者提供与应用程序

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

11 / 21

行为相关的关键性特征。各部署服务能够简化日志的访问流程，包括将 AWS 管理控制台、CLI 以及 API 等方

法相结合，意味着大家不必登录至 Amazon EC2 实例当中即可实现日志查看。

除了内置功能之外，各项部署服务还提供与 CloudWatch Logs 无缝化对接的方式，旨在扩展大家对系统、应

用程序以及自定义日志文件进行监控的能力 27。大家可以利用 CloudWatch Logs 实时监控来自 EC2 实例中的

日志、监控 CloudTrail 事件或者 Amazon S3 当中的归档日志数据。28

实例配置

Instance 配置 29 是一种理想的 IAM 角色嵌入方式，可用于实现面向 AWS 资源的访问操作。这些 IAM 角色能

够立足于实例安全地指向 AWS 服务进行 API 请求，而无需额外执行安全凭证管理。各项部署服务能够以无缝

化方式与实例配置相集成，从而简化凭证管理并免除在应用程序配置当中进行 API 密钥硬编码的处理方式。

举例来说，如果大家的应用程序需要利用只读权限访问 Amazon S3 存储桶，则可创建一个实例配置文件并在

相关 IAM 角色内分配 Amazon S3 只读访问。该部署服务会承担起将这些角色传递至 EC2 实例的复杂工作，

确保大家的应用程序能够按照您预先定义的权限安全访问对应 AWS 资源。

自定义变量

在开发应用程序时，大家可能需要对配置值进行自定义，例如数据库连接串、安全凭证或者其它不希望以硬编

码形式存在于应用程序当中的信息。定义变量能够帮助大家实现应用程序配置的松散耦合，同时以理想的灵活

性对应用程序中的各层进行独立扩展。在应用程序代码之外进行变量嵌入有助于提高应用程序的可移植能力。

另外，大家也可以根据自定义变量对开发、测试与生产环境进行简单的差异化构建。各部署服务能够帮助大家

实现变量自定义，意味着在设定完成之后，这些变量会可用于您的应用程序环境。

其它 AWS 服务集成

AWS 部署服务提供与其它 AWS 服务轻松集成的能力。无论大家需要利用 Elastic Load Balancing 对跨越多个

可用区 30的应用进行负载均衡还是利用 Amazon RDS 作为后端，AWS Elastic Beanstalk、AWS

CloudFormation 以及 AS OpsWorks 等部署服务都能够显著简化这些服务在您部署流程中的使用方式。

如果大家需要使用 apxAWS 服务，则可利用针对具体工具的集成方法同对应资源进行交互。举例来说，如果

大家使用 Elastic Beanstalk 进行凙，并希望利用 DynamoDB 作为后端，则可将配置文件包含在应用程序源捆

绑包 31 内以实现环境资源的自定义。利用 AWS OpsWorks，大家可以创建自定义模板以配置应用程序，从而确保其能

够访问其它 AWS 服务 32。同样的，也有部分模板片段可立足于多种示例场景供大家在 AWS CLoudFormation

模板中直接引用。33

标签

使用部署服务的另一大优势在于，我们可以实现标签的自动化使用。一条标签由一条用户定义的键与值构成。

大家可以根据应用程序、项目、成本中心、业务部门或者其它单位进行标签定义，从而轻松完成资源识别。在

开发阶段中使用这些标签时，各类工具能够自动对应标签之后的底层资源，例如 Amazon EC2 实例、Auto

Scaling 分组或者 Amazon RDS 等等。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

12 / 21

理想的标签机制能够帮助大家更好地利用成本分配报告进行成本管理。34成本分配报告根据各项标签进行成本

汇聚。通过这种方式，大家能够了解到自己在各项应用程序或者特定项目当中支出了多少成本。

堆栈更新策略

根据实际选择的部署服务，应用程序代码的更新策略也可能有所不同。AWS 部署服务能够提供敏捷性优势并

改善应用程序的部署速度，但使用正确的工具与策略则成为构建强大环境的一项前提条件。

以下章节着眼于各部署服务如何帮助我们完成应用程序更新。下面提到的各项方案首先进行预置设备镜像生成，

而后是现场执行并进行一次性升级。

预置 AMI

所谓 Amazon Machine Image（简称 AMI），是指一套由基础操作系统或者云端应用程序服务器构成的镜像。35为了启动一套 EC2 实例，大家需要选择使用哪种 AMI 以安装自己的应用程序。常见的作法是在实例启动过

程中安装应用程序。这一流程被称为引导实例。AWS CloudFormation 提供多种选项以实现应用程序的引导。

要了解更多具体可选项目，请参阅通过 AWS CloudFormation 进行应用程序引导。36

需要注意的是，如果大家的应用程序非常复杂或者有多款应用程序需要安装，则整个引导过程可能速度较慢。

利用多款构建工具管理一组应用程序时，其中的依赖性往往很难在发布中得到妥善处理。因此，大家的部署服

务应当在设计中重视快速发布从而发挥 Auto Scaling 的固有优势。

预置是一种嵌入流程，旨在将应用程序中的某一部分添加到基础 AMI 当中。在开发过程中，大家可以使用各

类 EC2 实例元素（例如实例标签、实例元数据以及 Auto Sclaing 分组）实现应用程序安装的自定义。

举例来说，我们假设大家正在管理的 Ruby 应用程序需要利用 Nginx 作为前端; Elasticsearch、Logstash 与

Kibana 用于日志处理; MongDB 实现文档管理。大家可以对基础 AMI 进行逻辑分组，由其将 80%的应用程序

二进制代码加载至这些 AMI 组中。大家可以选择在引导过程中安装大部分应用程序，并立足于由实例标签、

Auto Scaling 分组或者其它实例元素划分的配置组进行安装调整。大家可以在 Nginx 实例上（例如

Nginx-v-1.6.2）上设置一个标签。更新流程会查询该实例标签，验证其是否属于 Nginx 的最新版本，而后在安

装流程中执行。在对预置 AMI 进行更新时，大家可以直接利用来自底层部署服务的最新版本覆盖现有 AMI，

而后更新该标签。

AWS CLoudFormation 以及 AWS OpsWorks 等部署服务更适合处理预置 AMI 方案。大家也可以利用其它第

三方工具完成预置 AMI。其中比较知名的选项包括 packer.io37以及 aminator38（由 Netflix 公司推出）。大家

也可以为自己的配置管理方案选择其它第三方工具，例如 Chef、Puppet、Salt、Ansible 以及 Capistrano 等等。

原状对一次性方法

各部署服务提供两种方法，旨在帮助大家更新自己的应用程序堆栈，即“原状”与“一次性”。原状升级方法

在 Amazon EC2 实例之上实时执行应用程序更新。而一次性升级则通过终止旧有实例并发布新的 EC2 实例组

实现。

原状升级通常用于一致性发布规划中的快速部署需求。其设计目标主要指向无会话应用程序。大家也可以使用

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

13 / 21

原状升级方法实现有状态应用程序的滚动部署规划，同时实现之前曾经提到的蓝-绿部署机制。

相比之下，一次性升级则提供简单方式以了解大家的应用程序中是否存在求知依赖性。底层 EC2 实例使用情

况在部署阶段应被视为临时或者一次性属性，直到其当前发布状态为活跃。在新版本的发布过程中，将有一组

新的 EC2 实例推出以替代原有实例。这类升级技术常见于恒定基础设施当中。

原状升级中的典型服务为两种：大家可以使用 AWS CodeDeploy 在管理更新的同时，继续利用各独立构建单

元（Amazon EC2、Amazon EBS、Amazon S3 以及 Amazon RDS 等等）管理应用程序部署; 或者利用 Github、

Jenkins、Travis CI 或者 Circle CI 等第三方托管构建系统。另外，大家也可以使用 AWS OpsWorks 同时管理

应用程序部署与更新。

而对于一次性升级，大家可以设置一套克隆环境，其中包含部署服务（AWS Elastic Beanstalk、AWS

CloudFormation 以及 AWS OpsWorks）或者利用其同 Auto Scaling 配置相结合以管理更新。

原状升级方法

AWS CodeDeploy 是一款专门负责实现软件部署的工具。大家可以利用此工具部署来自 Amazon S3 以及

GitHub 库的应用程序。一旦大家完成了部署内容以及底层 Amazon EC2 实例的筹备，则可在一致性基础之上

部署应用程序及其版本控制。大家可以将更新推送至一组由有标签 EC2 实例 39以及/或者 Auto Scaling 分组 40

生成的实例组（名为部署组）。另外，AWS CodeDeploy 能够与多款配置管理工具、持续集成与部署系统以及

源控制系统进行协作。大家可以参阅 AWS CodeDeploy 说明文档以了解完整的生产集成选项列表。41

另一项可用于管理应用程序整体生命周期的服务为 AWS OpsWorks。大家可以使用内置层或者部署自定义层

与模板，实现应用程序堆栈的启动。另外，亦有多种自定义选项可用于配置并推送应用程序更新。欲了解更多

信息，请参阅利用 OpsWorks 管理多层 Web 应用程序内的 OpsWorks 堆栈更新策略部分内容。42

一次性升级方法

大家可以通过多种方式执行一次性升级。我们可以使用一项 Auto Scaling 策略来定义如何对实例进行添加（向

外扩展）与移除（向内收缩）43。通过将此与现有更新策略相结合，大家能够将应用程序更新的发布作为规模

伸缩事件中的组成部分。

举例来说，大家可以利用新的 AMI 更新 Auto Scaling，同时在事件规模伸缩过程中利用 OldestInstance 配置

一项终止策略。或者，大家也可以使用 OldestLaunchConfiguration以利用原有配置进行各实例分段。如果大

家使用 Elastic Load Balancing（简称 ELB），则可将额外的 Auto Scaling 配置附加至 ELB 之后，同时利用同

样的方法分段发布新实例并移除旧实例。

同样的，大家可以利用各类部署服务（例如 AWS Elastic Beanstalk44以及 AWS CloudFormation45）配置滚动

部署。大家可以利用更新策略描述 Auto Scaling 组中的各个实例如何在更新策略中接受替换或者修改。大家能

够控制并发或者批量更新的实例数量。大家也可以选择针对特定实例进行更新，同时隔离其它尚处于服务中的

实例。大家也可以指定不同批量更新之间的等待时间。另外，大家也可以取消或者回滚更新，从而解决应用程

序代码当中存在的 bug。这些功能可帮助用户提升应用程序在更新阶段当中的可用性。在下一章节中，我们将

解决利用 Auto Scaling 对有会话应用程序的更新进行管理时存在的部分问题。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

14 / 21

蓝-绿方法

蓝-绿方法意味着大家需要为运行在自有环境内的应用程序设置两套相同的堆栈。大家可以利用多种策略将现

有应用程序堆栈（蓝）中的流量迁移至该应用程序的新版本处（绿）。这是一项非常流行的零停机时间应用程

序部署技术。AWS Elastic Beanstalk、AWS CloudFormation 或者 AWS OpsWorks 等部署服务在这类场景中

能够发挥巨大作用，特别是其能够提供简单方法以克隆运行当中的应用程序堆栈。大家也能够对现有应用程序

版本（蓝）进行克隆，从而设置出该应用程序的新版本（绿）。

对于无会话 Web 应用程序，其更新流程则非常 简单。首先对应用程序的新版本进行上传，并利用各部署服务

（AWS Elastic Beanstalk、AWS CloudFormation 或者 AWS OpsWorks）部署新版本（绿）。为了切换至新版

本，大家只需要替换 DNS 记录当中的 ELB URL 即可。Elastic Beanstalk 拥有一项 Swap Environment URL

（即清除环境 URL）功能，从而简化这一切换流程。如果大家利用 Amazon Route 53 管理自己的 DNS 记录，

则需要清除 ELB 端点以确保 AWS CloudFormation 或者 AWS OpsWorks 部署服务得以正常执行。46

图二：蓝-绿部署

而对拥有会话状态的应用程序来说，这一切换流程则更为复杂。当执行更新时，大家当然不希望最终用户遭遇

停机时间或者数据丢失。大家应当考虑将各会话存储在部署服务之外，并利用特定部署服务创建新堆栈以重建

会话数据库。具体来讲，如果大家在使用 Amazon RDS 数据库或者 Amazon ElastiCache，则可考虑将会话独

立存储于部署服务之外。47

请阅读利用 Elastic Beanstalk 在应用程序升级过程当中实现零停机时间的相关建议。48同样的，参阅相关建议

以保证在更新 AWS CloudFormation 堆栈的同时避免对堆栈资源进行更新。49另外，考虑在蓝部署内监控各项

实例，并在关闭旧有实例之前关停各 ELB 连接。50

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

15 / 21

如果大家使用Amazon Route 53托管自己的DNS记录，则可以考虑利用Weighted Round Robin（简称WRR）

功能完成由蓝到绿的部署迁移工作。该项功能有助于实现流量的逐步转换——而非一次性切换 51。如果大家的

应用程序当中存在 bug，则此方法能够确保将受影响范围控制在最低程度，即只影响到极少数用户。另外，大

家只需要使用最低限度实例数量，同时在绿阶段进行向上扩展并在蓝阶段实现向下收缩。举例来说，我们可以

将 WRR 设置为只允许 10%流量指向绿部署，而仍有 90%流量继续指向蓝部署。大家可以逐步提升绿实例的

流量承载比例，直到整个部署过程全部完成。另外，全程利用 DNS 缓存缩短客户端的 TTL，从而确保客户仍

然能够接入快速发布中的绿部署，最终有效降低负面 DNS 缓存行为的数量。

混合部署模型方法

大家也可以以混合方式使用各项部署服务，从而管理自己的应用程序组合。举例来说，大家可以将 Elastic

Beanstalk提供的 AWS基础设施管理简化效果同 AWS CloudFormation实现的自定义网络分区自动化相结合。

利用混合部署模型亦能够简化整体架构，因为其将实现部署方法解耦，从而允许大家为应用程序堆栈的更新选

择多种不同策略。

下面提供几种示例场景。虽然并非面面俱道，但相信其足以帮助大家在一定程度上了解自己的混合部署方法规

划思路。

场景一：利用 AWS CloudFormation 部署一款 Elastic Beanstalk 应用程序与一项 AWS 服务集成（例如

DynamoDB、Amazon RDS 以及 Amazon S3）。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

16 / 21

图三：场景一参考架构

场景二：利用 AWS CloudFormation 在 AWS OpsWorks 当中部署多套同样的应用程序堆栈，而后利用 AWS

CloudFormation 对整体基础设施加以管理。

图四：场景二参考架构

场景三：利用 AWS CloudFormation 部署多套应用程序堆栈，并利用 Elstic Beanstalk 与 AWS OpsWorks 进

行管理。

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

17 / 21

图五：场景三参考架构

场景四：利用 AWS CodeDeploy 部署并管理多款应用程序，同时利用 Amazon EC2 与 AWS CloudFormation

进行基础设施配置。

图六：场景四参考架构

总结

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

18 / 21

Amazon Web Services 提供多种工具，旨在简化并将自动化机制引入基础设施配置与应用程序部署。每项部署

服务皆拥有自己独特的应用程序部署管理方法，亦提供一系列可实现应用程序更新的策略。为了实现最佳效果，

大家应当关注自身工作负载并选择最适合实际需求的部署服务。在规划当中，应考虑利用混合部署模型方法将

多种部署服务加以结合，最终贯穿整个生命周期实现多款应用程序的全程管理。

备注

1 http://aws.amazon.com/ec2/

2 http://aws.amazon.com/ebs/

3 http://aws.amazon.com/s3/

4 http://aws.amazon.com/glacier/

5 http://aws.amazon.com/rds/

6 http://aws.amazon.com/redshift/

7 http://aws.amazon.com/dynamodb/

8 http://aws.amazon.com/kinesis/

9 http://aws.amazon.com/elasticbeanstalk/

10 https://www.docker.com/

11 http://aws.amazon.com/autoscaling/

12 http://aws.amazon.com/elasticloadbalancing/

13 http://aws.amazon.com/cloudformation/

14 http://aws.amazon.com/codedeploy/

15 http://aws.amazon.com/opsworks/

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

19 / 21

16 http://aws.amazon.com/codecommit/

17 http://aws.amazon.com/codepipeline/

18 http://aws.amazon.com/codedeploy/

19 http://aws.amazon.com/ecs/

20 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-

security.html

21 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-

amazon-ec2.html

22 http://aws.amazon.com/vpc/

23 http://aws.amazon.com/cloudwatch/

24 https://console.aws.amazon.com/

25 http://aws.amazon.com/cli/

26 http://aws.amazon.com/tools/

27

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/Wh

atIsCloudWatchLogs.html

28 http://aws.amazon.com/cloudtrail/

29 http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html

30 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-

availability-zones.html

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

20 / 21

31 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-

containers.html

32 http://docs.aws.amazon.com/opsworks/latest/userguide/other-services.html

33

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/CHAP_

TemplateQuickRef.html

34 http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/allocation.html

35 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

36 https://s3.amazonaws.com/cloudformation-

examples/BoostrappingApplicationsWithAWSCloudFormation.pdf

37 https://www.packer.io/

38 https://github.com/Netflix/aminator

39

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#U

sing_Tags_Console

40 http://docs.aws.amazon.com/codedeploy/latest/userguide/auto-scaling-

integ.html

41 http://aws.amazon.com/codedeploy/product-integrations/

42 http://d0.awsstatic.com/whitepapers/managing-multi-tiered-web-

applications-with-opsworks.pdf

Amazon Web Services – AWS 上的部署选项 2015 年 3 月

21 / 21

43

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScaling

Behavior.InstanceTermination.html

44 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-

features.rollingupdates.html

45 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-

attribute-updatepolicy.html

46 http://aws.amazon.com/route53/

47 http://aws.amazon.com/elasticache/

48 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-

features.CNAMESwap.html

49

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect

-stack-resources.html

50

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/co

nfig-conn-drain.html

51 http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-

policy.html#routing-policy-weighted