1.3 Ansible特性

Ansible是基于一致性、安全性、高可靠性设计的轻量级自动化工具，具有功能强大、部署便捷、描述清晰等特性。对于管理员、开发者、IT经理等都容易上手，学习曲线较低，能够快速理解、掌握Ansible的自动化体系，满足不同技术级别的用户需求。

同时Ansible是一款满足当代大规模、复杂环境的IT基础架构自动化管理的工具。Ansible相对与其他自动化解决方案，在核心能力上效率更高。也很好地解决了统一配置、统一部署、流程编排等复杂的IT自动化管理问题。下面就介绍其功能特性以及与其他工具的对比。

1.3.1 Ansible功能特性

从功能上看，Ansible可以实现以下目标：

·应用代码自动化部署。

·系统管理配置自动化。

·支持持续交付自动化。

·支持云计算、大数据平台（如AWS、OpenStack、CloudStack、ⅤMWare等）环境。

·轻量级，无需在客户端安装agent，更新时只需在控制机上进行一次更新即可。

·批量任务执行可以写成脚本，不用分发到远程就可以执行。

·使用Python编写，维护更简单，Ruby语法过于复杂。

·支持非root用户管理操作，支持sudo。

实现上述目标是很有挑战性的工作，需要满足健壮性、易于管理的架构，这在应用维度一直没能很好地解决，因为管理工具不能对被管环境施加额外的影响，而Ansible很好地解决了这些问题。Ansible作为优秀管理工具具备以下一些特点。

1．语法简单、易读

Ansible的配置管理脚本playbook语法基于YAML，它是一种可读性高、用来表达数据序列的格式标准。YAML参考了ⅩML、C、Python、Perl以及电子邮件格式RFC2822等其他多种语言，可读性好、交互性强，使用了实现语言的数据类型，有一个一致的信息模型，可以基于流方式来处理，具有表达能力强、扩展性好等特点。

可以把playbook称为“可执行的文档”，就像README文件一样描述你需要部署软件的指令，由于这些代码是可以直接执行的，这些指令永远不会过时。

2．不需要在被管节点安装客户端软件

Ansible项目管理系统的核心是通过SSH来连接被管节点，可以使用paramiko（一个Python库）或使用原生的OpenSSH（带参数-c ssh）。当使用SSH客户端连接时候，默认的OpenSSH连接是可以重用的。无论哪种方式，SSH都是作为一种传输方式，不是作为一种执行的Shell。

模块是包含一些参数的Ansible小程序，通过SCP或SFTP传送到远端被管机器的临时目录中进行执行，然后再删除。这些模块通过标准的输出方式返回JSON格式的数据，这些返回的数据通过控制主机上的Ansible程序进行处理。

这种方式能管理非常多远程活动，并且只需要很小的交互流量。模块按照“幂等资源”的方式进行管理，也就是发起多次执行也不会给服务带来负面响应。它不是简单的命令或脚本，例如一个模块可以确定应该安装某个特定版本的软件包，但如果这个系统已经有合适的工作状态，就不会再执行任何命令。这种方式有如下优点：

·提高网络安全：由于不需要在远端被管节点上运行agent，因此Ansible遭受攻击的机会很少。只需要运行OpenSSH一个后台进程，它在全球范围内是最严格审查的程序之一。Ansible知道做好加密是一项极其艰难的事情，因此没有考虑使用自己的后台进程和认证方式，而是依赖可用的最安全的远程管理系统。OpenSSH极其广泛地在各种系统中使用，有时非常轻量级。一旦OpenSSH出现安全问题，将会非常快速地推出补丁修复。当我们认为可能编写一个安全的OpenSSL实现时，我们也一直跟踪远程拓展在这一应用领域的类似工具，期望尽量避免出现类似问题。

