拿什么拯救你，我的Ansible
在自動化運維方面，我用過Chef,Puppet,Salt還有Ansible。
其中Chef和Puppet之前在線上用了很長一段時間，效果也都不錯。后來，我們希望嘗試一些新的工具，而Salt和Ansible都是通過Python實現(xiàn)的，加上我們的團隊也很喜歡用Python，所以就對二者進行了一些比較和試用。
就我個人而言，當時是比較推崇Salt的，因為看起來Salt更輕量級，跟Puppet在配置管理方面也非常相似，而且Salt的源碼看起來很舒服，結(jié)構(gòu)很簡單，很適合學習和做二次開發(fā)。
但Ansible看起來則似乎更獨特一些，通過SSH通道實現(xiàn)免Agent，同時在配置方面顯得更干練，也有豐富的模塊，能通過tags對每個配置項來進行靈活的分組。這些特點，得到了另外一些同事的大力肯定和推薦，在經(jīng)歷過幾次爭論之后，領(lǐng)導決定將線上所有的Puppet配置都遷移到Ansible上去。
在初期，使用Ansible感覺是比較新鮮的，還略微有點嗨，因為不再需要安裝Agent了，新服務(wù)器上線之后，把主機名加入hosts inventory，利用初始的root用戶密碼Push一次，整個配置任務(wù)就算完成了。
但在運行了半年多之后，在我們將所有的Puppet配置都遷移過來后，在不停的增加新的配置的情況下，我感到了痛苦，是真真正正的痛苦。
因為，我們目前很難確保線上的配置是完整的，上下邏輯是沒有問題的，是能夠適用于所有環(huán)境的。
而這些，不是Ansible的問題，是人的問題。
由于Ansible免Agent，所以每一次配置的更改，都需要主動的Push一次。在之前配置內(nèi)容不多，服務(wù)器較少的情況下，我們每次都直接把整個配置 Push一次。但隨著配置的增多，服務(wù)器數(shù)量增加到了一個相對飽和的程度時，我們絕大部分情況下都只需要對現(xiàn)有的服務(wù)器配置進行一些調(diào)整，例如增加或更新某個軟件，修改某個參數(shù)等。
在這種情況下，我們每一次的Push基本上都是通過tags來完成的，沒有人愿意在每次都將所有的配置都主動Push一次，沒有人會有這個耐心，因為使用tags來執(zhí)行我想要修改的部分，可能只需要10秒，而將整個配置都跑一次，則需要3分鐘甚至更長的時間。因此，日積月累，整個配置的完整性沒有了保障，大家更新過的地方，通過tags跑都沒有問題，但是拋開tags將整個配置Push一次的時候，就會發(fā)現(xiàn)，各種沖突和錯誤都出現(xiàn)了。
我曾經(jīng)寫過一個CDH5的role，在最開始部署集群時沒有一點錯誤，但是在維護了1個月之后，需要新上線一個新的CDH5集群時，這個role根本無法完成一個新集群的部署，我花費了足足2天來修復所有的報錯，我發(fā)現(xiàn)，在這1個月里，大家更新了很多的地方，通過那些綁定的tags在現(xiàn)有的環(huán)境中 Push，都不會報錯。
但其實有很多地方，是有沖突和邏輯問題的，很多僅需要在初始化的時候執(zhí)行的配置之后再也沒有執(zhí)行過，因為更新后的配置大家都是通過tags進行Push的，而Ansible在任何一個配置項報錯時都會中止。
這的確是人的問題，但這也是符合人性的。我們嘗試過不使用tags來Push，但之后所有的人都覺得這樣太過愚蠢，因為絕大部分時間都不會發(fā)現(xiàn)錯誤，只會浪費時間。而經(jīng)過一段時間之后，誰都不敢保證整個配置Push一次是沒有問題的，并且，殘酷的現(xiàn)實告訴我們，每次都會有錯誤出現(xiàn)。
為何之前在使用Puppet的時候，沒有遇到過這樣的困擾呢?因為，Agent的方式，每次都需要Pull所有關(guān)聯(lián)的配置，需要耗費一些時間，但由于不需要手動去Push，所以感受會不同，我們沒有覺得浪費了多少時間，也不用擔心更新之后其它的配置項會有問題。
這或許不是工具的問題，是我們沒有找到一個合適的方法來使用它。
但是，真的很難找到解決的辦法，強制所有人Push整個配置，或周期性的檢查整個配置，都難以實施下去。
該拿什么拯救你，我的Ansible。
原文鏈接：http://heylinux.com/archives/3245.html?utm_source=tuicool&utm_medium=referral
