［ECUG专题回顾］使用SALTSTACK部署OPENSTACK的运维实践－石山石（携程网云平台系统工程师）

Posted 2021-05-01 七牛云

ECUG 全称为 Effective Cloud User Group（实效云计算用户组），由七牛云CEO许式伟于2007年发起，集结了一批具有高端视角并仍醉心于技术本身的同仁，共同关注云计算前沿技术的最新成果和分布式开发、运维的最佳实践。在过去的八年中，ECUG社区每年都会组织一场全国性的ECUG Con 大会，期间众多技术大神纷纷参与，他们或许在大众技术会议已经鲜少露面，但会在ECUG Con畅谈心得，共同奉献大批高水准的技术分享。值ECUG Con2015即将召开（2016年1月22、23日，北京）之际，我们特意挑选了往届大会中那些历久弥新的精彩演讲进行回顾，以飨读者。

石山石：大家实践起来肯定还是我相信他们还是从最早很小的规模到很大的规模，今天想讲的是携程在从SaltStack这个部署方面，从0到现在大概200台规模这样的一些实践的分享。我们携程的云平台是从12年的7月份开始组建的，现在大概有2部分的业务一部分是携程的网站还有IT提供IaaS，包括虚拟机，生产上是VMware还有物理机的应用，另外一部分是为携程的呼叫中心提供VDI的，后面是用的spice。

 

我今天讲的主要是携程的虚拟机这一块，携程的虚拟机和其他很多公司不同，是有很多的Windows sever。携程还没有完成这样的转变，实际上也不能随便动他们的机器，所以他们现在不完全是叫cattle我们现在的VMware也是有自己的一些用法，没有用到高级的功能，只是用了一些OpenStack，所以我们自己有自己的修改，现在都流行一些SDN，但是我们要改变这个还是逐步来的，所以现在还是很基本的用法，主要是拿一个IP，跑一个DHCP。关于这一块社区有一些分享，如何在OpenStack上面做二次开发，最下面是他们有一些工具，做一些系统。

 

我们现在用的是Ubuntu的12.04，这个也是因为我们的在kvm上跑也是有问题的，我们自己的代码打包的话是稍微修改了一下Ubuntu server他们打包的控制文件，这个版本实际上是有三部分的，前面的epoch是优先级最高的，只要我们自己打的包比官方的版本优先级要高的，后面的这个是在上游的OpenStack上面加了一位数字，这个是我们里面的version，我们可以打不同的包，这个脚本也是有问题的，这个也是要加一个version，加了一个标识，现在也是用了Docker打包的工具，另外我们也有一些apt-cacher，这个都是Go的工具，现在大家都用Go，我们不用也不好意思出来讲了。

我们在开发过程当中也经常下apt的包，有了这个以后开发的大家都知道在中国有的时候等这个东西最早的时候要等10几分钟，有了这个以后生活就瞬间美好了，下面是HP他们的OpenStack Helion，他们自己做了一些自定义的，他们有很多这方面的资深人士，接下来就是如果要部署的话，我们前面改了那么多东西，部署的话就要来决定到底用哪些工具了，最早的时候我们只知道有puppet，chef，salt，ansible，这个是按照他上手的难易程度排的，上手难的话知道的就很少。当时也是没有像apt开始的时候这样东西，下载的包也是很麻烦的，前面有一些没有试出来，后面尝试的时候也没有关于比较这些东西，网上一搜一大把，我们选的话也没有什么高深的东西就是好用用起来的就可以了，而且下面的话像这边是OpenStack他们分享他们之前用的puppet，后面是OpenStack，这个人也是把puppet弄出来了，现在也是结合做这些东西。

 

我们讲salt是怎么工作的？当初调研的时候是希望能够在写salt之前就知道的事情，一个是salt-master，你在salt-master上面执行一个这个东西告诉kevin这台minion跑这台，他会收到这个请求。

 

这块的代码是在salt源码上面的master.py。

 

minion所有的都会收到，如果是的话就从本地装上之后会有自带的，这边就是前面的data，会把这个结果返回给master，这个代码也是在salt.minion上，因为我们是做OpenStack的，所以这方面看起来比OpenStack简单很多。之前前期经常遇到的一个问题是salt did not return，过去之后经常什么都不返回，知道前面的salt工作原理之后就会了解到实际上master并不做多少事情，主要的工作是在minion这边来做的，所以我们一般是在minion这边看，可以看到有的时候真的就是假死了就是网速的原因，也可以看log就是看minion这边的log，到底这个minion在做什么？然后官方也对这个东西实际上是故意设计成那样的，如果minion那边超时了或者是怎么了是什么也不返回的，但是新版本是有一个参数，可以调成true，他会告诉你，我们的建议是尽量有新版本的salt，它会带来一个更高版本的zeromq。

 

