1.5 Ansible通信发展史
Ansible主推的卖点是其无需任何Daemon维护进程即可实现相互间的通信，且通信方式是基于业内统一标准的安全可靠的SSH安全连接。同时因为SSH是每台Linux主机系统必装的软件，所以Ansible无需在远程主机端安装任何额外进程，即可实现Agentless（无客户端），进而助力其实现去中心化的思想。尽管稳定、快速、安全的SSH连接是Ansible通信能力的核心，但SSH的连接效率一直被诟病，所以Ansible的通信方式和效率在过去的数年中也在不停地改变和提高。基于以上认识，我们先来了解Ansible SSH的工作机制，再来回顾其发展史。
1.Ansible SSH工作机制
Ansible执行命令时，通过其底层传输连接模块，将一个或数个文件，或者定义一个Play或Command命令传输到远程服务器tmp目录的临时文件，并在远程执行这些PlayComand命令，然后删除这些临时文件，同时回传整体命令执行结果。这一系列操作在未来的Ansible版本中会越来越简单、直接，同时快速、稳定、安全。通过了解其工作机制及其一直以来秉承的去中心化思想，我们可以总结，Ansible是非CS架构，自身没有Client端，其主要特点如下。
无客户端，只需安装SSH、Python即可，其中Python建议版本为2.6.6以上。
基于OpenSSH通信，底层基于SSH协议（Windows基于PowerShell）。
支持密码和SSH认证，因可通过系统账户密码认证或公私钥认证，所以整个过程简单、方便、安全。建议使用公私钥方式认证，因为密码认证方式的密码需明文写配置文件，虽然配置文件可加密，但会增加Ansible使用的复杂度。
支持Windows，但仅支持客户端，服务端必须是Linux系统。
如Ansible官方介绍，如上特性是希望实现以下最终目标：
Clear（简易）：YAML语法，Python语言编写，易于管理，API简单明了；
Fast（敏捷）：快速学习，设置简单，无需任何第三方软件；
Complete（全面）：配置管理、应用部署、任务编排等功能集于一身，丰富的内置模块满足日常功能所需；
Efficient（高效）：没有额外软件包消耗系统性能；
Secure（安全）：没有客户端，底层基于OpenSSH，保证通信的安全可靠性。
2.Ansible通信方式发展历程
Ansible底层基于安全可靠的SSH协议通信，但一直被人们诟病于其效率，通信功能作为Ansible最核心的功能之一，官方也一直在做改进。本节我们来了解Ansible通信发展史。
（1）Paramiko通信模块
最初，Ansible只使用Paramiko实现底层通信功能，但是Paramiko只是Python语法的一个第三方库，发展速度远不及OpenSSH。同时，Paramiko的性能和安全性较OpenSSH稍逊一筹（在笔者眼里）。
在后续发布的新版本中，Ansible仍继续兼容Paramiko，甚至在诸如RHEL 56等不支持ControlPersist（只在OpenSSH 5.6+版本中支持）的系统中封装其为默认通信模块。
（2）OpenSSH
从Ansible 1.3版本开始，Ansible默认使用OpenSSH连接实现各服务器间通信，以支持ControlPersist（持续管理）。Ansible从0.5版本起即支持OpenSSH功能，但直到1.3版本开始才将其设置为默认。
多数本地SSH配置参数，诸如Hosts、公私钥文件等是默认支持的，但如果希望通过非默认的22端口运行命令等操作，则需要在Inventory文件中配置ansible_ssh_port的值。OpenSSH相比Paramiko更快、更可靠。
（3）加速模式
据官网介绍：开启加速模式后Ansible通信速度有质的提升，是开启ControlPersist后的SSH的2～6倍，是Paramiko通信速度的10倍。
尽管加速模式对Ad-Hoc命令不友好，但是Playbook通过加速模式会收到更高的性能。加速模式抛弃SSH多次连接的方式，通过SSH初始化后，带着AES key的初始化连接信息通过特定的端口（默认5099，但可配置）执行命令传输文件。使用加速模式唯一需要的额外包是python-keyczar，如此一来，几乎所有的常规模块OpenSSHParamiko均工作在加速模式，但如下使用sudo的情况例外：
1）sudoers文件需要关闭其中的requiretty功能，注释掉或者设置每个用户的默认值为username !requiretty。sudoers的man文档说明如下。
requiretty
If set, sudo
will only run when the user is logged in to a real tty. When this flag is set, sudo can only be run
from a login session and not via other means such as cron(8) or cgi-bin
scripts. This flag is off by default.
2）开启加速模块必须事先设置sudo文件NOPASSWD配置，禁用sudo后的PASSWORD交互认证过程。加速模式相对OpenSSH可以提供2～4倍的性能提升（尤其对于文件传输功能），在Playbook的应用中可以通过增加配置开关来实现。
---
- hosts all
accelerate true
accelerate_port
5099
[...]
其中的端口也可以在ansible.cfg中单独配置。
[accelerate]
accelerate_port
= 5099
加速模式是现在已经被废弃的Fireball模式的进化版，类似于Ansible加速通信方式，但需控制机事先安装ZeroMQ服务（这与Ansible简单、无依赖、无Daemon的理念是相违背的），并且一点也不支持sudo操作。
（4）Faster OpenSSH in
Ansible 1.5+
Ansible 1.5+版本中的OpenSSH有了非常大的改进，旧版本中实现方式是复制文件至远程服务器后运行，然后删除这些临时文件，而新版本的替代方案是通过OpenSSH发送执行命令，将所有操作附带在SSH连接过程中同步实现。该方式只在Ansible
1.5+版本有效，且需在etcansibleansible.cfg的[ssh_connection]区域开启pipelining=True功能。
关于加速模式我们还需要关注如下内容：
pipelining=True需结合sudo的requiretty配置方可生效，请确保etcsudoers的Defaults requiretty为注释状态。绝大多数现有流行系统默认开启该选项。
在Mac OSX、Ubuntu、Windows的Cygwin或其他流行OS最好选择5.6以上的OpenSSH版本，这些版本对ControlPersist有更友好的支持。
如Ansible运行的主机系统是RHEL或CentOS，然而希望升级当前OpenSSH到最新版本以支持FasterPersistent连接模式，可以通过yum update openssh升级最新版本。
本节内容可以通过如图1-1所示的Ansible通信方式发展史鱼骨图来概括，从最开始的Paramiko，后来初步演变为OpenSSH，加速模式官方推荐Pipelining方式。
在了解Ansible通信原理及发展史后，我们进一步学习Ansible自身的发展史。要知道，在Chef、Puppet、SaltStack、Fabric等自动化工具群雄争霸的市场背景下，Ansible依然能够杀出重围，在GitHub取得如此惊人成就，并且被红帽官方收购，其发展史不得不让人刮目相看。