为什么要选择AWS 来做DevOps？
aws可以提供一套非常灵活的托管服务，专为扩展而设计具有庞大的合作伙伴生态系统，可以集成并扩展aws服务， AWS可以使用自动化功能，让您更加快速、高效地进行构建。利用AWS 服务，您可以将部署、部署与测试工作流、容器管理和配置管理等手动任务和流程自动化。
AWS的Codecommit，它是一个代码管理库，就像我们都会使用Github去管理自己的代码，那么AWS的Codecommit它是一个什么服务呢？Codecommit具有标准的git功能以外，它还会用到S3这样的对象储存服务去储存代码实际的部分。因为在这种情况下，相比传统的磁盘，S3会有一个更好的方式去储存一些大文件。作为一个海量的代码库，它对一些大的分区或者大尺寸文件的储存会有更好的优势，而我们会使用Amazon的NoSQL服务去作为它的元数据管理。这个在Git里面，我们的版本控制、各种分支的控制，都可以在这边去做到，我们也可以通过KMS去加密存在AWS的代码，因为相信对公司来说，做好自己源代码的保密性是非常重要的。
部署完代码以后，就需要一个集成的流程，我们可以通过CodePipeline这样的可视化工具去调动云端服务，去进行自动化的持续集成工作。
图2 AWS CodePipeline管道流程
这个持续集成的工作通常包括代码、构建、各种的Staging，我们需要在不同的Staging里面去做不同的测试，可能我们有些项目里需要一些人工的审批，确定是否部署到我们的生产环境里去，这一部分无论是自动化的流程还是人工审批的流程，我们都能可视化地构建在Codepipeline流程。在AWS上面，可以沿用自己传统的一些使用工具或已经非常熟悉的工具去做，包括我们的Codecommit，也会有相应的Jenkins插件去集成。
我们有了流程，有了代码库，这时可能就需要一个很重要的环节”编译”。编译环节在很多的开发团队或者说在DevOps过程里是非常重要的，很多团队可能会使用Jenkins或者别的一些工具去构造这样的编译流程，但AWS CodeBuild是在具有弹性的云端编译工具和环境中，它会预先帮大家构造好一些成熟、常见的编译环境，比如安卓、Java、Golang等各种的编译，所以我们就无需重头去建立这样的一个编译环境。在有了CodeCommit、CodePipeline、CodeBuild以后，我们就能在云端很容易地构造一个持续集成的完整链条。我们的代码Commit以后，有一个很常见的开发过程，比如说我们本地有一个开发团队，他们本地可能使用Gitlab建了自己的一个开发的Git仓库，本地仓库进行完一个简单的单元测试以后，它就可以通过这个团队的管理员，比如说他是有权限去把这个代码Push到远端的CodeCommit的仓库，那么这个代码一旦进到Codecommit仓库，后面的流程就完全自动化，CodePipeline会发现Codecommit的一些改动，然后会把这个代码pull下来，启动一个Codebuild的环境进行一个编译，接下来我们还可以持续地结合一些测试的工具进行代码测试，单元测试，或者说一个QA的测试，而生成的代码我们可以放在S3上面，这样就完成了一个持续集成的过程。
图3：持续集成
接下来我们就要进行持续地部署了。相比持续交付，持续部署更多的一个情况在于部署过程中，会把人工化尽可能地减少，逐步地做到完全自动化的部署。
持续交付与持续部署有什么区别！
- 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。
图4: 持续交付
持续交付的好处
持续交付和持续集成的优点非常相似：
快速发布。能够应对业务需求，并更快地实现软件价值。编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈;高质量的软件发布标准。整个交付过程标准化、可重复、可靠，整个交付过程进度可视化，方便团队人员了解项目成熟度;更先进的团队协作方式。从需求分析、产品的用户体验到交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
- 持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
图5: 持续部署
- 持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。
部署借助AWS CodeDeploy，可以轻松实现软件部署完全自动化，能够快速且可靠地部署。无论是部署到Amazon EC2、AWS Lambda 还是本地服务器，都可以在开发、测试和生产环境中持续部署应用程序。即使出错，也可以轻松停止和回滚部署。CodeDeploy 还能与现有的持续交付工具（例如GitHub、Jenkins）集成。还有很重要的一点，就是我们可以在云端很好地去调用云端弹性的资源，去构造不同的发布方式。比如在云端我们保证数据的可用性，可以把它变成一次一台的发布、一次一半的发布或者一次全部的发布。
图6：发布部署方式
其实在云端还有一些更好的发布方式，比如说我们原来的业务在生产系统里面本来是有三台机器，然后需要去扩展我们业务或者发布一个新版本时，我们可以在很短的时间内在云端产生一台新的机器，把我们实际的新的版本放到这台新的机器上面去，再通过域名方式或AWS负载兼容器的方式，把一部分的流量往这个地方去发布，这其实就构成了一个蓝绿的发布。
图7: 蓝绿部署
这个蓝绿发布在绿的部分完全是一个新的机器，不会干预到我们实际的生产环境的机器，我们通过这样域名的方式去把一部分的流量引入到绿方的新发布里去，然后通过云端的工具去监控绿方这边的动作。当发现这个绿的部分情况完全没有问题后，我们可以在云端逐步地增加绿这边的流量和它实际的机器数量，最终我们发现在新的版本环境已经完全可以支撑服务了，我们再移步把蓝方这边旧的环境全部给切换掉，把机器也关闭掉，这是一个在云端蓝绿发布非常好的实践。所以，当CodePipeline加上CodeDeploy，我们就可以很好地控制持续部署的流程。在AWS DevOps服务包括部署、搭建、监控、运维等，这都是一些基础设施即代码的服务，这里面包括了我们的Elastic Beanstalk，就是说如果我们的团队仅仅是开发一个PHP的集成环境或Tomcat的集成环境，我们并不需要很复杂的互相访问架构，这时就可以使用Beanstalk；如果是需要描述一些很复杂的互联方关系，可以使用CloudFormation这样一个YAML或者JSON放入描述语言，去快速地构建云端的整个基础设施。
图8：操作AWS服务的三种方式
这是AWS服务的三种服务方式，很多人刚刚接触AWS时，第一个接触到的一定是左手边的Web控制台，Web控制台是很重要的一个用户界面，我们可以在Web控制台上控制大部分的AWS服务，但其实这些Web的控制台上面的每一项功能，后面都会对应着一个API或SDK，然后可以通过我们的开发或命令行去操作这样的DevOps工具，有了这样的基础以后，就能做到各种基础设施即代码的服务。
Elastic Beanstalk。比如一个创业团队项目需要快速的去构建一个环境，会使用一些特定的技术栈，比如使用PHP、MySQL这样的方式。而现在你只需要在Elastic Beanstalk上面选择一个这样的技术栈，一键就能帮你去做出这样一个完整的环境，里面包括了的语言比如PHP，还有底层的一些数据库服务，都会安装好。这样的情况下团队马上就可以投入到开发的工作，而不需要担心各种的基础设施的问题。同时我们的应用部署可以自动扩展，这样的情况下，工程师只需关注代码就可以运行到这样的一个环境。
如果要构造一些更详细的服务，我们可以使用CloudFormation。刚才说到AWS所有的资源，无论大小，它在提供时一定会提供API，而且我们会有SDK，在这个基础上，我们构造了CloudFormation这样一个组建的工具，可以通过JSON或者YAML的方式去描述你在AWS上面任何一项资源。这个资源我们是可以通过变量去控制的，比如说常见的一些生产环境和测试环境，它们绝大部分的结构是一样的，但他们需要的JSON的大小可能不一样，我们可以通过一个JSON文件或YAML文件去备注一下他们的关联关系，然后通过不同的参数去启动不同的环境，一旦这个模块文件产生了改变，我们后台的程序也会自动根据你的模板程序的改进，去改变你们使用的一些资源跟它们的依赖关系。可以这样理解，JSON文件是一个类，它跟模本的程序产生每一个堆栈，这个堆栈就是这个类产生的实例，然后刚刚提到的变量，根据这个变量，这个实例的大小就会不一样。如果你的类改变，它的实例也会跟着做一定的改变。
图10：CloudFormation组件和技术实现
这样的情况下，我们就可以做到整个基础设施平台的模板化，这对于DevOps是非常有用的，也就是说整个基础设施可以非常好地管理起来，比如说可以使用AWS的各种代码管理工具去管理我们的基础设施。
比如下图中的这个服务器，原来只是Application到数据库的，现在要在中间增加一个Redis作为缓存，基础设施的这种改变，可以完全用代码的方式描述起来，并且这个改变也可以被Commit到我们的代码库里，因此我们能够知道这个改变是什么时候产生的，为什么要这样产生，可以很好地去做这样一个动作
图11：基于模板的快速部署
基于这样的模板就可以产生不同的环境，这些环境可以去做不同的改变，然后我们也可以做到不同的生产测试环境与蓝绿部署。
图12：Cloudformation一键部署全站
当业务想往海外发展时，我们可以利用现有积累的经验，很容易快速地部署到10-20个不同的海外区域，如欧洲、美国、中东甚至东南亚这些地方，这些均可通过一个代码、一套代码，去一次部署完整个的服务。
Opsworks可能不太熟悉，其实就是AWS提供的一个托管Chef的工具，它完全跟Chef一样，所以我们就可以利用它在Chef方面的一些经验去控制在AWS上的这些资源。
图13：OpsWorks工作原理
说了这么多的服务我们要怎么监控和管理安全呢？不得不提贯穿始终的安全与监控IAM与CloudWatch
安全是非常重要的，在云端，我们只要用好了服务，其安全性很有可能会比在本地更加安全，刚才我们说到的从代码开始到持续集成、持续发布，再到基础设施即代码，整个部分都是一个过程，最终实现的目的是希望我们的开发人员可以直接去支撑到业务，以上这就是AWS DevOps的内容，框架包括了从开发、构建、部署，搭建、监控、运维的整个范围。