基于 Ansible 的主机自动化配置管理

作者简介
王奥
前上海某交易所 DevOps 专家

大家好，Ansible 大家也都知道是一个配置管理工具，现在被收购了也是有一个商业化的服务支持。

今天是第十届GOPS大会，我从聆听者变为了演讲者，希望在座的各位也可以站在台上。

我把主题的门槛定的低一些，这是一个比较 Low 的主题：

五个九和四个九表示是你能听明白和清晰理解我能用 Ansible 做什么，你也能看到我们公司是用 Ansible 做了哪些事情
80% 的人听完之后能借助 Ansible 并完全模仿并实现更符合需求的管理方式，这句话怎么理解？是因为 Ansible 本身就是一个非常简单的配置管理工具，是标准化的脚本语言。你们看了这个之后知道我们做了什么，同样你们也能用 Ansible 实现相同的需求。
最后百分之百的努力是去平衡生活，我们知道做运维都很痛苦压力大，需要花时间去平衡家庭和工作的。大家都很年轻，我刚刚结了婚，也会遇到很多的问题，希望大家都能做得更好。

1. 公司和技术架构介绍

我上一家单位是上海某交易所，目前在新加坡 Sea，以下内容以交易所的 Ansible 实践为主。

前两点都很好理解，不同行业侧重点不同。

从第三点来看，我们已经消灭了小机，金融机构消灭小机是个趋势，而且对于做标准化很有利。

第四点是内外网物理隔离，这个大家如果能理解物理级别的隔离就明白在管理上成本有多高，同时也面临各种安全合规上的要求，这是一个效率和安全的平衡过程。

第五点，我们由成熟的国外商业化集成方案逐步向国产开源运维研发一体化转型。

第六点，现在已经流行 DevOps 和 AIOps，《研发运营一体化 DevOps 标准体系及能力成熟度模型》已经评上了国际标准，大家都可以借鉴和参考，拥抱变化。

这是交易所之前的解决方案，对于裸机和虚拟机的部署，我们知道成本很高。

我们也在逐步转型 OpenStack，从最原生的 Bash Shell 到 Ansible 项目 v1.0。

我希望在下一界运维大会的时候能邀请原来的同事分享自主研发且支持商用的监控平台。

我们为什么选 Ansible？跟大家的理解可能类似，灵活，它是没有客户端的，可以非常轻松地切换其他解决方案。

Puppet、SaltStack 学习成本比较高，商业化产品无法满足个性化需求，基于 Ansible 二次开发就成为了一个十分理想的选择。

这是我整理的一个CM配置管理工具流行趋势，Ansible 是 2012 年出来的，它是后起之秀，但活跃度远远高于其他的。

2. Ansible 标准化学习路径

这是我们之前整理的一些官方的学习标准，包括我们内部的资料。

3. Ansible 项目实践

到这里我希望大家能理解用 Ansible 做什么，我这边提了两点，第一点就是标准化，这里的标准化很复杂但又非常重要，这里我们体现更多的是软件层面上的标准化，标准化是自动化的充要条件。

所以，做标准化很重要。Ansible 并不知道你的需求。但是你有了标准，你就可以基于 Ansible 快速实现自己的需求。即使你不用 Ansible，你也能够做更多的事情。

无论是自建数据中心还是托管，私有云或者公有云，唯一不变的是自动化运维的能力，这点会让你们永远不会被淘汰。

3.1 Ansible 项目实践 - Linux

我们去掉了小机，目标是把 Linux 和 Windows 管起来。

下面我会比较快地做一个梳理，它不是最重要的，最重要的是思想。

第一个服务端，Ansible 很简单，我们是在 RHEL 6 和 7 上搭建，服务端的 Python 版本我们用的是 2.7.14。

2.4 以上 Ansible 变化非常大，因为它对于 Windows 的支持上了一个台阶，在 2.4 之前的版本，连 Ansible 官方都写我们做 Ansible 不是为了管 Windows。

管理的对象，我们这边主要是针对RHEL 5/6/7，包括最新的版本。还有基线的标准，这个是很多公司想要的，因为这是自动化的前提。

这是一个思维导图，从这个图里可以看到这个结构非常简单，Ansible 就是 inventory 和 playbook 两部分，主要有四个功能，我们后面会讲。

服务端也说了，客户端安装的时候，一般只有 RHEL5.5 需要安装 simplejson，其他的都不用很方便。

可以看到这是一些最基本的纯命令行，而且是可以灵活调整的

配置文件也很简单，因为我们的关联方式包括传统密码，下面有做优化，我们设了一个缓存。

下面是 Ansible 的一些变量，后面都写了非常详细的解释，这些我认为很基础，大家看了之后，包括看官方文档会很清晰。

主要的功能是用户管理，包括用户创建，信任关系添加，密码修改等

第二个配置是动态化的，第三个主要是补丁包，大家都会遇到突然出现高危漏需要尽快评估修复的需求，Redhat 官方也会使用 Ansible 作为打补丁的标准化方案之一。

