为何使用Ansible

IT 自动化

现在市面上用一些实现IT自动化的工具，例如 puppet, chef, salt。Ansible 是一个相对比较新的工具，但目前社区十分活跃。我用过puppet和ansible。这里想讨论一下我偏爱ansible的原因。

架构选择

Puppet和chef这样的工具使用的是master-agent 模式(或者说是拉模式)。在这种模式下，需要部署的节点上需要安装代理。这些代理会定期向主节点传送部署节点的状态信息。主节点再向部署节点发送命令，以保证状态的稳定。这样做有一下几个问题：

• 安装和使用代理无疑代理额外开销和稳定性隐患
• 定期确保状态使得状态的更改和应用的升级变得十分困难，弊大于利.
• 主节点成为单点故障和系统瓶颈，不利于线性扩展

基于上述原因，不少人以及开始在puppet应用中使用无主节点模式 master-less mode。相比之下，ansible没有主节点和代理。它仅仅依赖于SSH，使得应用的部署简单而轻量。更重要的是，ansible很好的支持了持续交付。这是一个例子。当然，如果需要，使用playbook或者ansible tower你也可以让ansible定时检查系统状态。但是，我个人认为，应用的运行状态，往往更应该使用Nagios这样的工具进行检测和预警。

一个好的IT自动化工具应该令其脚本开发简单而易于理解。这里的脚本，Puppet称其为manifest, Chef称其为cookbook，Ansbile称其为playbook。 Puppet manifest和Chef cookbook都是基于ruby的DSL，而ansible playbook是YAML。除非你已经很熟悉ruby，大多数人会觉得playbook更容易写。至于易读性，puppet manifest中需要处处显式说明依赖关系。在中大型项目中，很难理解依赖关系。Ansible默认执行是顺序的。仅仅在需要的时候，使用notify和handlers来说明依赖关系。

供应 （Provisioning）

这里的”provisioning”，我是特指主机的创建。 在很多情况下，Provisioning是IT自动化的一部分，特别是在基于云的部署和自动化测试的情境下。 Ansible提供了大量模块支持Google Compute Engine (GCE)， Amazon Web Service(AWS)已经其他环境下的Provisionning。我个人使用过Ansible了创建和销毁GCE节点。我也用过另一个工具Beaker。 它是puppet开发的测试工具，也支持provisioning。相比之下，Ansible的GCE模块更简单，更丰富，也更稳定（特别是最近GCE经常默默更改ssh和sudo的策略）。


性能

Ansible是基于python的，理论上比基本ruby的puppet有更好的性能。无主节点的架构也省去了不少不必要的开销。同时，Ansible对于ssh的使用进行了很多优化(老版本的centos的OpenSSH缺失不少性能优化）。当然我没用看到具体的性能测试数据支持这一点。不过这不会妨碍我对ansible的偏爱。