基于SaltStack的基础设施即代码

白凡

分享：赵班长
编辑：白凡

讲师介绍：之前是在武警部队做运维工作，后来退役之后到北京做运维工作，身边的朋友都叫我赵班长，所以就一直这样叫下来了。是中国SaltStack用户组的发起人，2008年发起了一个运维社区，现在自己创业做DevOps学院，也和朋友一块儿写过书，三个人写了一本书，出版了好几年，从来没在市面上见过。自己写了一个运维知识体系，大家可以关注运维社区来了解。

在部队做运维的时候，最早的优势是什么？就是你们没见过的设备我们都摸过，各种贵的你们买不起的我们都摸过，一个程控交换机可能价值至少过千万，除了到很大的地方，在中小型企业是看不到的，武警有自己的防火墙。我们和其它的地方不一样的是我们还有加密机，所有的传输都会用加密机的加密，并且也都是硬件。

大概2004年左右就实现了光纤到哨楼，当时网吧都还没有光纤，我们实现了光纤到哨楼，然后数据、语音、视频三网合一，最早还是北电的设备，大家可能还不知道北电，最早还没思科什么事，最早北电是老大，后来北电没落了，思科才慢慢起来。
我个人做运维也比较奇葩，我最早是做安全的，安全界有句话，真正的黑客是要会Linux的，2004年的时候我就从windows转到了Linux。

今天分享的主题有四个：

• 第一个会讲配置管理
• 第二是基于SaltStack的基础设施即代码
• 第三是以SaltStack为基础的自动化运维实践
• 第四部分会介绍一些基代码

1. 配置管理（状态管理）

之前有人问我，你怎么还在搞SaltStack，我们都用Ansible了，SaltStack已经过时了。我说你去看看谷歌官方提供的自动化部署的方案，它就是SaltStack。

现在做运维有两种方式，第一种方式是命令式，相当于做命令的编排，我拿Playbook写了很多命令，到机器上执行，我就实现了自动化。我说这叫自动化作业执行，这是命令式。还有一种是声明式，我声明一个什么状态，然后它会帮助我们实现这个状态。

我们说配置管理，其实更严格意义上来讲就是状态管理。我们可能都听过一个神话故事《神笔马良》。我为什么拿神笔马良举例说这个状态管理？因为这个和状态管理完全是一样的，谁是神笔？就像SaltStack、Ansible这样的东西就是神笔。谁是马良呢？也就是我们使用者。这样一描述你就懂了，什么叫状态管理？就是你描述一个状态，然后这些工具帮我们实现状态，这是完全不同的，一定要注意你在它的机器上装一个NGX和这台机器上有一个NGX是完全不同的。

声明式的更新相当于是在执行的基础上又封装了一层。比如说你要在这个机器上装一个NGX，你只要执行这个命令，每次都要装一个。声明是你说这个机器有一个NGX，每次执行状态的时候，我就会检查这个机器上有没有NGX，如果没有我就把它装上，如果没有我就什么都不干。如果有人把这台机器的NGX卸了，我再执行这个状态，它就会装上，这就是状态管理，你描述的是一个目标状态。

所以说我一定要把这个东西给大家讲明白，因为我看着好多刚入门的拿着这些工具说自己都会，但是干的事却很悲哀，明明人家工具那么强，结果你就是做这种命令编排。

2. 基础设施即代码

大家知道Ansible现在被红帽收购了，红帽在国内的市场份额还可以，所以它一直在推。SaltStack在国内的份额相比红帽要小一点，他们做软件定义数据中心，国内有很多大的企业也在使用SaltStack，只不过他不说。
SaltStack最基础的两大功能，第一是远程执行，现在好多做自动化运维平台的做作业平台，定义一个作业，然后在那个机器执行这个作业，其实就是Salt的远程执行。目前国内有很多商业的产品是基于Salt封装的，但我不能告诉你是谁。国内很多商业的自动化运维平台底层就是封装的SaltStack，因为底层的执行者你没必要去自己写，它说难也不难，但是要说容易也不容易，它的稳定性、安全性等等很多问题还是蛮多的，所以我们现在做更上层的东西，可以直接利用Salt做最下层的执行者。
再紧接着就是状态管理，SaltStack的状态管理是基于命令执行基础之上的。Salt为什么叫Salt，是因为他们美国的那个组织在盐湖城，当时要注册一个名字，发现叫Stack的都火了，然后他们就决定叫SaltStack，最后发现这个能注册，就叫了这样一个名字。最早它是做什么的你都想不到，他们是做监控的，它做了一个类似作业的平台，用来采集数据。后来就开始做远程执行，他们做了远程执行之后发现，在上面做一层封装，把它封装成一种声明式的，现在声明式很流行，比如说咱们在座的如果有研究K8S的，它就是典型的声明式，你写一个文件，声明你有几个什么东西，让KBS帮你执行，所有东西它就会管，这就是声明式的。所以你会发现有很多的概念其实很早的时候就有，只不过很多的技术引到国内之后，在大厂发展还不错，但到了小厂就会被用歪了，把人家最主要的功能砍掉了，然后用它最基本的功能，这真是挺遗憾的。

Salt有两个最核心的东西，一个是Grains，一个是pillar。Grains是做数据采集的，我可以把数据采集存储下来，Grains可以做CMDB的资产采集、资产比对，我们之前就基于Grains，把硬件的快速服务代码获取，然后我们又写脚本，拿到这个快速服务代码贷给官网，判断这台机器是什么情况。如果你是一名编程者，你见到的所有东西都支持二次开发，你可以自己写一个Grains。
现在大家看到的是一个高级状态，所谓的高级状态是什么呢？每台机器都可能有很多状态，我可以通过模板的形式帮你定义各种名称。现在刚入门的都去玩Ansible了，真正用得深的才用SaltStack，因为你能做的东西真的是太多了，你会发现你能把所有的运维工作全部使用SaltStack来完成。

