[转]基于AWS的自动化部署实践

做者 徐桂林 发布于 2014年1月22日 

--------------------------------------------------------------------

1. 背景

在过去几年里，社交、移动和云计算深入改变了整个互联网的格局。做为设计软件领域的全球领导厂商，Autodesk也与2009年正式开始从传统桌面设计软件提供商向在线服务、协做和移动端设计转型。在此次转型中，公司充分利用现代云计算的巨大优点给客户带来了大大超过传统桌面软件的处理能力、用户体验和性价比。其中AWS是目前公司服务的主要运行平台，每一年在此投入千万美金级别。

1.1. 传统软件交付的挑战

在过去的30多年里，Autodesk拥有了很是多的桌面设计软件（如AutoCAD，Maya，3dsMax等）。因为设计软件常常须要处理超大的数据集合（如整个上海中心的设计模型）和极其复杂的运算逻辑（如阿凡达电影画面的绘制），其软件尺寸通常都比较大（GB级别）。之前，客户基本都是经过互联网下载、快递或者分销商得到软件安装包，整个过程比较耗时。另外，软件的升级、安装和维护也是一个很是大的工做量（一些大的设计公司要购买上千份软件拷贝）。尽管公司软件已经支持基于应用程序虚拟化的集中管理模式，但它仍是有如前期基础设施建设成本大，服务能力缺少弹性，仍须要专职运维人员等明显的缺点。因此，提高软件交付的用户体验成为咱们必需要面对的一个问题。

如大多数人所猜想，SaaS成为咱们的第一个尝试方向。在2006年，Autodesk实验室开始尝试以SaaS提供设计软件服务的可能性，而且取得了不错的成绩。可是，目前SaaS应用仍然面临着浏览器能力限制、大数据传输慢等诸多问题，没法给专业设计师提供传统桌面软件同样的体验和设计能力。 

1.2. 云计算带来的新可能

随着云计算的兴起，以AWS为表明的基础设施云提供商让咱们有可能以一种全新的方法去解决这个问题。咱们能够利用基础设施云的强大后台来帮助用户运行虚拟化的软件实例。用户无需下载、安装和维护这些软件，只须要连接到互联网上就能够在线使用咱们的软件。并且按需付费以下降使用成本。基于此，Autodesk实验室在2009年开始这个尝试（注：该服务已经于2013年成为公司云平台产品的一部分），并选择了AWS作做为咱们的后台云服务提供商。选择AWS有下面的几个缘由：

• 须要基础设施云（IaaS）。如今的平台云（PaaS）大部分都是为Web服务准备的，并不适合咱们运行虚拟化实例的要求。
• 须要强大的弹性运算能力。Autodesk设计软件对于计算的需求都很大，而计算能力的成本不低。因此，弹性计算能力能让咱们很好的控制成本。AWS EC2在这方面很是符合咱们的需求。
• 须要丰富的服务。除了运算能力，咱们还须要给用户提供海量设计数据的存储，快速的数据访问，安全的访问控制等。AWS云服务在这方便服务很是完备，并且相互集成很容易。
• 须要稳定的服务。AWS EC2可以提供超过99.5%的弹性计算可用率，能为咱们创建可靠服务提供坚实的基础设施。
• 须要全球化部署。Autodesk是一个在全球提供软件、服务的公司，因此咱们但愿基础设施提供商也能全球布局。而AWS已经在全球创建多个数据中心。

2. 自动化部署

在完成服务的基本实现并上线服务后，整个后台的维护和部署成本在不断加大。尤为考虑到咱们须要高频（每月更新一次）、多地（多个AWS数据中心）部署服务并同时须要维持高的服务可用性，构建一个自动化的部署系统成为必需要作的事情。

2.1. 设定目标

做为一个运行在AWS上的服务，咱们在设计之初就开始思考AWS给自动化部署带来的新可能和挑战。在咱们看来，针对AWS上服务的自动化部署须要特别关注到下面的一些特色：

 