·可以使用非root用户访问（可用sudo）:Ansible的playbook能够用任何用户账号登录远程系统，可以用初始连接的用户来运行程序，也可以使用sudo切换到其他用户（包括root）。如果需要可以直接用root登录，sudo可以需要口令，也可以不需要口令，当管理的一些系统根本不能使用root登录的时候，或者不允许root登录但可以通过sudo切换到root的，这些方式是非常合适的。这里有个例子，一个没有超级权限的用户能够用Ansible管理自己home目录下的内容，即使在这个系统上没有root或sudo权限。甚至当使用sudo时，文件传输是没有限制的。Ansible也包含一个兼容sudo的文件传输工具，内容是按照正常的SFTP方式传输的，Ansible会把文件复制到授权的位置。通过比较源文件和目标文件的校验和方式，Ansible能够智能地识别文件是否需要传输。

·限制传输潜在敏感数据：Ansible总是尽量把最少的数据传输到被管节点，由于控制服务器是逻辑控制中心，只有远端被管节点必要的变量才送给它。例如，有一个全局变量叫foo，只有在远端被管节点中明确在资源或模板中使用它，否则它不会发送到该远端节点。这种Ansible的推送方式，只给远端节点需要看到的最少数据。类似地，Ansible没有包含客户文件服务器的实现，只通过SFTP、SCP、Rsync（基于SSH）传输文件，并且只有playbook需要的文件才传输。结果是被管节点请求的文件或模板可以提供，但敏感数据不会提供给。也就是不能给一台远程主机查看将要提供给其他被管节点的数据。这使得Ansible适用于带有敏感数据的环境，包括社会科学工作、健康医疗、政府政务等应用。

·（Credential Segregation凭证隔离）:Ansible适用于不同用户有不同安全级别的环境。可以定义管理主机的通用变量，然后使用自己的凭证访问远端节点。例如，允许研发工程师管理开发的服务器，QA工程师管理QA的服务器，系统管理员管理生产环境服务器，不存在研发工程师把代码推送到生产环境的风险。

·去中心化：由于Ansible的playbook需要用户的凭证来执行，不存在中心点，只是通过访问配置内容、管理软件链条，不需要访问SSH密钥，就可以接管建立“僵死网络”，避免使它成为攻击的目标。用户可以加密自己的密钥，不需与任何人使用相同密码。在可选的管理形式中，访问授权的软件资源都有可能导致部署系统自动化。要使用Ansible，用户需要两个条件：能够访问到资源库，具有管理远端节点的凭证。当使用锁定的密钥（甚至是密码）时，不存在暴露安全漏洞中心被攻击点，也不允许从远端硬件来访问管理服务器。

·没有“管理的管理程序”的问题：许多配置管理解决方案的主要问题之一是“管理的管理”，为了开始管理服务器必须先在远端节点上安装软件。当更新管理软件时候，通常各种agent需要先更新（许多系统是无法自己自动更新的）。有时会产生管理服务器与agent软件版本兼容性问题，或agent与运行语言版本问题，Ansible通过基于SSH传输模块避免了这类问题。SSH二进制代码已经是OS的一部分了，并且是每个主流操作系统的核心。不需要任何agent，也就不存在agent以任何方式崩溃的问题，因此服务器存在的安全风险是非常小的。

·管理服务器的可扩展性：由于Ansible使用推送方式来管理远端节点（当然，也很容易配置成远端节点查询更新的方式），因此Ansible对于“羊群效应”的管理问题是有免疫能力的。在其他的一些解决方案中，管理agent周期性检查会对管理服务造成破坏，经常会超过管理服务器的运行负荷，导致需要对管理服务器进行横向或纵向扩展。频繁管理服务器需要为远端节点消耗昂贵的计算资源。为了解决这个问题，Ansible通过推送的方式，通过配置每次推送节点数量来做限制。均衡了远程节点需要的管理服务器的负载能力，可以让计算系统负载更加均衡，即使个人笔记本电脑也可以作为Ansible系统的控制服务器。

