带你「拥抱开源」- Ansible

Posted 2021-04-25 火炉山蚁群

「他山之石，可以攻玉」

「第三章系列文章将带来“开源工具”在移动云运维工作中的实践经历分享」

1、作者介绍

刘超，移动云系统、中间件及存储运维工程师。负责MQ、Redis等中间件及云存储业务的维护及自动化运维工具开发工作。

2、什么是Ansible

Ansible是近年十分流行的一款运维自动化工具，在其官网上定义如下: Ansible is Simple IT Automation. 即Ansible是一款简单的IT自动化工具。

Ansible的主要功能是帮忙运维实现IT工作的自动化、降低人为操作失误、提高业务自动化率、提升运维工作效率，常用的场景有：软件部署自动化、配置自动化、管理自动化、持续集成等。

Ansible使用Python语言开发，由Michael DeHaan发起创建，他同时也是著名工具软件Cobbler与Func的开发者。Ansible的第一个版本发布于2012年2月，后于2015年10月被Redhat公司收购。收购后在保持开源的同时，Redhat公司还为企业客户提供Ansible商业服务，如健康检查、培训、咨询等。

当前在GitHub上，Ansible是排名前10位的Python项目，活跃度远超其他同类型自动化运维软件。

3、为什么选择Ansible？

 当前比较流行的几款与Ansible功能类似的主流配置管理软件有Chef、Puppet、SaltStack等，通过对比研究，结合我们团队的实际情况，我们选择了Ansible，主要看重其以下优点：

（1）巨人的肩膀：Ansible完全基于Python开发，Python对运维人员而言有天然的亲和力，当前DevOps已然普及，运维人员使用Python自己开发工具的门槛逐步降低，因此可以方便地对Ansible二次进行开发；

（2）丰富的内在：Ansible有丰富的内置模块，甚至还有专门为商业平台开发的功能模块，近600个模块完全可以满足日常运维所需；

（3）简单易用：Ansible的部署和使用方式都十分简单，学习成本十分低。运维前期积累的脚本工具也可以在Ansible工具下使用。

（4）DevOps融合：Ansible可以方便地集成到DevOps工具链，提供自动化配置、管理等功能为DevOps所用。

（5）Agentless：Ansible使用ssh连接，客户端无需任何配置，由管理端配置好后即可使用，这点非常诱人。

（6）去中心化：Ansible没有中心节点的角色，一个简单的复制操作即可完成管理配置中心的迁移。

（7）良好的社区活跃度：背靠Redhat的大树，还有良好的社区活跃度，Ansible的未来不可限量。

4、Ansible原理

Ansible没有客户端，底层通信依赖于系统软件，Linux系统下基于OpenSSH通信，Windows系统下基于PowerShell。使用者在管理节点通过Ansible工具调用各应用模块并将指令通过ssh连接推送至被管理端执行，在执行完毕后自动删除产生的临时文件。   
        Ansible系统架构图如下：

根据Ansible使用过程中的不同角色，可以将其分为三类：

（1）使用者

用户可以通过通过多种方式来使用Ansible，最常见是Ansible命令行（Ad-Hoc）和Ansible Playbooks，此外还可以使用基于CMDB、PUBLIC（公有云）/PRIVATE（私有云）等的API接口来调用。

（2）Ansible工具集

主要有INVENTORY（命令执行的目标对象配置文件）、API（供第三方程序调用的应用程序编程接口）、MODULES（丰富的内置模块）、PLUGINS（内置和可自定义的插件）等。

（3）作用对象

Ansible的作用对象，不仅可以是Linux、windows等操作系统的主机，同样也可以作用于各类公有云/私有云，网络设施等。
        Ansible的执行流程如下图：

使用方输入有效的指令后，Ansible会按照预先编排的规则将Playbooks逐条拆解为Play，再将Play组织成Ansible可识别的任务（Task），随后调用任务涉及的模块（Module）和插件（Plugin），根据Inventory中定义的主机列表通过SSH连接将任务集以临时文件或命令的形式传输到远程客户端执行并返回执行结果，如果是临时文件则执行完毕后自动删除。

下面以一个简单的Ansible命令执行过程为例说明Ansible架构和执行流程。这个命令即是使用Ansible的命令行方式执行，远程在INVENTORY文件hosts中配置的主机上执行shell模块的命令‘hostname‘，并返回详细的执行结果。执行的记录如下图所示, 从中可以看到Ansible的执行原理：

     

5、移动云Ansible实践

首先，让我们回顾一下移动云Anbile运维实践的历程。目前，移动云运维团队管理的物理机已增长至数千余台之多，Ansible工具在移动云运维中的使用是伴随着移动云的运维实践逐步发展而来，主要经历了以下几个阶段：

批量执行工具阶段。最初引入Ansible的时候，我们使用最多的是批量下发执行的功能。彼时我们的运维团队积累了大量的运维脚本和工具，在批量下发执行时使用shell循环或plink等批量执行工具，但在维护对象的数量快速增加之后，这种方法就不适用了。Ansible很好的解决了这个问题，而且它简单易上手，不需要我们对已有的工具脚本做任何改动，很快便得到了落地应用。

