配置管理工具，Ansible 1.9.0发布

Ansible 1.9.0（版本代号是Dancing In the Street，Ansible每个主要版本代号都是VanHallen乐队的一首曲子）的主要变化是：

• Added kerberos support to winrm connection plugin.
• Tags rehaul: added 'all', 'always', 'untagged' and 'tagged' special tags and normalized tag resolution. Added tag information to --list-tasks and new --list-tags option.
• Privilege Escalation generalization, new 'Become' system and variables now will handle existing and new methods. Sudo and su have been kept for backwards compatibility. New methods pbrun and pfexec in 'alpha' state, planned adding 'runas' for winrm connection plugin.
• ……

更多详情可以参考这里。

配置管理也是一个选择多多的领域，维基百科里洋洋洒洒列了十几二十个，其中Puppet、Chef和Salt以及CFEngine、Vagrant和NixOS大家都已经耳熟能详了。不过后起之秀Ansible的人气更高，GitHub上Star居然超过1万，远远高于Puppet和Chef的三四千，Salt的4953，只有非直接竞争的Vagrant的8000多能望其项背。

在Ansible公司网站上，推ter、Evernote、NASA、GoPro、Atlassian等知名企业都是他们的用户。

Ansible为什么这么火呢？我们从它的开始说起。

2012年2月，曾在Red Hat开发Cobbler和Func、又在Puppet工作过的Michael DeHaan看到了 IT自动化领域的机会：Linux管理员不得不用好几类工具来应付不同的工作——配置管理是Puppet或Chef，部署时要用Fabric或 Capistrano，还要Func或mCollective处理其他任务，总体上还是太复杂了。同时，多结点部署却没有工具处理得很好，而在云和大规模 互联网基础设施里，这恰恰是最有意思的问题。

一天，DeHaan在自己的沙发上开始用Python开发一个新工具，他的目标是：极为易用，连他自己都很想用；任何人可以在几分钟之内学会并用起来，而且6个月不用，还能很容易地想起来。这就是Ansible。

由于DeHaan在运维圈已经很有名气，Ansible发布后很快流行起来。这期间，Fedora的Seth Vidal（yum作者，2013年7月车祸身亡）的采用和4月High Scalability文章的发表，都非常关键。

这之后，DeHaan还参与了OpenStack的开发，但在用Puppet自动化OpenStack的过程中不断撞墙。这时候，Ansible在GitHub上火起来了。很快他决定成立公司——AnsibleWorks。2013年8月公司获得600万投资。

Ansible只依赖SSH，无需在远程机器上安装代理，上手极为容易。Hacker News上有人称之为(shell scripting)++，很到位。

DeHaan后来这样总结Ansible的成功原因：

关键的想法是，开发一个好的自动化系统，能认识计算机是一组而不只是一个个分开的机器，也就是所谓“多层编排”。建模过程与建模状态同样重要。 不按传统配置管理依赖定制代理架构的思路，避免了证书交换，以及反向解析DNS和NTP的问题。默认可插拔，人人都可以很容易地贡献，因此获得了广泛的参 与和采用。保持简单（用YAML等），制定计划并坚持，然后乐观其成。

Ansible 1.9.0的版本代号是Dancing In the Street，Ansible每个主要版本代号都是Van Halen乐队的一首曲子。对了，DeHaan在今年1月已经离开Ansible公司也不再太多参与Ansible社区，而是加盟DataStax（Cassandra背后的公司）任工程经理了。他告别文章的标题Happy Trails也是Van Halen的歌曲名。不过他在Hacker News上仍然活跃。

今天，在配置管理方面，Ansible和Salt是双星闪耀。那它们之间又该如何选择呢？

Hacker News上有很多相关讨论。其中两段比较说明问题：

Ansible要简单得多，本质上混合了声明式和命令式，在大型集群上性能可能差一些。Salt设置起来要重得多，有代理和服务器，有远程机器的元数据，而且很多术语和概念都是自己的一套。在小一些的环境（20-50台机器）里Ansible更合适。

SaltStack感觉功能更全、更强大。Ansible没有依赖图，有时候很难模块化。我自己是这么用的：Ansible启动Salt，然后让Salt干脏活累活。

小米运维博客有简明的介绍。


来自：http://geek.csdn.net/news/detail/29962