阿里云高级技术专家董孝在云栖TechDay41期带来了云上自动化资源架构和变更实践，本文整理字TechDay41期的沙龙内容。在业务转型互联网+或是+互联网的时代，企业上云已成定局。但上云之后，如何管理云计算基础设施？如何实现云原生架构的交付？
本次以开源技术工具Terraform、Packer、Jenkins、Docker为例，分享一个Multi-Cloud下的基础设施和应用自动化管理方案。
为什么上云？
从技术人员的角度来说，上云的因素包括价格、基础设施启动和运行时间、云上具有良好的扩展性、云上具有更好的安全性。
钱从自己家里放到银行一开始也需要建立 一个信任的过程，需要相应法律法规的完善，这样大家才慢慢放心把钱从家里放到银行。而上云同样需要一个过程，大家一开始可能对敏感信息放到云上是有担心的，一方面是技术上的问题，网速不够快，想访问的时候访问不了，一方面法律法规不健全，可能会导致我们的信息泄露。但是随着技术进步和相应法律法规的完善，云一定会像银行一样成为社会的基础设施。
传统模式下上线新业务基础设施准备引发我们的思考，我们需要准备哪一些？我们要进行容量规划，在容量规划方面我们不能只考虑现在，如果业务发展很快的话，还要规划扩容的准备，还要规划测试用多少，应用用多少，服务要有多少，这是一个很困难的过程；容量规划做完了，还要报采购计划，还要准备机房、布置网络等等，还要安装软硬件，准备相应的应用的构建部署工具；在开发应用上线之前，也要应对开发和测试运营之间因为环境一致性引发的各种争论，比如开发人员说软件已经开发好了，结果测试人员说在我的环境下就是运行不好，然后检查发现是因为测试用的是重复的环境，不是一个干净环境，结果造成了数据污染，造成了自己应用在测试的环境下跑不起来，这是环境引发的。在一个传统的环境下我们会遇到各种各样的问题，等到我们把这些问题都解决了，应用上线了，可能几周甚至几个月过去了，有时候可能商机就丧失了。
这些问题都解决后，如果说业务增长迅速需要扩容，或者说我们需要在新的地域来开展我们的业务，那么所有过程又需要重新来一遍，而且这一部分基础设施准备在传统的环境下是不可避免的，流程难以自动化。
DevOps和基础设施自动化
据数据统计，在2015年DevOps的被采纳率是66%，而到了2016年就达到了74%，在这短短的一年间增加了8%，对于现在的企业来说，是否采用DevOps，使用得好不好，不仅仅是企业运行的好坏问题，而是生与死的问题。
什么是DevOps？有人说采用敏捷开发，追求最小的可交付价值，快速的开发敏捷是Dev Ops；也有人说建立良好的监控体系能够自动迅速的反馈提高交付质量就是DevOps；也或者是建立良好的组织和文化，建立企业之间各个部门之间相互良好的沟通方式，以快速交付软件的价值为目的，就是DevOps；还有说DevOps就是打破开发和运营之间的壁垒。那么这些是DevOps吗？
依我看来，DevOps是能够加速从需求收到最后应用和服务交付的一切流程和方法。只有我们采用敏捷的方法，始终追求一个目标，然后建立快速的监控和反馈体系，来提高我们交付的质量，建立企业之间各个部门之间沟通信任的交流环境，以最快的交付服务应用为目的的企业文化，然后基于自动化的工具和服务作为基础来实现目标的快速交付，只有这几个部分有机的组合，才能取得DevOps最大效益。
云上DevOps有哪些优势呢？主要有以下三点：
功能强大
它能够覆盖DevOps整个环节，从提交代码到最后运营监控的整个环节。
我们来看一看在“IaaS”层可以使用Terraform、ROS、ANSIBLE、CHEF和Parker，在传统中我们的基础设施是用配管等等之类的工具来维护的，存在信息更新等等方式的问题，而且使用起来也比较麻烦，而使用IaaS到模式的话，我们创建基础设施也像创建代码一样，比如说我们要创建一个VPC集群，里面要包含哪些机器，要配置一个什么样的网络，怎么样设计安全组规则，在传统模式下需要人去操作，然后通过配管工具来记录的。
而我们首先像写代码一样写出我们的这些需求，写出我们的模板然后直接应用，会在云上创建出各种资源，而且它也会把这些创建资源的结果记录到状态文件里面，我们就知道当前有哪一些文件，哪一些资源，而且在创建资源的时候，有的时候需要维护一个状态，假设我们需要六台虚拟机，如果已经有了三台虚拟机，使用传统模式我们相对要创建三台，而在IaC模式下，使用Terraform模板的话，我们就只需要指定需要六台虚拟机，它就会在云上看当前有多少台，然后产生新的三台，如果到了六台发现业务量下降了，我们只需要两台，那我们就写最终目的是两台，我们不用去计算我们现在有六台，我们要达到两台的目的我们还要减少四台，我们只需要写最终要保留两台，那么它就会自动给我们销毁另外的四台。这样就避免了我们在写代码脚本维护时容易发生的各种错误。而像ANSIBLE、CHEF这些都是大家常用的运维工具，现在在云上也提供了相应的功能，而ROS是阿里提供的跟Terraform相对应的专有产品，能够自动化的一键创建我们的基础设施。Packer是一个创建镜像的IaC工具。
如果大家对于基础设施这一块创建好之后，那么有的企业不关心怎么样去使用基础设施，这个时候我们就可以选择PaaS平台，使用couldfundry，或者说我们使用容器服务来发布我们的应用，用像ContainerService这种。那么当Paas平台都准备好了之后，我的代码怎么样能快速发布到云上？这个时候就有我们的产品CodePipeline可以直接提交代码，然后自动构建，按照我们的指令部署到ContainerService或者我们的ECS上，在这一块CodePipeline在阿里云也提供。这些工具怎么样来支撑完成DevOps的完整流程呢？
从一个Develop提交代码到Github里面去，这个时候webhook就会通知CI Server有代码变化了，你需要去构建。那么CIServer就会从Git上拉起代码，按照事先的指令进行构建，如果构建的过程中发生了错误，它就会通知开发者有错误需要去修正。如果成功之后，对于喜欢使用新技术的人，可能会把构建完的构建物打包成Docker镜像push到Docker Registry里面去，然后进行测试和产品环境的部署，从Docker Registry上pull它的镜像，在各个环节上进行分发。
对于一些企业来说，他们不习惯采用Docker，或者应用已经采用传统物理机，这个时候我们可以将构建物上传到OSS里面去，然后我们的CDServer会将我们的部署物按照我们指定的指令部署到相应的ECS上，或者是物理机上。
在这个过程中，CI、CD我们可以采用Codepipeline来实现，而容器的发布运行环境可以使用容器服务。当我们部署到ECS上的时候，Terraform能够帮助我们快速的一键生成我们所需要的环境。
灵活性&适应性
我们可以*的选择开源工具和专有的产品，现在广泛使用的DevOps和服务都是支持多云平台的。
灵活性构成的工具里面既有我们自己提供的产品，像ROS、ContainerService、Codepipeline，也有众多的开源产品，是不是我们使用了专有产品就被阿里云绑定了呢？不是的，因为好的服务，其实各个云平台场上都提供了。比如ROS功能在AWS是由CloudFormation来提供的，而ContainerService在AWS也提供了ECS，所以我们采用这些工具并不会被某一云平台锁定，而对于开源部分更是天生就是跨云平台支持的，所以它有良好的适应性，我们并不担心使用这些工具会让我们绑定在某一平台上。
关于Terraform
Terraform是什么呢？
Terraform是一个开源的基础设施编排工具。
- 它具备广泛的产品支持。Terraform集成了所有主要的阿里巴巴云服务，能够覆盖90%的需求，在AWS上Terraform更是比较成熟的，基本上所有AWS的服务Terraform都支持，而且谷歌某一项产品要提供云的支持，这个产品如果不支持Terraform是不准发布的。
- 我们也提供了丰富的示例。大家可能对Terraform不是很熟，也不知道怎么样去编写Terraform的模板，这不是问题，因为我们在开源仓库里面已经针对我们每一个提供的资源都提供了示例，总计有大于30以上的模板。
- Terraform是多云支持的，能够很方便的管理阿里云、AWS、AZure等主流云平台的基础设施。使用Terraform一键打通了阿里云所有的主流产品，使用Terraform能很方便的管理阿里云上的所有主流资源。‘
我们要创建一个VPC集群，我们有哪一些服务呢？我们有ECS服务，我们要创建两台ECS，要在不断的子网中间有统一的安全组，然后设计了通过NET网管进行对外访问，有SNET、DNET来提供网络访问，同时SLB提供负载均衡的服务，health check来检查SLB的健康状况。
大家在使用页面的时候，如果一个两个资源大家都会觉得很简单，按几个button就创建完了，但如果创建一个复杂的环境，使用Terraform可能编写一个模板，然后使用一个简单的命令，这样一个集群就创建好了。如果你需要创建一个新的，只要再执行一次命令就可以重建集群，如果我觉得这个集群现在不用了，Terrafor执行destroy命令，那么整个集群就被销毁了，所有的资源都被释放了，这是很方便的，而且我可以很方便的去查有哪一些资源，从它生成的状态文件里面，我就可以很方便的查到，可以创建哪一些资源组，有哪一些ECS，网络的IP是什么等等，所有的集群信息都在这个状态文件里面。
在我们仓库里面，已经对常用场景提供了模板，大家只要拿下来复制，简单的去修修改改就可以满足你的日常需求了。这样就把我们一个很复杂的基础设计创建过程变成一个简单的命令执行过程。
如果访问一系列服务的时候，我们很关心密码怎么样，比如说我现在作为阿里云上的一个ECS里面的APP，我要访问OSS，在以前我是需要在应用里面放上我访问ECS的AKD的，这是一个不安全的行为，因为如果突破了ECS，那么就有可能会获取到AKD，而现在通过RAM，我们在创建ECS的时候，把相应的RAMROLE绑定到相应的ECS上，那么从这台ECS上去访问我们指定的ECS时候，我们的应用就不需要OSS的密码了，这台机器绑定相应的Role也可以通过一个Terraform的模板完成。
容器服务
使用Terraform能够方便的帮助我们一键创建整个基础设施，而且这种创建是可以重用的，比如说我在北京Region创建的基础设施，然后我的业务扩大了，到海外或者其他的省份创建这种基础设施的话，我们只需要修改Region名字然后pipeline，就可以快速一键复制我们的整个基础设施。而我们的容器服务提供了服务编排，服务发现，自动伸缩，失败调度等等功能，它是无缝的阿里云服务支持，降低客户创建和使用服务的成本。我也可以简单的自己搭建一个容器集群，但是要达到一个生产级的容器服务，然后方便使用相关的各种各样技术还是有一定的门槛的，而容器服务能降低这种门槛。我们自己的CodePipeline里面也使用了我们自己创建的容器服务，在我们build的时候，我们的CodePipeline是一个SaaS服务，怎么样能最大化的实现在构建时候的资源共享？
这个时候我们使用了自己的Container服务来根据需要来动态分配资源完成构建任务，构建结束后，而如果我们要部署到容器也就可以部署到ContainerServers，也可以部署到ECS，我们自己在创建CodePipeline产品的时候，我们的基础设备准备也是为使用Terraform模板来准备的，这样当我们要国际化的时候我们可以很方便的使用Terraform模板来复制我们的基础结构，同时对于部署到ECS的时候，我们可以用Terraform、ROS来创建测试Staging production所需要的各种各样环境。
在CodePipeline服务中，我们的构建是运行在容器中间的，当然容器构建完成的时候，我们就会释放资源，供其他的JOB来使用。
总结
那么以下问题怎么样来解决呢？
- 通过云服务实现容量规划：因为在云上我们可以快速以分钟级创建资源，并不需要过多的考虑怎么样扩容。我们是按需来规划，我们当前需要多少就规划多少，那么就把一个拍脑袋来规划容量的事情变成当前可及的事情。
- 云产品的采购计划也相对简单，不需要准备机房、布置网络、安装软硬件这些工作，如果我们采用Packer的模板来创建基础设施，也可以一键来准备这些东西，将一个几小时或者几周时间变成分钟级的任务。
- 如果采用CodePipeline等类似的SaaS服务，我们也不需要准备应用的构建和部署工具。因为我们可以很方便的去派生一套新的环境，如果我们需要一套干净的环境时候，我们就可以很快在分钟级来创建这些资源。不用应对开发和测试运营之间因为环境一致性引发的各种争论，业务如果要增长要扩容，对于云上也是Terraform一个简单的命令能完成的事情，所以在云上基础设施自动化DevOps，解决了对于线下来说非常难以解决的基础设施自动化的问题。让DevOps变得更简单、更方便。
- 云上DevOps工具提供了覆盖DevOps的整个环节，从代码的提交到应用发布的整个生命流程，我们可以有灵活的选择开源工具和专业的产品。我们不仅仅能在同一供应商之间选择，也可以在多个云平台厂商之间进行选择。