我们一开始的是这样看的puppet，昨天搜索一下发现这本很著名的书里面也讲了puppet，我们看下来的感觉是感觉salt这部分的实现要比我们预想的容易很多，也比OpenStack那部分的RPC的容易很多，前面有兴趣的话也是可以看一看的，然后刚刚百度的肖平也讲了他们的用法，salt有另外的教法，有了前面的job，一些疯狂玩家就发命令给minion就做一些事情了，我们正常人是通过写salt states，帮助salt转化成一条一条的命令发给minion，然后文档里面是salt的states，它的来历是salt states的几个字母，然后文档里面还有一句话是sls files are just dictionaries，我们下面看为什么是这样叫？

 

一个最简单的例子是我们装包实际上网上搜的话很多的文档直接告诉你apt-get就可以了，在我们私有云的环境里面是有的时候有防火墙的，有的时候网不通，你每次做这种事情，如果都是从网上下载也是很慢的，一个解决方法就是可以让salt跑，最好的方法是下面的方式，可以看到这边有一个如果熟悉jinja是一个模板的语法，实际上是两步，第一个是发送这个命令，把这个文件cache到minion上面，然后返回了是minion上面的路径然后会替换到这个apt-key的地方，所以最后实际上看到的这边是会被替换成cache key的位置，这个实际上是我觉得很神奇的时候，在salt里面是通过renderers实现的，这个里面可以看到编译的过程，里面有render_pipe的内容，默认是yaml_jinja，是先通过这个处理一遍把这个输出再传给yaml render，我们看一下yami renderer拿到之后的结果。

 

有了前面这些东西的话，实际上后面再之后写salt的话就是记住salt大法就是可以了，就是三个链接，另外如果jinja不是很熟悉的话，之后去他的文档里面看一看就可以了，关于这个写sls的话，新手实际上不是一个很难的东西但是还是要折腾一段时间的，如果碰到问题了的话可以看一下下面的这些更正式的定义，比如说states里面sls怎么定义的，salt的states是怎么处理的，然后前面这些的这两个页面里面的东西很容易和salt源码里面的目录对应起来。

 

loader会加载进来，但是在这个上下文里面注入这些pillar。这个是文档里面的参考链接，这个是源码下面参考的loader.py的文件。

 

Develop environment之前的版本是很容易加一些pdb的断点的，这个是可以看一下他的文档了，最后是用一个tmuxp这样的工具，之前我们介绍了一下salt sls，这个实际上就是你写了一个程序，有了源代码但是没有输入，比如说你写了一个参数是N的，执行这个程序，实际上N就是等于10，如果做OpenStack的话，是有很多的配置的，有配置的话就看如何给salt states给他一些输入。

 

一种是一些roles数据，像OpenStack的节点主要有4种，一个是controller，还有一个是OpenStack compute，还有一种是OpenStack data，还有一种是OpenStack slb。

 

下面是遇到的问题网络没有规划好，我们没有经验所以我们诉主机的vlan出现了两个，这个是机器部署完之后不会改的，我们的做法也是把这个vlanID写在这个里面，并且可以拿一些数据，这个是静态的输入。

 

OpenStack configuration

 

Configuration OpenStack is nontrivial，我们一开始的话也是尝试了看看上游是不是有相应的module，parameterization，repository structure，这个OpenStack的输入和上游基本一致的，然后map.jinja有一些默认值是实际的输入，到了后面的配置文件的话是可以直接用了，用jinja的模板写到后面的文件里面去。然后所有的这些配置项都是在map.jinja里面声明一下，这个时候如果写readme的话是非常难写，有的有默认值有的没有默认值这个维护起来不是很方便，然后pillar的优先级比map.jinja里面的优先级高。

 

这个我们跑下来一直到现在都是用起来很方便的，所以如果你觉得这个不是真正的marge这个配置就做的有点复杂了，像这个红的概念实际上是程序设计语言的概念，我们运维也可以接触很多计算机科学方面的知识，最后在sls文件里面，会在这边把它传给模板文件，在这边直接用了，就不需要做什么处理了，所有的处理是在map.jinja里面做掉了。

 

刚刚提到了上游的一些东西，满足不了我们的需求，我们把老版的OpenStack搭出来，也把新版本的OpenStack搭出来，我们测升级的，方式是这种方式，那渣这个做一个例子，在这个目录下面有一个dhcp-agent的sls，这个就是get里面的不同的，但是这两个分支的sls是这样，是通过salt的include，extend，把自己需要修改的地方做一下扩展，jinja也提供了这些功能，为什么不用get（音）？如果salt提供了这些东西不能满足我们的需求，我们还是可以用到get的，但是实践下来是salt和jinja这些东西，如果会用的话还是很方便的。

 

map.jinja这边有一个override，会把master的map.jinja把自己需要扩展的把这些做一下，然后像sls的话他就变成ml2了，这个时候他的core_plugin应该是之前的，最后还是会调用这个把piller的数据放到这边。

 