• 基础设施的服务化。在AWS中，你能够利用相似Cloud Formation服务在很短期（几分钟）获取你所要的全部基础设施（包括运算、存储、网络、IO等），而这些基础设施已经按照你的要求自动配置、链接好。因此，咱们可让自动化部署把基础设施的管理也包括进来，而这在传统的数据中心模式下很难实现。
• 支持弹性资源。由于须要支持弹性，整个服务要在运行时动态加入新的基础设施，如计算单元等。自动化部署系统须要能让新加入的基础设施立马投入服务。
• 保护数据更为重要。在传统的数据中心，咱们可让部署彻底在内部网络完成，在确认好全部的安全配置后再上线。可是AWS是一个公有云服务，你的全部部署实际上是在公有网络上完成的。因此，咱们必须在自动化部署中充分考虑到数据安全的问题。

结合上面的特色、DevOps的广泛实践和项目的实际状况，咱们给整个自动化部署系统定下了下面的目标：

• 一键式部署：必须尽量的自动化全部部署过程，包括基础设施的建立和部署。
• 多环境支撑：必须可以适应于Production、Staging和Development环境。
• 无服务中断：必须可以无缝的进行服务升级、切换。
• 随时可回滚：必须能够很容易的回滚到前面的版本以处理意外问题。
• 安全性检测：必须在确认部署环境的安全设置已经知足条件后才开始作部署工做。

2.2. 总体架构

在肯定目标后，咱们进行了技术选型，但愿可以找到既很好支持AWS相关自动化操做，又能集成DevOps优秀实践的方案（注：那时AWS尚未推出OpsWorks服务）。但最后并无找到合适的方案，因而决定本身来实现整个自动化部署系统。通过几轮的改进和实现，如今的自动化部署系统总体结构以下：

图1：自动化部署系统总体架构

相似于传统的自动化部署，咱们也一样有开发分支和发布分支，并与持续构建系统对接。当开发人员提交代码后，相应的构建就会在代码所在的分支自动触发。在完成代码编译和集成的自动化测试（目前主要是单元测试）后，将产生相应部署组件并存放在构建系统中（目前，每一个构建会产生全部的系统组件并拥有一样的版本号）。至此，整个构建过程完成。

为了支持多环境部署和安全隔离，咱们使用两个独立的AWS帐号来运行不一样的环境。其中开发环境在一个ＡＷＳ帐户内，只部署开发分支的构建。而生产系统则在另一个AWS帐户中，其下运行Prod/Staging两组环境。发布分支永远只会向Staging环境部署并在完成最后验证测试后与当前Prod环境进行热切换，从而达到无服务中断的目的。

2.3. 一键部署流程

在完成自动化持续构建后，咱们就能够部署其中的任意版本。当部署某一构建版本时（不管开发分支仍是发布分支），整个流程以下：

图2：一键式部署流程

1. 触发“一键部署”命令：在构建系统中选择好要部署的分支和版本，直接一键点击触发命令。
2. 上传部署文件到S3：如图1所示，部署组件是在运行时动态下载安装。AWS S3提供在线存储并可以方便的下载到EC2实例中，因此把部署组件上传到S3中最合适不过。为了支持多版本并存和部署回滚，全部上传到S3的部署组件都按版本号分文件夹存储。
3. 获取当前部署环境的配置文件：部署环境配置文件存在相应AWS帐户下的S3中。它定义了当前AWS帐户下面的部署配置，包括须要部署的数据中心列表，每一个数据中心下面的基础设施描述（Cloud Formation Stack）。因为Prod/Staging环境都在同一个AWS帐户下，每一个数据中心都会有两组Cloud Formation Stack配置（分别用于Prod和Staging环境）。部署系统会选择当前Staging环境的Cloud Formation Stack做为下一步的部署目标。
4. 初始化部署目标基础设施：根据当前选中的Cloud Formation Stack初始化整个基础设施，包括启动相应的EC2实例，绑定Elastic IPs等。
5. 运行部署环境：在整个基础设施运行起来后，EC2实例第一步就是自动作运行时部署（利用操做系统的启动脚本实现）。具体运行时部署细节以下：

   图3：运行时部署

