云上实施基础设施自动化的实践

自我介绍

Who Am I

在阿里云刚刚成立时，就来到了阿里云，相伴7年了。上面这张照片是在中国雅虎关闭的时候，在雅虎的摄影棚里拍了一系列此类的照片。

如果想了解更多的我，可以搜索一下我的名字或者“快的那个会被慢的拖死”。

Purpose

我和我的团队是负责开源生态和开发者服务的，在过去的一年时间里，我们在IaaS层、PaaS层和CNCD都做了一些开源层，Terraform做编排的，ansible和chef是做服务的配置，PaaS层是Flundry，然后CI/CD是Jenkins，目前这一层是以产品的状态存在，它是从代码的提交到线上发布是基于Jenkis之上存在的。

今天我会围绕IaaS层去做讲解，我们的目标是利用成熟的开源工具去实现云上自动化。去年我们做Terraform的时候还没那么火，今年很多大厂都在用，像Chef做其他基础设施和需求的时候也会用，Jenkins部署企业级平台也会利用Terraform做基础设施的编排。后面会结合实际的场景讲一下这些应用与基础设施有什么样的要求，为什么要用这些工具去做程序编排。

如果你是...

如果各位是开发者的话，我想你们也是想以自动化的方式做Ops； 如果你是运维人员，是想拒绝重复劳动，让自己更有价值，告别手工运维；如果你是企业领导，你肯定是想通过DevOps提高运维的效率。

今天的分享主要分三个部分：

1. DevOps的定义
2. 各类应用对基础设施的共性需求
3. 基础设施自动化

DevOps的定义

首先来看看Right Scale的调查报告。这个调查报告每年做一次，这是2016年的。

整个调查报告的人员范围有北美的，有亚洲的，还有其他的一些地方的。

企业的规模有的是1000人以上的，有的是1—100人的，还有100—1000人之间的。

DevOps在呈现上升趋势，2016年比2015年有一定的上升百分比。

右边这个是大企业和小企业采用DevOps的上升比。

很多都是多个配置工具混合使用，使用一个工具的达18%。

DevOps的工资是最高的。

DevOps的定义

什么是DevOps？有人说是敏捷；有人说是开发、运维、测试的墙；还有人说是持续集成、持续部署、持续交付；还有人说是自动化，都对。

那我给DevOps的定义是什么？

• 任何能够提高从需求到发布整个效率的过程或方法都是DevOps的范畴。
• 任何能够提高项目从立项到上线的效率的过程或方法都是DevOps的范畴。

这一过程包括了什么？

可以是从规划到构建到持续集成，到部署、到运营再到持续反馈；也可以是从计划到编码、到验证到打包到发布，到配置，到监控；也可以是从分析到修改、到构建、到测试、到除错，到部署、监控、审计、诊断、调整、反馈。就整个的这些过程，只要能够提高从需求到项目上线的过程和方法，都是DevOps的范畴。

这意味着如果今天你开发了一个东西，能够提高从需求到最后上线的过程，这其实你也是在DevOps的历史当中画上了你自己的一个印迹。

下面来看一下DevOps全生命周期图:

最开始是可以做需求管理的，往下是IDE，再下面一层是可以做仓库的，私建的仓库或者是公共的仓库，然后是用Jenkins和Travis CI做整个Pepline的流传，在这个流程里面可以加入代码检测。再下一层是可以做一些应用的部署，或者是对服务器的配置，中间也可以加入一些测试的东西。最下面的这一层就是为云平台基础设施准备的工具如Terraform和Packer，同时准备测试环境、预发环境、生产环境。

各类应用对基础设施的共性需求

这是刚才我所说的基于Jenkins上做的Pepline的一个产品，先看这个架构的构成，有几部分组成，一个是CodePipelienService下发部署命令，Deploy Service做部署，可以部署到容器或者是其他上面。

下面我分享一下这两个Service对基础设施的需求：

这个是DeployService，大家对阿里云都了解，VPC是做虚拟网络隔离的，它的好处是可以把你的应用放到VPC内和公网隔离，对自己有一个保护。在这个VPC内创建两个子网，子网下面有ECS，安全组保护ECS，安全组上配置了各种规则，这两个ECS上加了负载均衡，这两个ECS都需要有出入网的能力，然后是NAT网关和共享带宽包，负载均衡之上会有健康检查规则，某个端口不通会报警。这就是DeployService所需要的基础设施的东西。