·资源的利用：在Ansible不管理远端节点时，这些远端节点什么也不做，也就是没有后台进程在消耗CPU、内存。曾经报道过，某些应用服务器在唤醒配置窗口时会产生明显的降低性能，某些agent可能会占用超过400MB的内存。在虚拟化环境中，这些资源的消耗可能会快速叠加，就会增加对硬件的支出。Ansible能最大限度让你的关键性能负荷使用所有的计算资源，你也可以选用间隔方式运行管理程序，也不存在由于内存泄漏或agent软件崩溃导致无法管理远端节点的问题。

·防火墙的友好性和确定性：不像某些基于消息总线的系统，Ansible不需要长时间在控制节点与被管主机之间建立连接。在生产环境，这种长连接可能受限于防火墙，防火墙一般不喜欢长连接，Ansible很好地规避了这个问题。当管理服务与应用之间的连接被断开又没法重置的时候，就只能等到重启agent端服务了，Ansible没有这个问题。没有严格意义上的无代理系统，Ansible也避免在这些架构中的其他问题，获得确定性的响应。并不是只有出现响应节点才管理，对于你要管理但无法达到的就静默了。如果一个节点宕机，运行Ansible时你就会知道，将会返回一个失效信息，这个你可能忽略或修复。这对于你给所有节点或部分子集部署软件更新，是很重要的信息，知道哪些节点无法连接是非常重要的，而对“发布-订阅”架构通常是没有提供这些信息的。

3．基于推送（Push）方式

有些配置管理系统（如Chef、Puppet、Saltstack等）是使用代理模式的，它们默认基于拉（pull）方式。被管节点上安装代理后，代理服务将周期性检查中心控制主机的服务，并从控制主机上取来配置信息。被管节点的变更过程大致如下：

1）修改配置管理脚本。

2）把修改好的管理配置脚本推送到中心控制主机上。

3）被管节点的代理服务周期性触发检查。

4）被管节点连接配置管理的控制主机。

5）被管节点下载新的配置管理脚本。

6）被管节点在本地执行配置管理脚本，被管节点状态相应地变化。

而Ansible默认基于推送（push）方式，管理过程如下：

1）增加或修改playbook。

2）执行新的playbook。

3）控制节点的Ansible连接被管节点并执行修改被管节点状态的模块。

一旦你执行ansible-playbook命令，Ansible就会连接到远程的被管节点并按照脚本要求执行。

基于推送方式有很大的优势，你能控制什么时候让远程被管节点发生变更，不需要等到被管节点上周期性的时间。拉方式的支持者声称拉方式具有管理服务器规模数量的优势，新被管节点随时可以在线添加。但是Ansible已经在管理超过上万台节点规模的系统，很方便地动态增减或删除被管节点。

当然，如果你一定要使用拉方式，Ansible官方也已经支持这种拉方式，可以使用ansible-pull这个工具。

4．方便管理小规模场景

Ansible能够管理成千上万台主机，但如何管理缩小规模的场景呢？其实，用Ansible也很容易配置小规模集群甚至单台主机，你只要简单编写一个playbook即可。Ansible遵循艾伦·凯（Alan Kay）的名言：“简单的东西应该简单，复杂的东西才有可能成功（Simple things should be simple, complex things should be possible）”。

5．大量内置模块

使用Ansible能够在被管节点上执行任何shell命令，但是Ansible真正的威力在于内置大量的模块。使用这些模块可以完成如软件包安装、重启服务、拷贝配置文件等操作。Ansible模块是声明式的（declarative），你只需使用这些模块描述被管节点期望达到的状态。例如，你可以用user模块对用户授权，确保系统有一个deploy用户，并且属于web组，代码如下：

        user: name=deploy group=web