模块应用工具阶段。随着Ansible工具使用的不断深入，我们开始尝试使用Ansible的内置功能模块。Ansible提供了大量功能强大的模块，涵盖了日常运维管理的大部分常用功能。相对于直接编写脚本，Ansible内置的模块更为简洁、高效，而且Ansible具有幂等性的特性，可以只关注结果状态，而忽略过程细节，使得配置变更操作变得异常简单。Ansible的Playbooks提供了任务编排功能，可以将一个复杂的多步执行的运维事件分解为一个一个的play来执行。Playbooks使用yaml语言编写，上手起来也很简单，甚至不会写脚本和代码的小白也能上手。通过快速的转化和新增，我们积累了大量Playbooks。

炸弹已准备好，嘻嘻，只差一个火苗......

编排执行工具阶段。在积累了大量的Playbooks之后，Playbooks及其相互依赖关系的管理变得十分复杂，好在Ansible提供了Roles的功能。使用Roles的方式我们可以像开发代码包一样编写Playbooks，每一个Role完成对一个特定的独立的运维功能的封装，并可以方便的被调用，从而组合形成更为强大和复杂的功能，也有效解决了Playbooks的管理维护难题。

Web平台化工具阶段。在Ansible不断深入使用的同时，移动云维护团队自主开发的自动化运维平台陆续上线，DevOps的工具链也在不断应用和完善。Ansible在其中也扮演了重要的角色，如作为运维平台批量管理工具的后端，与DevOps工具链整合提供自动构建发布功能等。

接下来，介绍一下移动云Ansible应用实践的部分成果。

从管理的对象和积累的脚本规模上看，经过以上的积累，Ansible目前管理的主机及可用剧本数如下：

管理主机数	3K+
编排剧本数	100+
可分发组件数	20+
推送组件数	500+

从典型的应用场景上来看，Ansible在移动云新节点上线部署和组件推送安装等领域发挥了巨大的作用。

我们总结了新增、扩容资源池节点工程建设中系统层面的各类配置操作，转化为八大类配置场景，分别建立了Ansible剧本，如下图所示。在移动云后续的多期扩容建设中，尤其在工程实施阶段，Ansible工具发挥了巨大作用。只需要部署一台Ansible Server后，即可使用已有的各类剧本，完成系统初始化、基础组件安装等工作，大大提高了生产效率。

下图是一个典型的中间件推送相关的Ansible Roles的目录结构和Playbooks。

以此为基础，我们还在运维平台上开发了组件推送安装的功能。通过页面填写安装组件的主机、组件参数等信息后，调用对应组件安装的Roles来执行组件安装操作，从而提供了组件申请安装的自服务能力。

   

    在Web平台化工具开发和DevOps工具链应用方面，我们主要做了以下工作：

（1）、批量执行功能。

通过对Ansible的API进行封装，使用Ansible作为自动化运维平台批量执行功能的后台。授权用户登陆运维平台太后，可以在平台界面上选择执行用户、执行主机（组）、执行脚本及参数，由平台下发执行脚本并返回执行结果。

（2）、与资产信息库整合

之前，执行Ansible所需的用户名、密码等各类系统参数大多通过inventory文件的方式传入，其管理、安全性及一致性存在较大问题。为了有效整合各类基础信息资源，我们建立了资产信息库。有了资产信息库之后就可以免去inventory文件的配置，而从资产信息库中动态获取客户端IP，帐号，密码，端口等各类参数，有效解决了上述问题。

（3）、与DevOps工具链整合

在DevOps流程中，我们将Ansible相关功能模块开发的配置、脚本和yml文件等放置在内网的gitlab服务器上，使用git仓库的方式进行版本管理和团队协作。

此外，在我们的DevOps流程中扮演重要调度角色的工具--Jenkins的后台也是用Ansible工具作为支撑，通过Ansible插件功能实现自研工具软件的自动化部署和发布。

6、经验心得

又到showtime~~

就Ansible工具本身而言，它确实简单的可不思议。使用的经验和踩过的坑取决于你的使用方式和场景。就我们的经历而言，印象比较深刻的几点是:

（1）、权限的管理和安全问题。Ansible无中心节点，通过ssh方式连接客户端进行配置，因此权限管理和安全的问题比较突出，在运维团队人员较多，角色复杂的情况下，问题更为突出。通过运维平台进行权限的回收和管控是我们的解决方案。

（2）、环境依赖的问题。初期我们的Playbooks中有一些受执行环境影响的play，如ansible连接的用户、权限、文件的属性等。而我们维护对象存在多地多资源池的环境，在不同环境下执行的结果会受到影响。我们通过一方面规范Ansible的配置文件和执行条件，另一方面在play的编写中制定好每个play要达到的最终态，从而确保策略的执行不受环境的影响。

最后，还想多谈一谈。一路走来，Ansible工具使用的不断深入和优化的过程其实就是我们团队运维自动化发展历程的一个缩影。从最初的脚本运维，到集中的配置工具，到自动化运维平台，再到DevOps的流程和工具链应用。这似乎也是自然生长的运维团队的典型成长路径。而Ansible或其同类型的其他运维管理工具在运维工作中起什么作用、怎样使用、用的好不好，某种意义上讲，也反应了一个团队的自动化运维的能力和水平。

面对未来，你准备好了吗?

历史文章链接：