最近對devops很感興趣，從而也開始接觸自動化運維工具，在網上查閱了很多關於ansible的資料，對ansible和saltstack等工具的爭論也很激烈，各說各的優勢，但是爭論了半天我總感覺這些工具和持續交付並不是一個目的。

首先來講，無論是ansible還是saltstack都是被稱為是“配置管理”的工具，那麽究竟什麽是“配置管理”呢？我的理解就是把對計算機進行的配置集中管理起來。

而且Ansible是一個聲明式的管理工具，在編寫腳本時使用的是聲明式語言，如：“我希望這臺機器的apache服務是啟動的”，那麽在執行時如果發現服務是啟動的則返回“ok”，如果服務沒有啟動則啟動它並返回“

舉個例子（如下表所示）：比如我希望在主機A、B、C上部署JDK1.7的環境，主機D、E、F上部署JDK1.8的環境，而又想在A、B上安裝Nginx；C、D上部署Tomcat；E、F上部署MySQL，這時候使用Ansible工具是最佳的。對於這種情況需要新建5個roles，分別是：JDK1.7、JDK1.8、Nginx、Tomcat、MySQL。對於A、B主機，安裝

環境需求表

對於以上案例的playbook執行入口應該如下表所示：

其次來講，網上也有人非要用Ansible做持續部署，如下圖代碼截圖。這個並沒有不可以，但是在啟停服務的時候往往使用的是CentOS 6的service httpd start/stop這種方式，因為Ansible內置了服務管理模塊service，用法為service： name=httpd status=stopped/started。但對於使用二進制或者源碼安裝的服務則無能為力，依舊需要使用shell： /PATH/resin.sh start方式啟動，而這樣也就起不到冪等性的效果，對於已經開啟的服務再次執行啟動同樣會報錯。其中可以明顯看出，roles字段就像搭積木，你需要什麽就網上加一個什麽。而對於這個角色的執行腳本都是寫好的，在入口引用就好了。

所以綜上所述，我認為Ansible更適合基礎設施運維/機房運維，而Jenkins更適合應用運維。

最後再來補充一句題外話，下圖是我在DevOps學院上摘抄的圖片（鳴謝趙班長及其主辦的運維社區：www.unixhot.com），這個體系是目前來講比較實用的架構，首先使用cobbler對裸機進行操作系統的自動化安裝，然後就會使用剛才說到的Ansible或者saltstack進行基礎軟件的安裝以及配置，然後就要對服務進行監控，做完這一切之後就是日常的部署上線工作了，在整個服務的生命周期中還會不斷的產生日誌，需要ELK日誌平臺進行收集和分析加工。而對於底層的硬件無論是物理機、還是虛擬機都無需關心，只需要做好CMDB的資源登記管理工作即可。這就是互聯網行業的一個基本的思路。

Ansible的應用場景分析