Ansible的應用場景分析

Ansible的應用場景分析

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

首先來說，不管是ansible仍是saltstack都是被稱爲是「配置管理」的工具，那麼究竟什麼是「配置管理」呢？個人理解就是把對計算機進行的配置集中管理起來。

並且Ansible是一個聲明式的管理工具，在編寫腳本時使用的是聲明式語言，如：「我但願這臺機器的apache服務是啓動的」，那麼在執行時若是發現服務是啓動的則返回「ok」，若是服務沒有啓動則啓動它並返回「changed」。那麼相比shell這種「命令式」語言，聲明式語言更智能，由於若是用shell啓動apache，若是發現服務已經啓動，則會返回「端口被佔用」的錯誤，並異常退出，返回碼非0，這樣就會致使後面的腳本中斷執行，是很煩人的一種狀況。

舉個例子（以下表所示）：好比我但願在主機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主機，安裝JDK1.7和Nginx的roles，C主機安裝JDK1.7和Tomcat的roles；D主機安裝JDK1.8和Tomcat的角色，E、F主機安裝JDK1.8和MySQL的角色。換句話講，Ansible就是對於各類環境的搭積木式組合，你須要什麼環境，我就給你裝上什麼環境，對於系統管理員來說，沒必要再去每一臺機器上根據開發給的需求名單一個一個安裝，不只效率低、勞動成本高、並且容易出錯，形成環境的不一致。而Ansible具備冪等性的特色，不管執行多少次，只要你的操做系統是同一個版本，那麼安裝出來的環境絕對是同樣的，這樣也就保證了應用所處的底層環境的一致性，而不會形成同一個版本的應用在不一樣的機器上運行出現不一樣的效果的問題。

環境需求表

Hosts	所需環境		服務名稱
A	JDK1.7	Nginx	LVS
B	JDK1.7	Nginx
C	JDK1.7	Tomcat	WEB-1
D	JDK1.8	Tomcat	WEB-2
E	JDK1.8	MySQL	MySQL
F	JDK1.8	MySQL

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

其中能夠明顯看出，roles字段就像搭積木，你須要什麼就往上加一個什麼。而對於這個角色的實際執行腳本都是寫好的，在入口引用就行了。

其次來說，網上也有人非要用Ansible作持續部署，以下圖代碼截圖。這個並無不能夠，可是在啓停服務的時候每每使用的是CentOS 6的service httpd start/stop這種方式，由於Ansible內置了服務管理模塊service，用法爲service：name=httpd status=stopped/started。但對於使用二進制或者源碼安裝的服務則無能爲力，依舊須要使用shell：/PATH/resin.sh start方式啓動，而這樣也就起不到冪等性的效果，對於已經開啓的服務再次執行啓動一樣會報錯。

 

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

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