应用对基础设施的目的是准备预发环境、生产环境、测试环境，以方便于部署后提供服务。

针对DeployService有几个需求：

1. 第一个多Region部署，可能一开始在本地没上线的时候，可能只部署了北京的Region，后面为了实现更好的服务，可能要部署到香港的Region，或者是提供国外的服务要部署国外的Region，所以我要多Region部署，大家可以看到每一个点、每一个框都是源自云服务下面的一个服务。

   如果想把这些东西重新布置到另一个Region，整个配置的话耗时长，而且还会忘记了安全组配置了什么，负载均衡配置了什么，这些都会记不住而遗漏的。

2. 安全组规则更新，起到小型防火墙的作用，将不需要的端口屏蔽掉，随着业务的扩展，可能要开端口，这个时候要做安全的更新。

3. ECS数据的变化，流量上来了，就要做ECS的扩容。
4. DNAT规则更新。SNAT是为了出入网，DNAT是为了转发，可能外面的80端口转到内部的8080端口，随着应用不断扩大，会更新一些DNAT的规则。

这个是CodePiPelineService，和上面的环境差不多。不一样的是每台ECS要挂一个EIP，子网1的ECS不用DNAT和SNAT，子网2的ECS不用DNAT。同样的会有多Region的部署更新，安全规则更新，ECS的数量也会变化也包括EIP挂载的更变。

CodePiPelineService在测试的时候，它是一个可以部署到ECS和容器的一个服务，因此在部署到ECS上面的时候，需要频繁创建一台干净的ECS，就是这次部署完了以后，不管是成功还是失败了我都需要重新创建一台干净的ECS。

如果要部署一个PaaS平台的话，传统的IT是什么都没有，什么硬件都没有，然后自己采购。

后来有了云服务，云服务会提供基础的网络存储还有计算。

PaaS平台是除了基础网络存储的能力以外，它还能够提供应用的运行环境，一般大公司采用比较多的是Cloudfoundry。

Cloudfoundry比较复杂，它有很多层，有身份验证的，还有做存储的，还有做服务发现的等等。

Cloudfoundry一开始需要有一个VPC的环境，需要的基础环境就是这个，剩下的都是它的东西。

它的基础环境是什么呢？也是VPC内的一台ECS，可以用Terraform把这个部署起来，然后部署Micro—Bosh。

为什么CloudFoundry可以部署在各个平台上，因为它有CPI的扩展，如果部署在阿里云上，就需要有阿里云CPI的扩展，就能够部署到阿里云的平台上。然后他连接到这台机器上后发命令给它，部署CloudFoundry。

这个是最基础的环境。

分析上面的应用，发现这些应用对基础设施的需求是什么呢？

• 日常应用部署的基础架构创建及更新
• 日常应用的测试环境
• 企业自己部署PaaS平台和SaaS平台所需要的基础设施创建及更新

总结一下，我们发现对基础设施的工作是创建、更新、重复。因此要在基础设施这一层要能自动化一切。

基础设施自动化

这张图是一条可以自动化的解决方案，或者是一条通道。

SourceCode是我们所有的代码，我们通常管它叫模板。

对于Terraform来讲，去定义基础设施，定义基础设施的过程就是对资源编排的过程。之后它会对基础设施进行创建、更新、删除，然后就会使这些独立。

Ansible用来部署应用时的脚本。比如说我在部署CloudFoundry的时候，就会把CloudFoundry所需要的Miro—Bosh和上面的依赖都会用Ansible来做。但是它俩的应用场景不一样，我之前发现大家很多用Ansible做基础设施的更新，这是也可以，但是它更合适的是做应用的部署和对这些云服务的一些一次性更新，不适合去做频繁更新维护的场景，所以作为资源编排的话，Terraform还是一个更好的选择。

Habitat这是去年推出的一个服务，我们都知道容器特别火，它可以一个模板部署在所有容器上和各种虚机上面，可以是阿里云的ECS，可以是IWS的EC2也可以是其他的平台。Habitat中文信息很少，如果一个应用想部署在容器上，又想部署在ECS上面的话，建议大家可以去研究一下这个。

Terraform模板的第一部分是定义资源，Resource这是固定的，后面的是资源名，这个资源名也是固定的，比如说alicloud_security_group，代表阿里云的安全组，后边是一个别名，这个别名是为了让后面引用或者是自己方便记忆的时候做的别名。

定义安全组我可以什么都不写，就是name和description什么都不用写，为了方便写了一个name。