6. EC2实例在完成整个自动化部署中要及时进行有效性检测，如检测下载组件包是否完整正确，组件安装是否成功，指望的服务是否能够正确访问等。在完成全部部署和有效性检测后方加入的正式服务系统并处理用户请求，不然及时报告运维团队进行处理。

2.4. 为何选择运行时部署

看到上面部署流程，相信不少人会问一个问题：AWS不是能够经过虚拟机镜像（AMI）来启动EC2实例，为何不把上面的部署组件直接烧入AMI？这样在EC2实例启动后就直接使用而无需作运行时部署。其实，咱们的最初解决方案就是把部署组件直接烧入AMI，但很快就发现了这种方案的局限：

部署组件的变化是很是频繁的，尤为是在发布前，一天都可以产生上十次的变化。这就意味着自动部署系统可能须要频繁产生AMI。而AMI的建立过程并不快（10分钟~1小时），而且过多的AMI也会形成管理问题和额外的存储成本。

做为一个平台项目，各个产品会在咱们的平台上运行。咱们但愿提供给各个产品部门的基本AMI是平台版本无关的。这样产品部门在基本AMI基础上部署它们产品并从新生成的产品AMI也是平台版本无关的。因而产品AMI能够不作任何修改就可以快速采用最新的平台版本。具体以下图所示：

图4：自动化部署中的AMIs

为了保证图4中的基本AMI和产品AMI是平台版本无关，咱们就须要保证烧入AMI的全部部分都是可以独立于平台版本的。可是，启动脚本须要作平台组件的运行时部署，显然这个运行时部署脚本也会随着平台更新不断变化，因此咱们没法直接把整个运行时部署脚本放到启动脚本中。针对这个问题，咱们的解决方案就是把整个运行时部署脚本分红两部分。一部分作平台组件的安装、检测工做，并随安装组件存到S3中，而另一部分只作基本不会改变的事情（下载平台组件包并调用自动化部署脚本）并设置为操做系统的启动脚本。这也是图3中启动脚本和自动化部署分开两部分的缘由。

正是由于采起了上面的AMI生成、管理策略，咱们的产品部门基本上不用太频繁的更新它们产品的AMIs（除非产品自身有更新），真正作到平台版本和产品版本的去耦合，极大的下降了运维成本。

2.5. 运行时版本选择与回滚

因为产品AMI是平台版本独立的，以它为镜像运行起来的EC2实例没法知道应该去下载哪个版本的平台组件。幸运的是AWS的EC2服务提供了“User Data”机制。简单来讲，就是在启动EC2实例的时候能够传入一段用户自定义数据给AWS。当这个实例运行起来后，实例内部程序能够经过调用AWS EC2的元数据服务取得先前传入的用户自定义数据。因而，咱们能够把当前须要运行的平台版本号以“User Data”的方式传给EC2实例，而后让启动脚本读取相应版本号并下载相应版本组件来部署。

一样，基于“User Data”机制和平台版本无关的AMI，咱们很是容易得实现版本的回滚。只须要修改传入给“User Data”中的版本号并保证要回滚到的平台组件版本仍然存在于S3中便可。即便是从零开始回滚到之前版本也能够在几分钟内完成（主要时间花费在启动EC2实例上）。在实际运营中，由于已经有了Prod/Staging的热切换，咱们通常会在切换上新的版本后保持原来的版本运行一段时间（这段时间通常是问题的高发期）以便作到秒级的回滚。

2.6. 关于安全

如前面所说，咱们须要格外关心在AWS上自动化部署的安全问题。在咱们的实践中，时刻会遵循最小受权原则并利用AWS中的IAM服务实施，具体体如今下面的两个原则上：

• 不要让管理员以外的任何人直接使用AWS根帐户（包括它的Access Key和Access Security）。取而代之的是建立专门的IAM User并给于其必须的权限
• 不要在公司防火墙以外使用任何帐号的Access Key和Access Security。取而代之的是使用IAM Role来获取EC2实例运行时须要的资源访问权限。

