基于 ANSIBLE 自动化运维实践
讲师：张虎（云巴CEO）
张虎：各位早上好，刚刚老许讲的非常精彩，差点就要干起来了，刚才有一个爱立信的朋友。接下来我讲一个比较痛苦的话题，我先做一下自我介绍，我叫张虎，算是一个连续创业者。听到这个警报跟大家分享一个事情，昨天在南京发现要做公祭发了一个微博，第一次听到防空警报是在1997年当时我在南航上大学，听到这个警报那天我正在研究C语言，特别是今天在这里跟大家做很有技术的分享听到这个防空警报非常有感触，17年过去了，一个年轻的小伙子长大了。
我现在是云巴的创始人和CEO，之前是极光推送的创始人和前CTO，现场应该有极光推送的用户，下面是我的微博，如果有兴趣的话可以加我的微博和我做其他的交流。我今天要讲的话题是一个很痛苦的话题，就是所谓的运维，你做任何的产品都离不开这个非常痛苦的东西，但是这个痛苦的东西往往决定了你产品，不管你用什么语言、什么平台、什么技术，真正能够决定你产品成熟度的很有可能就是你运维的能力。
我简单介绍一下我们云巴是做什么的，我们宣传的口号叫云后端服务，就是我下面写的MQTT as a Service，当然这个我们做过一些很小的修改，但是基本上跟原来的MQTT是一致的，可以说是一个实时的发布／订阅系统。它面向的场景简单的说是跨平台的实时信息交换的服务，它可以面向应用也可以面向智能硬件，今天要讲的主题不是这个，我只是大概带一下，让大家了解一下我们在做什么。
我其实特别想从云时代的运维这个概念开始切入，我们可以想想云时代跟我们以前的时代有什么不一样，为什么以前的运维那么痛苦？大家好像也没有说一定要去改变这个现
精品文档
精品文档
状，或者说做多大的努力去改变这个现状，为什么？因为原来的时代比云时代痛苦太多了，因为原来不管你做什么你都要自己去建机房、自己去采购、去调研机房、采购服务器、采购带宽，中间出了任何问题我们首先去骂机房的人就OK了，跟老板说机房那边有太多问题了。基本上你找机房的问题肯定能找到问题，所以老板也不会说你运维怎么做的那么烂、我们用什么办法去改进，大部分的时间就是在机房和你们自己的运维团队之间做一些很低水平的骂战，可能不是真的是骂战，至少是大家互相在较劲。
在云时代这个事情应该会有很大的变化，在几年前这个事情就已经在变化了。在AWS出现之后，很多美国或者是国外的团队他们的运维方式，实际上是有极大的变化。我今天想从这个话题开始切入，为什么云时代的运维跟原来那个时代的运维不一样。首先是从云主机，大家可以看云主机的出现把你以前跟机房有模糊地带的争议话题全部都抹平了，实际上你有一个供应商他专门提供云主机的服务，可能会被上亿的用户验证过他的服务，他的服务其实很简单，他是提供了服务的模型让你做一些基本的监控，给你提供一个入口去部署你的服务。基本上来说，如果说一个云主机的服务商一大半的用户使用情况都是很稳定的，基本上你到上面用你碰到不稳定的概率是比较低的。其实它的可靠性是比你去找一个不知道从哪里找来的机房、一个带宽的供应商要好。也就是说一个专业的云主机服务提供商，他们能够更专业的去解决你原来基础设施的问题。你不会再面临那么多很痛苦的问题了，它还有一些本质的转变，你原来可能去建一个机房去部署，可能整个过程是以几个星期甚至是一两个月的时间来计算。现在所谓的云主机时代，就是所谓弹性运算的时代。可能你点击一个按纽就能申请到一台机器，或者是你运行他的API就能拿到一台机器，在两分钟之内就能完成整个申请、测试应用甚至上线的过程。你可以想想以前需要几个月完成的事情，现在实际上可以在调用一个API的时间就可以完成。
我个人感觉，是因为这些基础设施的变化造成了所谓云时代的运维跟原来的运维有本质的区别。原来你做的其实是很烂的事情，大家也不会太在意，因为就算哪个环节做的不
精品文档
精品文档
好，你的老板也感觉不到，我们可以这么说。实际上它带来的变化就是我们所谓的弹性运算，你的基础设施是一个弹性运算之后，实际上你所有的服务我个人感觉都可以变成一个所谓的弹性运算。具体弹性运算我后面会详细讲，我先列出来了一个点就是弹性扩容，我们现在的容量基本上你做一个云服务，你的容量只需要做一个最小的容量。到你的用户在增长的时候，你再去扩容。我们这边有一个京东的朋友，原来采购机器是300台，但是如果你是一个小团队，你提供一个简单服务的话，如果一开始采购机器就用这种规模去采购，我相信你去采购机器的投资你就拿不到，所以在云主机上面的做法是很不一样的。然后所谓的灰度上线，原先就是你的前置条件会很长，你会跟老板说我们这个没法做或者是要做几个月，但是现在因为你前置条件的成本非常低。我们几乎每做完一个小的特性马上就去做灰度上线，因为灰度上线的时间越早、你发现问题的时间点也会越早，你这个系统稳定的时间也会越短。因为这些原因，扩容、灰度上线，实际上它是一个开发的过程，我们可能每天都要面临部署，就是调整你的部署。你整个集群的部署每天都会做一些微调，这是我刚刚说一些问题里面有典型的场景，像增加一个新的机房在早期几乎是不敢想象的，你可能把公司最大几个老板叫在一起讨论这个问题说怎么去增加一个新的机房，但是在现在这个年代，我觉得会越来越轻量。
你将来会面临新增加一个机房，可能以前我觉得这个事情要规划非常久，但是以后你可能会经常做这样的事情，特别是现在云主机服务商群雄并起的时候。你不能说没有做过验证就去用，你要去验证的话肯定要去部署一整套的东西，在上面跑一些测试用户你才敢去用，这种情况下你就相当于增加一个机房去跑一些测试用户。新增加一个机房的成本其实也是很低的，还有就是我刚刚说的扩容，我把扩容的过程简单的列了一下。申请机器、配置DNS、部署应用、部署监控、自动测试、分配流量，这个过程我个人感觉，就像我念这么长的过程，实际上在我们现在做的自动化运维里面就是一个脚本，整个过程我们一般扩容就是3台到5台，可能我们是小粒度的方式扩容。3台到5台的整个过程就是20多分钟就可以完成，实际上你也可以认为所谓的扩容就是一个灰度上线或者是灰度测试。
精品文档
精品文档
可能说今天完成一个特性就会去做所谓的扩容，他刚开始是一个灰度上线，上线成功之后就会把它真正切到生产的流量就会变成扩容，我就会把以前老版本的流量或者是容量给它下掉，那就是这样一个过程。
我刚刚提过所谓的弹性运算，我理解的弹性运算主要是两点，刚刚我已经提到过一回就是需要的时候才分配。这个是现在基础设施的变化给我们带来的便利，需要的时候才分配。另外还有一个很重要的点就是分配过程很廉价，这是什么概念呢？我刚刚讲了一大串就是想说分配过程成本非常的高昂需要有很多的前置条件，但是现在的分配过程很廉价，就是你运行一个API，调用他们的一个API接口你的整个分配过程就完成了，包括主机的分配、流量的分配、IP的绑定、域名解析的配置这些过程，或者说你可能还买了其他的服务，比如说你有存储服务、load balancer，实际上整个过程都是非常的廉价。这边我想说一下，其实国内的云主机运用商现在做到这么好应该还没有，我有一些是根据AWS他们的服务来，其实我最早用的服务是AWS，但是现在国内的云主机服务商真的做到那么成体系、配套、完整的应该还是没有的。有一些已经有API了，但是跟周边一些自动部署模块的整合做的不够好，但是他们投几十个亿连这点都想不到那钱肯定就打水漂了。所谓的分配过程很廉价，就是刚才说的弹性、扩容、灰度这些东西就会非常的方便，这两个加在一起我觉得就形成了所谓的弹性预算最重要的点。
我下了一个结论，就是说没有自动运维就没有弹性运算，我刚刚讲了那么多这得就是我得出来的结论。所谓的弹性运算，我刚刚说用户随时在线扩容这个跟我刚才说的有一些不一样，不一样在哪里呢？我刚刚都是以运维者的角度，或者是以产品服务提供者的角度来讲这个问题，还有一个是所谓用户随时在线扩容。我们服务的目标用户，最早用户量非常少只是做验证没有付费，用户量越来越多发现我的延迟变大了，我们会有一些监控数据给他，说你每天的在线用户很多、每天交互次数很多，现在的通道不足以支撑你那么多的用户，你的通道可能需要去扩展。以前的做法是打电话给商务说再多交一点钱，你们再给
精品文档
精品文档
我多开一台服务器就变快了。我觉得那个还是传统服务，所谓的云服务就应该是纯自助的。我发现我的通道不够用了我就去申请，我发现我主要的用户是在上海、南京，或者说我主要的用户是在西藏、西安，我可能就需要去根据我的情况在不同的地方去扩张我的通道。这个事情应该是用户自己去做，但是他需要我们去帮助他，那我们帮助他的办法是什么？实际上很简单，我们会看到哪里有资源、哪里缺资源，实际上买资源的过程就是所谓自动扩容的过程。自动扩容的过程不是由运维来驱动而是由我们的目标用户，我的目标用户就是使用我们服务的开发者来驱动这个过程。
我一直在想一个事情，就是所谓的自动扩容，这是以运维的角度来看这个问题。我们会通过监控系统每天去看我们各个模块、各个组件的情况，然后看他到一定的基准线之后，以前的做法是说来一个机房压力很大超过水位线了我们需要人工去干预，但是我觉得各个环节的成熟度到一定程度之后实际上不需要人工去干预。我举个例子，假设我做一个配置，就是说我每天是晚上12点到早上8点中间，如果是哪一部分东西容量出问题了，我们就启动一个自动的扩容过程。可能后半夜就算你每天有运维人员去盯着，后半夜的工作能力是很弱的，大家都很累这很正常。我觉得很多运维做的事情都可以被标准化，尤其是像扩容这种事情，我觉得很多事情可以简单的通过扩容让他撑过很长的时间。不管你中间运维程序写的不好、代码不好，甚至因为你选的Erlang
没有用 Go的原因，我不管你什么原因，只要把那条路加宽就可以让车全部通起来，不管你是因为哪个模块的原因造成的。原来做过一个个事情就是我们系统突然出现瓶颈，然后会超时、丢包，我就感觉有一个集群的压力很大，我做了一个很简单的事情，就是我把它的容量扩充了一次，比如说原来是20台机很短的时间把它扩成40台机，我发现它的压力马上就下去了。我就跟团队人说就是这个模块里面有瓶颈，我们没有去看日志、没有去抓包什么都没看。就是发现他的入口数据一直在增长、出口的数据没有变，他调用依赖模块的请求数量没有增加，入口一直在堆积、出口上不去，就说明他这个管子太细了。
精品文档
精品文档
我一直有一个理念，所谓的云计算跟原来特别是企业服务不一样的地方是什么呢？企业服务出现了问题立马停下来，但是云服务是不行的，现在可能有成千上万的用户正在用你的服务，你现在停一分钟就会有人开始骂人了，你的电话、你的QQ群、你的邮箱都会爆满，所谓的云时代就是离线的去找问题在哪里。我们将来想做的事情就是说，我们把任何模块的出入口都去做很详细的监控，每一次请求甚至是每一个协议包都做监控，我们会找出一些范式，就是说应该进去多少、出去多少，出去哪些到模块A、哪些到模块B、哪些到模块C，我们做一些预测。一旦我们发现哪个模块有压力可以马上给它做自动扩容。这里面就像我刚刚说的，不简单是因为容量的问题，它有可能是因为你程序有BUG，不管是因为什么原因我们先让它通起来，就算你的程序有BUG但是每秒到200次是没问题的，现在马上就让它降到一个点这个服务就会通下去，这是我一直在构思的事情。我们后面也会在这方面投入很大的精力，下次我希望不是我在这分享，因为分享运维其实挺无聊的说实话。
这边实际上又回头来说这个事情，我们以前开发团队的分工是什么呢？就是写代码的人写代码、测试的人测试、运维的人去敲各种命令去部署，这里面有一个很有趣的悖论，其实写代码的人比测试的人更清楚这个东西要怎么去测试，写代码的人比运维的人更清楚这个应该怎么去配置和部署。实际上我们有过惨痛的教训，以前做极光推送的时候，我们做一次升级一般来说我们会怎么做呢？我会在办公室放两个很大的白板，我会准备出3支笔，黑色、蓝色和红色，把开发人员、运维人员、测试人员全部叫在一起，你把写东西的要叫过来、测东西的要过来，运维肯定也要叫过来，我们就相当于是写一个很复杂的作战地图。可能这一次迁移涉及到9个模块，就把9个模块全部画出来，那个过程有点像话剧的脚本。就是我先说A你要先做什么事情，做完之后你要运行什么确认之后通知B同时要告诉我，B要干什么事情，B干完之后也要告诉我通知下一个C，然后你要干什么事情，可能有一个事情需要我们几个人同时做。我相信大家应该很明白，这个人做了之后那个人应该在几秒钟之后完成另外的动作，要不然我们就会出问题，这样的事情我们每个月
精品文档
精品文档
会做一次，基本上是凌晨2点才敢去做这个事情，大家先各种打游戏然后玩到2点，吃点东西以后开始，基本上要干到早上5点钟左右，还要盯到早上8点大家回去睡觉，基本上都是这样的过程。其实做这个过程的时候我就很痛苦，每次运维要问我们说，这个东西到底怎么配置、配置文件到底在哪里、每个项目是什么意思，就各种问题都有了，最后发现你去强求每一个人写文档，其实它也是一个现实的考量。因为一个是程序员写出来文档真的是很烂，大家应该都知道。我们所有的文档写完之后我都要去重写，实际上写文档的门槛比写代码的门槛要高。
写文档的代价很高，所以它的时间成本是很高的，大部分的情况下大家没有写出很好的文档，就算你写出很好的文档运维和测试去看的时候也需要要花很大的时间代价，这三个角色之间沟通的成本非常高，沟通的效果也是非常差的。后面我们要怎么去解决这个问题呢？后面就出现了所谓的Devops，就是让运营来参与开发。实际上我们的做法是什么呢？就是没有测试和运维，所有的事情都是由开发来做，因为只有你清楚，但是我们有一点不一样的地方是什么呢？可能大家的分工会有一点交叉，我们可能5个人写一个模块，这个模块可能又被分成5个小模块，可能是做特性A的人可能做了特性A的30%测试，测试用例的代码和部署的代码。做特性B的人做70%的特性A测试和一部分特性A的部署，这样大家可以互相交叉。
你在写测试和部署程序的时候，你实际上对那个东西的理解可能比写代码的人更深刻。因为写代码说实话，在整个产品开发里面写代码是最简单的事情，一个好的产品就像我刚刚一开场说的，你写的东西大概只能占30%，还有其他的东西可能要占到70%，我开场说一个好的产品可能是用你运维水平来决定的，而不是由你写代码的水平来决定的。实际上在测试代码和运维，或者说我们部署脚本的代码量有可能是远远超过特性的代码，你可能随便写一个代码我们会造成一大片测试脚本调整和运维脚本的调整、部署调整的脚本，这个实际上不是我们首创的，这种做法在国外一些团队他们好几年前就开始实践了。他们
精品文档
精品文档
是没有测试也没有运维，所有的人又是开发、又是运维、又是测试。我们现在团队的成员，除了写好你的特性以外他们有很大的工作量会去写测试用例、写部署脚本。现在我们招人的时候会招全栈工程师，因为你在写测试脚本的时候、你在写部署脚本的时候你会反过来反思你原来写的东西。因为以前我们在这个年代的时候经常会碰到一个问题，运维的人会跑来抱怨说你这个程序怎么写的、这个配置怎么这么复杂，根本就不知道你在搞什么，然后测试的也会跟你说你的接口怎么定义的？我完全看不懂，我怎么写你的测试用例？在这个年代的时候，他们在写测试脚本、在写部署脚本的时候，他们就会去自己反思，你原来写的那个是不是很合理、是不是考虑到以后这个怎么维护。你去做过部署、做过运维你就知道了，其实热逻辑切换是多么的重要，反过来你在写特性的时候你就去考虑这些问题，你在写代码的阶段你要考虑你将来怎么去做测试、你将来怎么去做部署，这样反过来又可以提高你编码过程的质量。
我所谓理想的部署方式，其实早期有很多部署的工具，什么Puppet，我看了他的文档就很头疼我不太想用，以前有我们团队的同事研究过很传统部署的工具和系统，我觉得他们有一个很大的悖论在哪里呢？他们实际上是用一套集群或者是用一套已经部署好的东西，在去管理另外一些没有部署好的东西，这就有一个鸡生蛋和蛋生鸡的问题，就是你本身的部署应该怎么做。我用过 Puppet但是没有仔细的研究过它，Puppet本身的集群你怎么去做？原来的做法是运维把机器弄好了、把所有的机器都装好、配置全都配好，最后发现这个过程成本非常的高。我个人比较喜欢的做法就是我今天讲的主体，新机器只需要支持SSH，这实际上是一个非常廉价的事情，所有新主机标准的做法就是申请好了之后，真正做的好的就是你可能会有一些部署机器，把key导到你的部署机器上去，你调用一个API主机申请好了就可以马上带上去，你也用sudo权限做什么事情都可以做。我这里所谓配置新机的方式其实都已经不用配置了，好多都是申请好了就已经好了。大家可以想想这和Puppet一类的部署系统比照一下，它的成本是不是会更低，它是没有一个所谓中期的Master，只要在这台机器上可以连上你的目标机就可以了。
精品文档
精品文档
这是我今天要说的所谓的Ansible，我简单跟大家讲讲找到Ansible的过程。我们最早也是用SSH自己写很多脚本，然后比如说我们要用SSH连过去，也是在某一台机器上执行，不用在目标机上登陆，其实很简单，大家都知道SSH去执行一个什么命令就可以部署，这种做法在相当一段时间内是我们实际使用的手段，它实际上我个人感觉比Puppet还有效，但是它有一些问题，就是它的管理成本很高、你的脚本会越来越多，大家都在做类似的事情。你部署的过程是有很多的基础部件是需要你反复去部署的，脚本太多了之后几乎是没法管理，后来我们用了RunDeck的东西，它是有界面的、有一定的管理能力，我们还用过Fabric，就是你批量执行一些命令，他能做到类似部署的事情，但是，比如说目标机规模大了之后各种管理的能力是不够的。后来我们又调研过一些 Salt，我们调研完之后觉得没有什么太大的差别，我们当时用Ansible是觉得相关的支持非常的多，其实很多现有的组件和模块，并且有很多开源的Ansible部署和脚本。我们的团队里面有一个理念，我们不喜欢去纠结，比如说我们发现这个Ansible没有太本质的区别，我们就选一个开始用起来。用起来之后发现很难做我们再去研究别的东西，基本上我们的做法都是这样子的。你现在没有很明确的理由说服自己在两个或者是3个中间选一个的时候我们就凭感觉选一个用起来会怎么样，所以我们就从Ansible开使用起。它是通过SSH连接到目标服务器，上面这两个东西是我想了很久，我希望去拥有的特性。一个是完整的集群，你只需要有一个inventory去定义就可以了，你写出这个清单你的集群就被定义好了。具体的每一个角色要做什么，它会有若干的playbooks来定义你的角色具体要做什么，它这里面做了一些更有趣的东西，我等一会儿可以跟大家讲一讲。
这是一个Inventory的例子，这是虚拟的不是我们真实生产商用的。这定义了两个角色，一个是web-group，一个是db-gorup，这个格式看起来也是非常容易理解的。所谓的Playbook有一个更详细的案例会给大家看，因为我们用的是Ubuntu 12.04，所以我们先用一个Nginx的PPA，Ansible的开发过程是做什么呢？其实就是写一大堆Playbooks，有一个点是什么呢？你会发现有一些模块可能现在没有，什么意思呢？你有
精品文档
精品文档
很多东西需要写的话，不是说你写出来的东西效率低而是你整个团队的效率低，你会发现很多人都依赖于这个东西就要去写脚本这个很麻烦。你会发现你的Playbook最后变得非常简洁，实际上大部分的时间你都是在写Playbooks，我列了一些Ansible的支持，我昨天晚上看了一下它现在支持的有251个模块，把其中一些我觉得比较有趣的拿出来一看，特别是对于云服务的支持。像AWS、Docker、Rackspace、OpenStack，其实它的部署脚本都放在一个子目录下。也就是说你要去把别人写的脚本拿过来，或者是把别人写定义的Playbook拿过来非常容易，你可以根据他的手册，实际上你只是执行了命令你只要写一个脚本让他按照你写的顺序去执行命令就可以了，像数据库这些甚至支持了监控的模块，都可以支持。另外还有一个比较有趣的是，大家可以看一下有很多开源的脚本，我记得我大半年前跟我团队做过一次分享，那个时候我说了一下，有3000多个项目是提到过Ansible的。我相信它会越来越多，因为它的分享方式真的是很简单，就是像我刚刚说的一个目录下，你只要把目录拷过去你就会有这些能力。
这是我们其中一个机房部署的机器（图），我个人比较喜欢的做法是我会给每个机器都Hostname，我们每增加一台机器的时候我们会跑若干的脚本，其中就包括去修改跟他在一个主网内的所谓Hosts文件，这里面没有一个IP。这边我要讲一讲，比较有趣的地方比如说我这边有一个nogic，因为我要考虑到负载均衡的问题，每一台机器上配的配置项不一样，那你后面就可以带一些参数去给他指定不同的配置项，如果没有指定的话可以写一些脚本。
我给大家看一下我们几乎每天都要执行的命令，就是所谓的ansible-playbook，我们可以看一下playbook的内容。我定义了一些角色，这边我所有的机器都要去运行common，我们把一些基础的模块都刷一遍，每次运行的时候都装一遍个，避免造成他的依赖不一致。这是一个最上层的playbook，因为我的Roles又会引用另外一个Roles，我们把playbook也分了几级这样可以看的很清楚，我装redis的时候他就只去依赖于这
精品文档
精品文档
个，这边有一个Emqtt实际上以来于三个小的Roles，一个全的playbook你可以很清楚看到每一个Roles要做什么事情。你可以给每一个Role命一个别名，我可以把所有有这个Tags的Hosts给执行一个ubuntuprotobuf，你只要用这个Tags。我们在运行一个命令之前，就确认它会在哪一些机器上执行，然后去确认一下，他会去运行哪一些命令，你可以把这个去掉，就可以开始执行了。我不知道现在能不能执行，我还是最好不要执行，我给大家看一下吧，这就是我们其中的一个生产环境，我给大家执行看一下，应该没什么太大问题。他就开始playemqtt，会收集一些原始数据。他收集的数据非常多，大家看到这个叫Gathering facts，你系统的版本、各种平台的信息全部收集下来，其实收集这个信息就是要判断你的版本，它会执行不同的分支平台可以帮你做这些事情。还有比如说依赖于你的IP、依赖于一些其他的信息，比如说你可能有几个网口，可能你的配置需要用到不同的网口配置，在第一步就会把这些信息全部收集起来。这边还有一个很重要的是验证你的目标机器是不是能够连的上，在这个Protobuf过程当中。我的汇报就是这么多，看看大家有什么问题。
精品文档
因篇幅问题不能全部显示，请点此查看更多更全内容