定义安全组规则就可以定义为入网规则和出网规则，然后是ip_protocol、nic_type、policy、port_range等等。刚才说到如果安全组有更新怎么办？就需要另写一条开放20端口的规则，执行的话规则就会更新。

这个就是创建一个ECS典型的实例，首先定义resource，到底我的实例创建在哪个资源下面，然后定义availability_zone在哪个区，security_groups是哪个，vswitch_id是哪个，这台机器的密码password，还有收费类型是按量分配还是包年包月，ECS配置类型、带宽、是否IO优化，它的系统盘和镜像，以及实例的名称。这里我没有写Cont参数，默认是1台。如果再增加一台就改Cont的值，改成2，从1台就变成了2台。

这个和上面的类似，创建SLB实例以及SLB挂载的ECS实例。如果执行的话，就会把这些资源都创建出来。

Terraform最重要的是三条命令：

• 一个是预览
• 一个是执行
• 一个是销毁

预览，就是先看你所有的资源是哪些。执行，就是真正创造这些资源。销毁的时候就是会把所有的资源销毁。

资源更新是怎样做的呢？，在创建的时候，会生成一个Tfstate的文件。执行的时候，先装载TF的模板文件，然后生成Tfstate，同时更新物理资源。执行Apply的时候，第一步会装TF文件，然后读取资源后会和Tfstate文件做对比，最后返回差异。

因此在更新安全组也好，还是更新EC5数量，在改完模板执行Plan的时候就会知道变化在哪里，反馈给你让你确认，如果没有问题的话，去执行真正的模板变化。最后Destroy的时候就会删除。

中间的两个没有讲，这是两个间接应用的命令，这个Import是我现在有一些资源了，之前没有用Terraform管理，但是我现在想把它生成Tfstate文件，然后用这个文件去方便管理我曾经创建的资源，这是Import的功能。Terraform这个工具在国外应用非常多，这也是海外的一个用户给我们提的一个需求，所以我们为他提供了Import的命令。

Refresh的命令是什么呢？一开始大家不太习惯我的变更还要修改模板变更，可能第一次创建完了以后，下一次的变更我可能用其他的方式变更，比如说控制台修改或者是其他EPI的方式做修改，会导致Tfstate的文件和其他的不同步了，所以这个时候用Refresh的命令将他们两个同步。

讲两个实用技巧，这个可能一般人不太知道，首先它有一个DataSource，这是用于做入参过滤的。比如说我现在需要一台ECS，然后Region是华北2，CPU为1核，内存1G的，对应的阿里云实际类型有哪些呢？

对于ECS来讲，刚才我们看到的那个参数要输入实际类型，实际类型的阿里云有几十种，没有人能够记得清是什么，但是你知道你要的资源规格是什么，我要的CPU多少，内存多少。

刚才我们看到资源写的是resource，这里写的是data，后面是一样的，cpu是1核，内存是1G，重点是这output_file，它可以把资源过滤的东西导成一个json文件，这个是Terraform原生没有支持的，我做了拓展，AWS和Azure没有实现，所以这个功能我申请了一个专利。我特别喜欢这个功能，这个需求是我提出来的，因为我不知道实际类型是什么，没有人能记住，这样的话在Plan的时候，一定是在预览的时候就要看出来，我筛选出来的实际类型都有什么，真正创建的时候过滤，然后正好选择data范围的值。这个我们内部很多云架构师在用，他们需要看这个文件，这个文件的好处是通过它看到实际类型是什么，阿里云所有的基础镜像是什么。

这个就是导出来的文件，这个我们谁都记不住。

第二个使用技巧是teraformrc。

现在Terraform官方已经继承了70多个provider，什么叫provider呢？阿里云算一个Provider，AWS也算一个Provider。

每个Provider和官方集成的速度不一样，官方比较慢，这时候我们要设置一些新的Provider，就是最新的和它官方做整合，这样运行它所有命令的时候，就能调用最新的Provider的一些能力。

刚才我们说过Terraform是用作基础设施的，那我有了基础设施以后，给应用提供最基础的测试环境或者是生产环境，因此可能需要我们用Ansible或者Higbat去做应用更新和部署。

TerraformInventory也是开源的工具，它的作用是能够告诉Terraform所有的命令作用在哪些基础设施上，作用在哪些ECS上面，这个是能组合去用的一个方式。

总结

简言之，自动化能自动化的一切。