例如，咱们的构建系统须要访问多项AWS服务资源（如S三、EC二、Cloud Formation等），而构建系统又在防火墙内部，因此咱们建立专用的 IAM User来作自动化部署并给予构建系统须要的资源访问权限。另外，EC2实例须要访问S3并下载部署组件，因此EC2应该以专用的IAM Role来运行并在IAM Role中给予相应的S3桶只读属性。

2.7. 为何不是AWS OpsWorks

熟悉AWS服务的人可能都知道Amazon已经在2013年发布了它的DevOps服务： OpsWorks。咱们的自动化部署系统为何没有选择这个服务呢？最直接的缘由就是咱们开始构建自动化部署系统时候，AWS尚未发布OpsWorks。在AWS发布OpsWorks后，咱们对此作了仔细调研，并决定继续使用目前的系统。要了解其背后缘由，就要完整理解AWS提供的一系列应用程序管理服务（Application Management Services）之间的关系。这里，让咱们首先看看AWS文档中这张示意图：

图5：AWS中的应用程序管理服务

就如上图所示，AWS为各类应用场景提供了不一样的解决方案。因为针对的应用场景不一样，这些服务的关注点也就不一样。例如，AWS Elastic Beanstalk主要是为Web应用程序提供快速部署服务（有点相似国内SAE、BAE等服务），它帮助开发和运维人员隐藏了大量的底层细节，很是方便上手部署应用。可是，该服务在管理底层基础设施架构上就基本没有多少灵活性，没法适应项目的个性化需求。就咱们的服务而言，它开始于最右边的彻底本身定制方案。在AWS推出Cloud Formation后，为了提升系统的效率和自动化程度，咱们迁移到以Cloud Formation为基础的新方案。可是咱们没有继续向AWS OpsWorks迁移。究其原因，让咱们先多方面比较一下AWS OpsWorks和AWS Cloud Formation：

特性	AWS Cloud Formation	AWS OpsWorks
基础设施架构	以Stack的方式管理整个基础设施，你能够以任何你想要的架构组织你的基础设施。	遵循常见的架构实践，以Stack、Layer和App为核心观念来管理整个服务架构，并利用Chef 来把App自动化部署到各个Layer上。尽管它也有很大的灵活性，可是你须要把本身的基础设施架构映射到上面的这些概念中以实施该服务。
AWS资源管理	支持几乎全部的AWS资源。你能够在Cloud Formation的JSON模板中方便地加入各类AWS资源。Cloud Formation会自动帮你管理各类资源之间的依赖关系。你也能够自定义一些资源之间的逻辑依赖关系。	支持主要的AWS服务资源（如EC二、EBS、ElasticIP，ELB等），并利用这些资源构建常见的Layers。固然你也可本身加入一些非内建的资源（如RDS服务）到OpsWorks中来，可是它没法达到Cloud Formation对于资源管理的广度。 另外，目前的OpsWorks仅仅支持Amazon Linux 和Ubuntu LTS操做系统，你可使用这些系统的默认AMI或者在这些默认AMI基础上建立的新AMI。
定制化	支持利用参数改变由资源模板定义的Stack默认行为。	支持利用自定义JSON改变Stack的默认行为。
自动部署	支持各类自动化部署工具（如Chef、Puppet等），可是你须要本身实现全部的自动化部署脚本。	支持基于Chef的自动化部署，而且提供了大量的内建自动化脚本。这些内建的自动化脚本会帮助开发和运维人员完成不少的常见工做（如自动部署Tomcat服务器等）并已经集成到整个服务中去。另外，它一样支持自定义的Chef脚原本实现项目相关的部署。
弹性支撑	支持彻底自由控制的弹性策略。用户可使用Auto-Scaling组加自定义的性能指标来肯定Scale-up/down的条件。	提供基于负载（Load-Based）和基于时间（Time-Based）的弹性策略。其中基于负载的弹性策略主要考虑CPU、内存等几个主要因素。
系统监控	支持基于Cloud Watch的监控机制。用户能够监控大量的内建指标并添加自定义的监控指标到Cloud Watch中去。	提供以Stack为单元的整合监控界面，一样以Cloud Watch为基础提供监控服务。另外，它还提供了基于Ganglia的可选监控方案。
安全管理	支持IAM的完整功能。用户能够精细控制各个资源的访问权限。	支持IAM的完整功能。并能方便的把相应的安全策略批量实施。

 