sls还是需要稍微做一些改动的，jinja这边不是是salt的incluld，然后jinja会把这个东西做一个序列化，所以两个里面master用的是里面map.jinja的。

 

最后模板这边是一个jinja的例子，我们是用包步数，开发是用get安装的，我们的模板这边是开发环境的模板直接extends，加上我们的一些log的格式，因为维护这个OpenStack的配置文件也是很烦的一件事情，所以要尽可能的重用我们正式部署环境的变掉了，开发环境的配置也会跟着变的。

 

解决了版本之后的话，还有一个问题，是OpenStack有很多的组件的，nova是希望和这些东西是可以装在不同的节点上面的，所以要尽可能的分散开来，尽可能的模块化，有一个问题是nova.conf，我们解决的方案是从这个打包管理里面得到的灵感，可以看一下这个文件在哪个包里面管理的。

 

把任务分解以后是为了给灵活，但是有的时候就是想要做一些聚合比如说我的就是要装一个环境，我需要include把这些东西include进来，这个的实现是salt来用了jinja和yaml很容易把一个作为一个关系处理的，具体的代码是在这两个地方，然后这个看起来我们也没有权限看，但是我们碰到了一个问题，是通过看这边的代码解决的，实际上salt是他找一个依赖的时候，你可以让一个state依赖整个sls文件，那个sls文件执行再执行当前的state，但是找的时候和程序设计语言里面找的话，实现可能是有一些不同的，但是可能是找每一个state是标志在哪一个文件里面定义的，如果一个文件里面只有include这些东西没有真正的文件，他就认为这个东西是找不到，这个文件也是有问题的，所以我们在代码里面稍微找到了这部分的代码，解决方案就是写一个什么事儿不做的state，如果真的反馈给上游的话，这个方案还没有想好。

所以不能将数据库它本身作为这个sls文件里面的依赖，他们规定是装在一起的，这个时候就有一个需求了，是在data里面装一个，然后再这些里面装OpenStack的severs。昨天我去点开这个连接以后他告诉我已经移动到这个地方了，这个回去以后又有事情可以做了。

这个我们花了很大的精力写了一个OpenStack，把用apt-get的包换成git clone，这样的话配置文件基本没有多少的改动，我们就可以做到尽可能的复用这些开发环境了，salt还有其他的形式，salt-ssh，一种情况是minion没有装好的时候可以通过这个装minion，还有的是说有人把minion装错了，这个时候需要这些手段把这些错误修改回来，最后我们用的是这个fabric，这个大家都会写的，还有就是说salt-call，前面的stacker这个东西用户会让你，如果用salt的话还是装一个minion才能用我的OpenStack，我们知道master做的工作不是很多，所以salt很容易支持了standalone minion的形式，在本地装就可以布一个开发环境出来了。

 

现在我们在做的事情就是相当于之前百度他们讲的环境，现在已经越来越大了，然后像之前都讲到了，我们是有很多的环境要给机器打上tag，salt里面也有相关的支持，我们现在有比如说上海的环境，有南通的还有我自己有多套环境，然后我就是用了salt提供的directory overlay这个，配了多个路径会先从第一个路径找，是不是能找到这个文件，如果找不到会从后面的接着找，这个在pillar这边的用处是可以找到在相同环境下面所有OpenStack的所有的节点，有命令的支持，可以动态的生成里面的条目，在states用处不是很大了，有一些人他的bashrc这些东西都可以覆盖这些环境里面的东西。

 

接下来是从0-10这个手动的做字也没有关系，我们salt现在是支持从10台到100多台机器了，现在也很稳定了，很容易换到1000台的环境，我们打算做的是一个后面全部放到颁布控制里面，我们是之前只有states放版本里面的，如果放里面的话就是piller做加密，有可能是部分加密，这样的话就可以把它开放出来做这个了。还有就是上游的做开发，实际上上游就是也有一些更新，跟我们的思想也是差不多的，另外一个最痛苦的salt是测试，我们也想换成用Docker测试，然后下面可以看一些大公司的介绍，谷歌等等这些他们都有想法。

 

我们总结的话，实际上salt它是一个description语言，不完全是程序设计语言有一些概念行不通但是实际上也是非常强大了，只要能够掌控它就可以了，然后就是要熟悉工具的文档，salt的文档最开始的时候也是非常乱的，现在稍微好了一点，但是感觉还是比较乱的，我整理这个就整理了好久。然后像这个东西我们是实际上只有6个人在做这部分的dev ops qa support都做的，这个前面也讲的了，主要是为了解决问题的，也不是有这么明显的划分的。然后是learn from the best，向最好的人最好的公司学习，然后就是把运维做好，谢谢大家！

ECUG 2015正在火热报名中，点击“阅读原文”即可前往报名～