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公司網站上，Twitter、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幹髒活累活。
小米運維博客有簡明的介紹。