表1：Cloud Formation与OpsWorks的比较

参考上面的比较和咱们目前的自动化部署系统，OpsWorks对于咱们仍然有一些限制：

• 没法支持Windows操做系统。咱们的不少服务仍然是运行在Windows系统上。
• 没法提供自定义的弹性策略。咱们的系统实现了本身的调度算法，目前把该调度算法映射到如今OpsWorks中还比较困难。

随着OpsWorks的发展，这些限制将来均可能会被解决。可是，做为一个已经运行的系统，咱们仍然须要仔细评估OpsWorks带来的收益和成本以肯定是否迁移。若是须要在AWS上面部署一个新的应用，推荐的实践就是如图5从左向右依次选择，而且在确认左面的方案有明确限制的状况下再考虑下一个选择。若是图5中左边服务已经可以解决问题，就不建议本身开发相应的系统。毕竟整个部署系统的开发和维护仍是须要一个不小的成本，而AWS提供的这些应用程序管理服务都免费的。另外，在绝大多数状况下，Cloud Formation已经足够灵活以知足你在AWS上部署服务。可是，在某些状况下（例如，同时支持在多个云服务提供商上部署服务），你可能还得选择彻底本身开发或采用第三方供应商的方案。

在过去的一年里，咱们利用上面的自动化部署系统让整个部署过程的耗时从最初的几天快速降低到几分钟以内，大大下降了的开发、运维人员的负担。如此同时，自动化部署还把部署出错的可能性降到了一个极低的水平，提升了系统的总体可用性。

3. 总结

在上面的文章中，我仔细介绍了整个自动化部署系统，并讨论了怎样充分利用AWS服务的特色来提升自动化部署的效率。该系统运行高效、稳定，并且极大程度的下降了平台自身和运行于平台上产品的运维成本。接下来，咱们仍然会持续改进整个系统，其中关注的重点有：

• 解决各个平台组件之间的兼容问题。咱们但愿让自动化部署系统可以根据设置的规则自动检测各个组件内的兼容问题并选择合适版本自动化部署，这样，各个组件能够按照自动的节奏（和版本号）独立发布（而不是像如今全部的组件必须以一个版本一块部署）。
• 开发整个自动化部署系统的控制台界面（Dashboard）。该界面可让咱们本身和产品部门看到系统的目前部署状态及部署历史，而且可让一键部署在该控制台触发，从而让平台内部的构建系统完全隐藏在背后。
• 尝试和AWS OpsWorks的结合。OpsWorks的一个优点就是集成了大量DevOps实践精髓并提供了丰富的内建部署脚本，能够下降自动化部署系统自身的开发和维护成本。尽管如前所述，目前尚未办法向该系统迁移，但咱们仍然会密切关注OpsWorks自身的发展，并会在平衡收益与成本的前提下积极尝试和AWS OpsWorks的结合。

关于做者

徐桂林现为Autodesk中国研发中心的高级开发工程师。2007年加入Autodesk中国研发中心，前后在Autodesk Labs、CTO Office工做，如今Autodesk云平台事业部（Cloud Platform）工做。在2007年开始参与多个SaaS相关的开发，主要作前端开发。从2009年年末转向作后端，开始使用AWS服务并领导中国团队的开发工做。毕业于浙江大学计算机系CAD&CG国家重点实验室，关注云计算、前端开发等相关技术。

 

转自：http://www.infoq.com/cn/articles/automated-deployment-practice-based-on-aws/