最后备份恢复非常重要，因为我们不能保证在不同的平台下，你每次做执行结果都是一样的，有可能出现一些意外。之前我们在虚拟机上测试，后来放到新的服务器上执行结果把它搞坏了又没有备份配置文件，导致了服务器要重装，所以说备份很重要。

这是一些简单模块的处理，我认为没有必要多讲，大家事后可以做参考。

这边 Ansible 做的条件过滤判断非常方便，但这又是比较低效的。如果你们有自己的 CMDB 的话，提前分组执行，而不是让 Ansible 帮你判断，Ansible 虽然很快，但是牺牲的是效率。

3.2 Ansible 项目实践 - Windows

下面的是 Windows，我相信用 Ansible 很少用它来管Windows，因为大部分人没有需求，但是我们公司有，所以我们就得硬着头皮上。这边的管理方式跟那边一样，唯一不同的是我建议安装 2.4 的版本，包括最新的 2.6 也支持。

这边有一个 Windows 的安全基线，每一条我们全部写得清清楚楚。

这边的目录结构也是跟 Ansible 差不多，这上面写的安装可能是稍微有一点区别，如果Windows 版本低于2012，你需要升级客户端的 Powershell。

配置结构和Linux类似，大家后面仔细看都能发现，其实都是跟 Windows 相关，跟我们基线相关，可以非常方便的自由定制。

用户也是一样的，你改密码的话，目前没有特别好的方式去改，因为改完了会报错，但实际上是改成功了，这是一个坑。

整个配置流程和Linux保持一致性，大部分基于Windows的原生模块编写，支持注册表，本地安全策略，高级审计策略等等。这边是 Windows 的条件系统判断，它支持中文，你不用担心它对中文不友好。

4. Ansible v1.x 项目总结

我们原来主导Puppet的同事离职了，在重启自动化平台项目后用起来也不是很爽，加上很多安全合规的要求，最后选择 Ansible 源于多个维度的考虑。

当时用的时候是 2.4 以前的版本，对 Windows 的支持是个迷，你要顶着这个压力往上走。左边是我们写的代码，原来基于 Bash 写的代码非常非常复杂，是我领导一个人写的，你要知道支持 AIX/HPUX 另外两个操作系统有多么的不容易，他都做到了。我们想在这个基础上改，很痛苦，看不懂。

右边是我们传统的用 EXCEL 书写的，这些我们现在都可以转换成 Ansible。我们这边用它有几个好处，第一个使用场景标准化，因为我们通用的是 X86 服务器，无论是物理机还是虚拟机它都支持。

第二个我们没有小机很幸福，同时也实现的对Windows的管理，第三个我认为很重要的一点，我们适配了不同的配置场景，而且我们不止步于 Baseline，原来我们要拖很久，我们要去改很复杂，现在我们随时都可以灵活调整。

第四点 Ansible 的版本非常稳定，而且升级非常方便，大家不用担心装了版本之后我要升级是不是很麻烦很复杂，没有的事。你可能只要升级一个服务端。

现在我们把不同岗位的需求整合到一起，用 Ansible 统一维护并突破了不同的部门墙。跨岗位的需求我们都可以快速地迭代实现，所有的人都可以看到变化。

我相信大家现在用 Ansible 也没有什么好犹豫的，因为社区很活跃，知识库也很丰富。当时我们看不清楚，我们想的是怎么去破冰，想让运维人员去喜欢、去适应。

第三点最痛苦的地方是我们怎么把原来的 Baseline 转化为 Ansible，即便我离开了剩下的人都可以很快地上手，我觉得这是最重要的一点，为什么要用开源，这是有标准化的支持。

第四点是 Ansible 早期版本对 Windows 不友好，我们当时处理很痛苦，到现在我们发现已经有了良好的支持，大家可以大胆放心地使用。至少我使用Ansble实现了 Windows 7/2008/2012/10/2016 的全部基线要求，所以不必担心。

第五，内网隔离的情况下，网络不通，没办法连外网，这时候使用 Ansible 也可以很优雅地解决。

第六个是 Windows 和 Office 的补丁如何打，我们需要安装那些受政策、受合规性要求的补丁。我们全公司做了桌面虚拟化，即使在域控管理模式下，使用 Ansible 也可以轻松实现补丁的更新，对普通用户是无感知的。

5. Ansible v2.0 项目

这原来只是一个计划，现在在新加坡的公司已经实现的差不多了，有机会可以来年再分享。

6. 友情推广

这里有一个友情推广，我希望有更多的人能站上来分享，因为交易所相对来说比较神秘，但背后也做了很多专业的事情。比如 LightCam 完全自主研发并支持商用的监控平台，AOP 自动化运维平台也成功申请国家专利，我们希望可以自动化更多的场景，人始终会犯错，但犯错后才会激励我们去改进方法。

项目实施类的大家可能也在做，我们有一个项目是做 View 跨版本升级以及华为的 FusionCloud 的对比。和大家一起学习和进步。