Ansible内置模块都是等幂性的（idempotent）。这就是如果系统中没有用户deploy, Ansible将会创建一个deploy账号；如果这个账号已经存在，则Ansible什么也不做。等幂性对于自动化维护是非常重要的特性，这样在被管节点上多次执行Ansible的playbook也能达到同样效果。相对于直接执行操作系统脚本的方式是巨大的改进，操作系统脚本再执行一次可能就会产生不同的、非预期的结果。

什么是收敛性

配置管理的资料中经常提到“收敛”这个概念，在配置管理中收敛最切确的说法是在Mark Burgess以及他的CFEngine配置管理中所写的。

如果一个配置管理系统是收敛的，那么这个系统可以多次运行，都达到最终期望的状态，每次执行只是更加接近而已。

这个收敛的思想在Ansible中不完全适用，Ansible没有在被管节点上多次运行的概念，Ansible在模块中实现了这种方式，一次执行playbook就会确保每台被管节点都能达到期望的状态。

“等幂性”和“收敛性”是有差别的，而且有非常重大的差异。等幂性是指如果系统已经处于期望的状态，则对系统什么也不操作。而收敛性是指系统不需要变更或操作的特性。最终的结果可能一样，但CFEngine相对于等幂性更强调收敛性，并且在自动化系统中内嵌了大量的逻辑，避免执行不必要的操作。

6．非常轻量级的抽象层

有些配置管理工具通过一个抽象层，可以把相同的脚本在不同的操作系统上管理。例如，安装软件包有yum、apt工具，对于配置管理工具就可能抽象成package。

Ansible不同于这种方式，你需要使用apt模块来安装基于apt软件管理的系统，用yum模块来安装基于yum软件管理的系统。

这听起来也许不太方便，在实践中我们发现这使得Ansible更方便使用。Ansible不需要再学新知识来屏蔽不同操作系统的差异性、新的抽象环境。这相对减少了Ansible要求的知识领域。这样，你不需要了解太多就可以编写playbook了。

如果你确实需要，你也可以在Ansible的playbook中对不同被管节点的操作系统编写不同的动作脚本。但不太建议这么做，建议编写针对特定操作系统的playbook，如CentOS、Ubuntu。

Ansible社区中最主要的重用是模块，模块都是比较小的，与特定操作系统相关，具有良好的定义，容易实现，方便共享。Ansible项目是非常开放的，经常接纳社区贡献的模块代码。

Ansible的playbook不是真正地在不同上下文之间能够重用，本书后面讲到的roles方式整合playbook是更好的重用方式，大量在线的roles资源库收集在Ansible Galaxy中。现在已经超过4000个。

工作实践中，每个单位配置的服务器有所差异，应最好为自己的单位编写playbook，而不是尝试重用通用的playbook。查看其他人的playbook主要是学习人家如何做到的。

目标是提供面对广泛的自动化挑战如何获得大型生产力的优势。当Ansible提供更强大的生产力逐步替代其他许多核心性能的自动化解决方案时，它也在寻求解决其他还没解决的IT挑战，如何将复杂多层级工作流程清晰化、清楚统一地配置OS、在单一框架下进行应用软件的部署。

1.3.2 Ansible与其他配置管理的对比

当前几款与Ansible功能类似的主流配置管理软件有Chef、Puppet、SaltStack等，这里只对各个软件的技术特性做个简单对比，其中不针对各个软件的性能作比较。具体内容见表1-2。

与其他的自动化工具相比较，Ansible不需要安装管理客户端就能轻松地管理、配置你的基础架构。它们各自的优缺点见表1-3。

这些自动化管理软件都具备强大的功能、灵活的系统管理和状态配置，都提供丰富的模板及API，对云计算平台、大数据都有很好的支持。

Puppet、Chef、SaltStack设置比较复杂，有代理和服务，有远程被管节点需要长期运行管理进程，而且很多术语和概念都是自己一套。Ansible相对于其他产品要简单得多，本质上混合了声明式和命令式。不仅适用于大规模的IT环境，而且对于一些规模较小的环境（20～50台机器）Ansible也是很实用的。