接下来我要给Salt正名。Salt有Salt SSH，我们之前举办过运维挑战赛，有一届的冠军的方案就是用的Salt SSH，只不过他没说，因为不太方便透露我们是用开源的，2000台机器直接执行没有问题。那一场还有京东参赛的，京东获得的是第二名，他们用的是Ansible。还有一个最牛的事情是这个主机的编排可以直接兼容Ansible的house文件，我觉得Salt官方做得好厉害，为了让你无缝迁移过来，把他们的文件都兼容了。
大家都问SSH是怎么执行的。其实SSH有一个很大的问题，它比较慢，它为什么慢？你要在这个机器装SSH它怎么帮你干活呢？不管是SaltStack还是Ansible，它们的原理是类似的，首先你要执行状态，那台机器什么都没有，我把本地的状态确认一遍，然后看一下这些状态都要调哪些指标，然后打一个包，把这个包传输到这台机器上，到那个机器上把那个包解压，然后在本地执行，其实就可以了。

Salt还有一个特别牛的功能，一般别人问这么牛的功能你平时分享为什么都不讲？我说因为能接受的人群比较少。其实我经常说咱们中国已经这么多大会都在讲AIOps，我可以告诉你，全盘来看中国互联网的运维水平是中下等，大部分公司运维水平还是在走标准化、工具化、自动化，还是差很远，只不过两极分化很严重，大厂已经在研究AIOps，但是很多种小型企业根本就做不到那一层。其实所有的理由都是借口，最主要的就是没钱，另外也是自己现在的规模做AIOps对自己的业务没有任何的价值。我一天PV只有10个，宕了就宕了。但是越大的互联网公司，它的价值就越明显，所以是一个投入产出比的问题。
事件驱动的基础设施，所有的东西都会产生一个事件，这个事件会被发送到事件总线上。这个事件总线可以配置规则，如果当发现有一个事件的时候，你可以触发一个规则。

Salt怎么写？我给大家写好了一个模板，所有的东西都是由Salt做自动化的部署。之前有人问我说，我这个自动化到底怎么才叫干得不错？我说最简单的，你们所有的服务的部署都不应该是手工的，只要是手工的，别管你现在在做什么。我真的见过公司一帮人在搞AIOps，这帮人在手工编辑NGX，这是有问题的，正常应该是全部自动化的方式，我们做的话，这台机器是NGX的角色，就应该把它装上。

还有人说现在都是云计算时代了，还用SaltStack吗？Salt有一个组件叫saltcloud，它支持所有公有云和私有云。

现在还有人说，我们都容器化了，你怎么还在玩SaltStack？未来绝对是虚拟机和容器并存，甚至虚拟机、容器、物理机并存，不可能所有东西都是容器。比如说我们之前做电商，你的支付就要插一个Ukey，很多业务没法用容器的方式来运行。

3. 以SaltStack为基础的自动化运维实践

SaltStack为基础的自动化运维实践，第一个案例是结合CMDB完成基于角色的运行环境交付。别人说你们这个环境怎么交付，我面试的时候好多人说我精通这个精通那个，各种安装部署调优，我说你来我们公司都不需要，我们不需要安装调优，所有东西都是一键的，根本不需要到它的机器上实行上来东西，你的操作只有一个，就是在CMDB上创造一个标签。

第一个案例是结合Zabbix做自动化监控套件。大家知道做Zabbix有三大套件，第一个是监控脚本，你要写一个监控脚本把你需要的所有的卡夫卡的指标写出来，第二个是自定义配置，第三个是监控模板。我在生产上就是这样做的，我把生产用到的所有服务全部按监控套件的方式做好了。所以你会发现只需要打一个标签，服务做好了，监控也做好了，剩下就是部署代码。部署代码也有自动化的东西。所以是用这样的方式来实现自动化的监控的。

4. Everything is Code

刚才说了基于SaltStack基础设施即代码，什么叫基础设施即代码？这其实就是基础设施即代码。刚才我给大家演示那个架构，我们就是写代码，这是基于SaltStack的基础设施的即代码。

还可以基于Jenkins的Pipeline as code。这就是Jenkins的流水线，可以做一个简单的流水线。

还有一点，一切即代码，你通过一个描述语法描述出来你有什么东西，你有负载均衡，有数据库，架构是什么样的，直接就帮你创建出这样一个架构，这是AWS的一个案例，目前阿里云、腾讯云都是支持的，但是阿里云那个写法支持的格式不太相同。我们使用SaltStack做状态管理的时候一定要记住这一点，要进行版本控制，你现在写的是代码，这就要按照研发的流程来做，你得有流程控制，你得要做测试。如果你做自动化的开发的时候，如果没有测试，你要想想某某事件造成了所有机器被格式化的问题，就是因为没有测试，我见过好多的运维研发团队可能有六七个人，我说你们做测试吗？他们说不做，自己点一点没问题就上线了。我说你们这好大胆，他们说他们自己也不会测试，都是运维转过来的，不会做测试。如果咱们是做运营研发的，一定要想一想，把测试的东西要加进来。

5. Q&A

我的分享就到这里，更多的内容可以关注我的微信公众号，也可以留言，可以“互相伤害”。经常有人说我就看不惯那个讲师在讲台上吹牛，你们做得行不行？我们可以敞开来聊，你一问一答就知道他到底有没有做过。