[b][size=large]it 自動化[/size][/b]
現在市面上用一些實現it自動化的工具，例如 puppet, chef, salt。ansible 是乙個相對比較新的工具，但目前社群十分活躍。我用過puppet和ansible。這裡想討論一下我偏愛ansible的原因。
[b][size=large]架構選擇[/size][/b]
puppet和chef這樣的工具使用的是master-agent 模式(或者說是拉模式)。在這種模式下，需要部署的節點上需要安裝**。這些**會定期向主節點傳送部署節點的狀態資訊。主節點再向部署節點傳送命令，以保證狀態的穩定。這樣做有一下幾個問題：
[list]
[*]安裝和使用**無疑**額外開銷和穩定性隱患
[*]定期確保狀態使得狀態的更改和應用的公升級變得十分困難，弊大於利.
[*]主節點成為單點故障和系統瓶頸，不利於線性擴充套件
[/list]
基於上述原因，不少人以及開始在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來說明依賴關係。
[b][size=large]** （provisioning）[/size][/b]
這裡的」provisioning」，我是特指主機的建立。 在很多情況下，provisioning是it自動化的一部分，特別是在基於雲的部署和自動化測試的情境下。 ansible提供了大量模組支援google compute engine (gce)， amazon web service(aws)已經其他環境下的provisionning。我個人使用過ansible了建立和銷毀gce節點。我也用過另乙個工具beaker。 它是puppet開發的測試工具，也支援provisioning。相比之下，ansible的gce模組更簡單，更豐富，也更穩定（特別是最近gce經常默默更改ssh和sudo的策略）。
[b][size=large]效能[/size][/b]
ansible是基於python的，理論上比基本ruby的puppet有更好的效能。無主節點的架構也省去了不少不必要的開銷。同時，ansible對於ssh的使用進行了很多優化(老版本的centos的openssh缺失不少效能優化）。當然我沒用看到具體的效能測試資料支援這一點。不過這不會妨礙我對ansible的偏愛。
ansible使用文件
假設a機器上安裝ansible yum install ansible vim etc ansible hosts 對每個主機加key認證 ssh copy id i ssh id rsa.pub root b ip ansible all m ping 乙個playbook檔案可以引入其他的yml...
Ansible 簡單使用
安裝 rpm uvh yum install y ansible 配置hosts vi etc ansible hosts aly ansible ssh port 10011 ansible ssh host 127.0.0.1 kaiping ansible ssh port 10013 ans...
ansible基本使用
ansible是個配置管理工具，可以批量處理一些任務。ansible只需要依賴ssh即可使用，而不需要在受管主機上安裝客戶端工具。ansible具有冪等性，即以結果為導向。比如，當我們拉取檔案到本地時，如果本地有該檔案則不再拉取，如果本地沒有該檔案則拉取。使用ansible需要滿足兩個基本條件 安裝...