《AWS DevOps架构实践》由会员分享，可在线阅读，更多相关《AWS DevOps架构实践（49页珍藏版）》请在金锄头文库上搜索。
1、AWS DevOps架构实践一年5000万次部署的实现本文将跟大家分享一下亚马逊AWS在DevOps方向的一些见解。AWS其实是在亚马逊整个DevOps沃土中发展起来的一个产品体系，所以在讲AWS时，我希望给大家看到的不是一个服务的广告，而是一些DevOps理念真正的实现。关于DevOps大家对DevOps也比较清楚了，我们不希望研发人员直接把代码丢给运维，再让运维去做，因为代码的发布是一次发布成千上万个，如果出现问题，我们不知道怎么去修改，我们的希望是让整个代码发布、整个运维更加顺畅。所以在亚马逊，DevOps需要管理很多很多方面的问题：包括了基础设施、IT自动化和配置管理、版本控制的集成、
2、持续集成和持续交付、持续部署、应用和基础设施的版本管理、监控和日志管理等。亚马逊的DevOps故事1、亚马逊开发流程的演进 传统应用发布的4个阶段：冗长的周期和复杂的协作亚马逊作为一家非常庞大的电商公司，最早进行开发时也有很多的团队，把它分在一个代码里去发布，然后在开发时会用一种很传统的源码编译、特色生产的过程去做。 亚马逊开发形式的转变：2001-2009这个过程持续了很久，直到2001年，我们的创始人跟一个巨大的运维团队将里面越来越多的开发运维进行了改善，所做的就是把整个亚马逊的服务拆成很多微小的服务。当时在内部有个说法，可以看到就是上图中的2 pizza teams，即我们希望用两张披萨
3、饼就可以喂饱每一个承担这些微服务的团队，这一点在亚马逊内部是贯穿始终的。两个披萨饼、一顿午饭，大概就是说2到10来个人的团队，这个情况下每个团队都是在这么小的一个范围内，他们能对外提供一个统一的标准化的接口，内部也可以用自己的方法去构建自己的服务，去保证整体的服务是一个统一的整体。这样的情况下，我们通过构造一个巨型的面向服务的架构，单一地通过不同的APL调用，把整个亚马逊的各种服务进行一个高度的解耦，最后达到的效果就是每一个团队都有自己的持续集成、持续交付、持续发布的灵活情况。软件生命期新的管道这个情况可达到怎么样的效果呢？可以达到一年5千万次的部署，如果按工作日来算，就是平均下来一年里每11
4、秒就可能会有一个小版本部署上去，这个版本部署可能只有几十行代码的修改，然后2 pizza teams会针对这个版本做自己的回归测试、单元测试，保证自己提供出去的APL是稳定可靠的。总体通过一个巨型的架构，利用中间的微服务APL调用来保证我们整体去做，所以可以同时部署在很多不同的服务器、应用上，这是亚马逊今天能够做到的。我们屏蔽了以前旧的软件交付方式，可能要用很多不同的版本，甚至用十几个介质来配适我们的客户，包括在亚马逊AWS上的客户，他们已经可以很好地用新的这种交付方式去做。这里，亚马逊想到，除了能够让我们自身的团队变成这样，其实能不能为我们的客户去做到这样一个微服务的架构或持续集成的架构，于
5、是就有了亚马逊AWS服务体系的诞生。接下来我会介绍AWS这部分DevOps方向的一些服务，通过这个服务去看到我们如何能够在一个云端非常敏捷地实现DevOps，同时也会介绍到一些DevOps的框架和工具。基于AWS服务实现DevOps的框架和工具1、AWS对DevOps的全面支持首先AWS对DevOps是全面支持的，包括从代码的提交到各种的FreeWork Test，然后会有SDK去调用我们的APL，去使用平台的各种基础设施，建立流畅的自动交互渠道，下图是我们整个持续流程的模型。这个模型也包括了我们整个域名服务。域名服务很多情况下跟我们整个DevOps的服务是一个最基础的入口，因为访问是通过域名
6、去进入的，那么，我们在域名这一端通过一个智能DNS可以做到蓝绿发布这样一些动作，然后通过我们的基础服务来获得基础服务提供的这些服务。这个基础服务旁边是各种的源代码库，还有项目管理库会用去构造不同的服务，去自动化地持续集成到我们实际的服务里去。持续集成模型2、AWS CodeCommit第一步接触到的是AWS的Codecommit，你可以认为它是一个代码管理库，它在整个AWS Devops服务体系中是处于最左边的位置，就是在我们的开发、版本管理这个方向，那么它能够提供一个怎样的东西呢？它其实是一个Git的服务，就像现在大家都会使用Github去管理自己的代码，那么在AWS的Codecommit，
7、它是一个典型AWS微服务的结合，它会用到AWS S3这样的对象储存服务去储存代码实际的部分。因为在这种情况下，相比传统的磁盘，S3会有一个更好的方式去储存一些大文件。作为一个海量的代码库，它对一些大的分区或者大尺寸文件的储存会有更好的优势，而后我们会使用Amazon的NoSQL服务去作为它的元数据管理。这个在Git里面，我们的版本控制、各种分支的控制，都可以在这边去做到，我们也可以通过KMS去加密存在AWS的代码，因为相信对很多公司来说，做好自己源代码的保密性是非常重要的。有了这样一个Git的服务之后，我们就很容易会去构造企业私有化的一些仓库。众所周知，如果我们使用Github的方式去管理，它
8、的私有化仓库是要付费的，那在CodeCommit这样的方式里，我们是可以提供免费的私有化仓库，只需要出少量的储存费用就可以去做，所以这个本身也是一个由亚马逊自身微服务组合而成的一个组合型服务。AWS CodeCommit使用方式对于Git的使用方式，这里就不多说了，我们跟GtiHub的操作方式是一样的，可以通过亚马逊的APL去创建自己的产品库，前后包括分支这些东西，就用传统Git的方式去做，而在最近的一两个星期，我们的Codecommit也加入了类似Github pull这样的方式去管理各种不同的分支，可以让我们不同的团队通过Pull的方式来操作代码。关于Git的提交大家也都很熟悉了，其实可以
9、把Codecommit作为我们最常见的一种方式，因为Git的仓库其实是平行的，所以Codecommit作为我们的远程仓库，它可以跟本地一些分发的仓库平行地去做，可以把需要做云端的Devops的部分作为一个特殊的Commit权限，或者叫Push的权限放到云端去，同时本地还可以维护这样的Git仓库。3、AWS CodePipeline有了这个代码以后，就需要在云端去构造一个Pipeline流程，或者说一个持续集成的流程，我们可以通过CodePipeline这样的可视化工具去调动云端的服务，去进行各种自动化的持续集成工作。AWS CodePipeline管道流程这个持续集成的工作通常包括了好几块，会
10、有代码、构建、各种的Staging，我们需要在不同的Staging里面去做不同的测试，可能我们有些项目里需要一些人工的审批，确定是否去不到我们实体的生产环境里去，这一部分无论是自动化的流程还是人工审批的流程，我们都能可视化地构建在Codepipeline流程里，去让它很完善地流动起来，数据也就可以很好地在这上面去做。这个是CodePipeline界面的截屏，我们可以把Source、Beta阶段、QA阶段通过一个很好的可视化工具去做，相信在座的各位应该用过Jenkins，或者别的一些开源工具，都能够构造出一个很好的Pipeline。在AWS上面，大家可以沿用自己传统的一些使用工具或已经非常熟悉的
11、工具去做，这些都是支持的，包括我们的Codecommit，也会有相应的Jenkins插件去集成。如果是初创企业或者新的研发团队直接使用云端的资源，也可以大大节省学习成本和部署成本。4、AWS CodeBuild有了CodePipeline和CodeCommit以后，我们就有了流程，有了源代码，这时可能就需要一个很重要的编译。编译环境在很多的开发团队或者说在DevOps过程里是非常重要的，很多团队可能会使用Jenkins或者别的一些工具去构造这样的编译流程，但AWS CodeBuild是在具有弹性的云端编译工具和环境中，它会预先帮大家构造好一些成熟、常见的编译环境，比如安卓、Java、Golan
12、g等各种的编译，当然JS不算是一种编译了，但JS的项目通常也需要打包，所以我们就无需重头去建立这样的一个编译环境。AWS CodeBuilde工作流程另外还有个非常重要的事情，在很多已经很成熟的团队里，可能公司内部已经构造了一些很好的编译环境，这些我们也已经搭建了，但没办法避免的一件事就是我们的本地资源是有限的，很有可能在不同的团队下面，我们可能刚好有一个大的发版情况，比如说在双11前我们会集中式地去做一些开发，这时可能同时有好几个团队都在编译，这种情况下，我们的资源就很有可能会不足。但在AWS CodeBuild的过程中，每一个团队去创建一个CodeBuild实例时，它其实都是在云端申请了一
13、段新的资源，这时它的资源永远是不会跟别的团队去竞争的，这个情况可以大大保证我们的开发团队整个开发的过程，而不会因为一些开发流程的竞争而导致实际工作被阻塞，这个是云端一个非常大的好处。我们在云端去构造比如Jenkins这样的环境时，其实也很难去构造一个完全弹性的环境，而CodoBuild里是有一些已经内置好的，当然如果有一些自己的发布情况，也可以把自己打包成一个Docker的镜像，作为一个Customers的Codobuild镜像发布上去。有了CodePipeline、CodeCommit、CodeBuild以后，我们就能在云端很容易地构造一个持续集成的完整链条。我们的代码Commit以后，有一
14、个很常见的开发过程，比如说我们本地有一个开发团队，他们本地可能使用Gitlab建了自己的一个开发的Git仓库，本地仓库进行完一个简单的单元测试以后，它就可以通过这个团队的管理员，比如说他是有权限去把这个代码Push到远端的CodeCommit的仓库，那么这个代码一旦进到Codecommit仓库，后面的流程就完全自动化，CodePipeline会发现Codecommit的一些改动，然后会把这个代码拖下来，启动一个Codebuild的环境进行一个编译，接下来我们还可以持续地结合一些测试的工具进行一个代码测试，步入单元测试，或者说一个QA的测试，而生成的代码我们可以放在S3上面，这样就完成了一个持续
15、集成的过程。AWS 持续集成这是一个在云端很顺畅的过程，当然，即使我的一些客户他们也在云端构建了类似的过程，他们也不一定要使用到亚马逊的服务，最重要一点是，在云端的一些资源，因为都是弹性的，在不适用时，Build服务器其实不会占着我们的使用费用或开机费用，CodePipeline也会在后面默默地等待Codecommit的存储，所以在整个开发的过程中，如果我们很多时候可能都没有动到这一块，它整个过程是没有产生任何费用的，只需稍微给一些代码存储的费用，只有当我们的代码真正进入到远端的分支以后，它才会开始启动AWS云端的服务，去产生这样的一个实际的集成。有了持续集成以后，我们就要进行持续地部署了。相比持续交付，持续部署更多的一个情况在于部署过程中，会把人工化尽可能地减少，逐步地做到完全自动化的部署。持续交付与持续部署的区别5、AWS CodeDeploy我们会有CodeDeploy这样一个服务，CodeDeploy的服务其实是处于AWS整个Devops体系中一个承上启下的作用，它往后会跟我们的CodePipeline去做集成。当CodePipeline做了一个测试以后，它就可以往前去调用我们的各种基础设施，去生成一些真正的生产环境或者说蓝绿测试的环境，去部署我们的软件包在上面，并且调用一些测试的过程
