本文講的是自動化工具後起之秀Ansible的部署實踐，從早期手動加腳本的部署方式，到後來自動化工具（chef, puppet, saltstack, ansible等）的出現，再到如今DevOps的盛行，企業應用部署正式進入平台部署階段，CD（持續部署）已經成為企業對應用部署的标準需求，運維的傳遞也不再是以周或天為機關，而是以分鐘為機關。
本文主要介紹自動化工具Ansible，及其在普元DevOps平台中的應用部署和日常應用部署中的實踐。
本文目錄：
一、如何選擇合适的自動化工具？
二、Ansible架構圖及工作流程
三、DevOps基于Jenkins+Ansible+GitLab的部署實踐
四、Ansible日常應用部署實踐
五、總結
面對衆多的自動化工具（chef, puppet, saltstack, ansible等），我們該如何選擇适合自己的呢？總的來說，無外乎從以下幾點來權衡利弊。
活躍度（GitHub活躍度，社群活躍度）
學習成本
使用成本
編碼語言
性能
各種開源的自動化工具在GitHub的關注度是其活躍度最直覺的展現，從圖中Contributors這一項就可以看出Ansible和SaltStack的開源項目貢獻者遠遠多于其它幾種自動化工具。越活躍的開源項目往往意味着更完善的功能和更高效的問題解決率。
Ansible Galaxy和Salt Formulas都提供了豐富的第三方工具，基本覆寫了日常部署應用的所有需求。
Puppet和Chef使用的開發語言是Ruby，而Saltstack和Ansible使用的開發語言則是在運維開發這個圈子相對吃得開的Pythen，這也是SaltStack和Ansible相對于Puppet和Chef更容易被接收的原因。
很多選擇Ansible的朋友，大多都是覺得Ansible上手簡單，因為Ansible預設采用SSH連接配接的方式，不需要安裝配置Client，隻需要在Server端配置SSH連接配接資訊即可。這也是Ansible相對其他自動化工具的一大優勢，但是這一優勢帶來的影響就是實作機制的差異導緻在大規模環境下，Ansible的性能确實要比SaltStack差很多，當然，規模大概在一兩百台機器左右Ansible的性能也是可以接受的。如果是做少量機器應用部署的話，性能問題也就不是那麼關鍵了。
綜合以上因素，最後我們選擇Ansible作為我們DevOps部署功能底層實作的自動化工具。
先來看看這張架構圖（來源于網絡），看起來是不是很簡單，首先對Ansible架構圖的各個組成部分作一個說明。
核心引擎：即圖中所看到的Ansible。
核心子產品（Core Module）：和大多數運維工具一樣，将系統和應用提供的能力子產品化，一個子產品有點像程式設計中一個功能接口，要使用的時候調用接口并傳參就可以了。比如Ansible的service子產品，你要保證名為nginx的service處于啟動狀态，隻需要調用service子產品，并配置參數name: nginx，state: started即可。
自定義子產品（Custom Modules）:顯而易見，如果Ansible的核心子產品滿足不了你的需求，你可以添加自定義化的子產品。
插件（Plugins）：子產品功能的補充，如循環插件、變量插件、過濾插件等，也和子產品一樣支援自定義，這個功能不常用（我沒用到過），就不做細說了。
劇本（playbooks）：說到這個，先說說Ansible完成任務的兩種方式，一種是Ad-Hoc，就是ansible指令，另一種就是Ansible-playbook，也就是ansible-playbook指令。他們的差別就像是Command指令行和Shell Scripts。
連接配接插件（connectior plugins）:Ansible預設是基于SSH連接配接到目标機器上執行操作的。但是同樣的Ansible支援不同的連接配接方法，要是這樣的話就需要連接配接插件來幫助我們完成連接配接了。
主機清單（host inventory）:為Ansible定義了管理主機的政策。一般小型環境下我們隻需要在host檔案中寫入主機的IP位址即可，但是到了中大型環境我們有可能需要使用動态主機清單來生成我們所需要執行的目标主機（需要雲環境支援動态生成Ansible host inventory）。
Ansible工作流程大緻就是這個樣子，之後在日常應用部署實踐部分對一個應用部署的調用流程再做說明。
三、DevOps基于
Jenkins+Ansible+GitLab的部署實踐
既然已經決定用Ansible來完成應用部署的底層實作，那我們如何将Ansible和DevOps結合起來呢？
首先想到的是API，Ansible倒是有一套Python的API接口，但想來在DevOps中做Ansible Python接口的內建封裝不太容易，再就是Ansible通過指令行提供服務，并沒有啟動程序及監聽端口，沒想通如何在DevOps中調用Ansible接口，自己對Python亦不是太熟，是以便放棄了這種方式。
之後便了解到了Ansible Tower，Ansible Tower是Ansible的web界面，采用REST API作為接口，先安裝起來看看效果。
上圖為首頁及任務執行頁面截圖，從它相對簡潔的頁面我們就能看出它提供的大部分功能。
首頁推送最近使用的Job和最近Job執行情況。
主機管理。
實時的playbooks輸出和浏覽。
執行曆史資料預覽及報表。
基于角色的通路控制。
REST API。
任務頁面截圖是一個安裝部署Nexus的Task，在它的曆史任務執行頁面可以清晰的看到任務執行的實時輸出，任務執行的變量資訊，以及任務每一步的耗時情況等。
Ansible Tower看起來還是挺不錯的，不僅提供了主機管理，任務管理，任務曆史及實時輸出等能力，還提供了直覺實用的報表。奈何，因為它收費的原因，還是被PASS掉了。
正苦思冥想之際，有幸得見一篇文章《Jenkins+Ansible+Gitlab自動化部署三劍客》，文中提到的這種使用方式與我們DevOps本身的很多設計點不謀而合。
在CI（持續內建）的設計上，我們本身也是将Jenkins作為內建工具來使用的，同時Jenkins2版本的Pipeline as Code也給CD（持續部署）帶來了無限的可能。當然，也增加了一定的學習成本，那就是Pipeline的核心Groovy，一種基于JVM（Java虛拟機）的靈活開發語言。
Jenkins給我映像較深的一點就是它強大的擴充性，它同樣支援Ansible的擴充插件Ansible plugin，在Pipeline中使用插件和其他類型的Job略有不同，建立一個Pipeline Job之後，可以使用Pipeline Syntax配置插件和參數，然後Jenkins會自動生成可以在Pipeline中使用的代碼片段。
再來說GitLab，當然，也可以是其他Jenkins支援的代碼版本控制系統。它在整個過程中擔任什麼樣的角色呢？試想，我們所需要管理的部署機器和産品對應着的部署腳本，如果單單隻是儲存在某個Server端，如何進行編寫維護以及更新，如何形成運維日積月累過程中的經驗與知識産物。
這裡GitLab可以很好的幫助我們進行Playbooks的管理，我們隻需要将Playbooks送出到倉庫，然後在通過Jenkins執行部署之前，将Playbooks拉取到Job的workspace中，然後調用執行就可以了。
如何将DevOps與這種Jenkins+Ansible+GitLab的實作方式結合起來呢？
我們DevOps部署大緻操作流程如下：
資源：建立部署需要的環境資訊，可以是實體機，虛拟機以及容器雲環境。
設計：設計部署容器，比如部署mysql和tomcat并設定tomcat依賴mysql的關系。然後送出設計。
轉換：配置部署政策以及部署模式，設定部署容器的參數，建立部署計劃并執行部署。
運維：部署容器運維，啟停、解除安裝、伸縮、復原等操作。
實作方式大緻可以簡化為：根據模闆化的表設計動态生成部署配置頁面，頁面參數傳遞結合靜态的部署模闆（groovy）生成Jenkins的config.xml檔案，然後調用Jenkins的API接口建立Jenkins的部署Job。
那我們要進行一個部署容器的擴充，我們需要做哪些工作呢？
1.在模闆化的表設計中新添加部署容器（如mysql）的相關資訊（元件依賴，屬性定義字段等）。
2.按照既定的規則在腳本目錄添加groovy模闆（安裝，解除安裝，運維等）。
3.在腳本庫中添加groovy模闆中對應調用的ansible playbooks。
因為DevOps應用及其內建的第三方工具也需要自動化部署，剛好又接觸了Ansible這樣一款自動化工具，是以就寫了一套快速部署DevOps應用及一些第三方工具的playbooks。
單看這張圖，大家可能覺得有點不明是以，我們結合DevOps平台部署的playbooks目錄結構及檔案類容對此部署設計做一個說明。
Ansible機器分組：就是Ansible的host inventory檔案，内容為機器分組資訊及組變量，在DevOps平台部署中擔任配置檔案的角色，部署前隻需要修改此檔案即可（修改應用的安裝配置和對應每個分組的部署機器）。
DevOps部署角色：對應的site.yml是應用部署的入口檔案，這裡将DevOps應用分成8個角色，分别是devops、mysql、jenkins、nexus、sonarqube、gitlab、cmdb、jira。每個部署角色對應多個role。
Ansible Role：可以了解為Ansible中可複用的最小的操作單元，這裡考慮的不隻是DevOps的部署了，考慮到playbooks檔案在今後的日常使用中也會使用到，比如要安裝一個jenkins，隻需要在inventory中添加機器資訊，然後定義入口檔案使用repo（考慮到無外部網絡通路權限情況，配置内網源）和jenkins兩個role即可。
執行指令行ansible-playbook –i devops.inventory site.yml即可開始執行部署，首先會根據site.yml入口檔案中hosts中配置的資訊去devops.inventory中擷取主機及主機變量資訊，然後根據remote_user配置和ansible.cfg中配置的SSH連接配接資訊去執行連接配接，然後根據roles配置的角色去執行相應的Task。接下來我們看看Ansible Role的目錄結構和内容。
Roles主要依賴于目錄及檔案的命名和擺放。目錄說明如下：
file：copy子產品檔案預設路徑，這裡存放安裝檔案和一些不需要修改的固定檔案。
handlers：在發生改變時執行調用的task。如在tasks目錄下main.yml中有一步修改配置檔案後調用handlers，當執行時該步狀态為changed就會調用handlers中的task。
tasks：存放role任務檔案的目錄，main.yml就是任務入口檔案。
templates：template子產品檔案預設路徑，用于存放配置檔案和會改變的檔案，檔案中會定義變量資訊，在傳遞時進行變量的替換。
vars：role的變量目錄，可以存放role的變量配置資訊，為了友善使用者統一配置，這裡未使用role變量，而是采用了inventory中的組變量。
以下為在Playbooks中用到的一些技巧
register：注冊變量。
場景：在mysql5.6版本安裝完成後會生成預設root使用者的密碼并寫進~/.mysql_secret檔案，那我們要在安裝完成之後用這個root密碼執行初始化操作就可以使用這種注冊變量的方式。
擴充用法：判斷某個檔案或檔案夾是否存在，來控制task是否執行。當when語句的結果為true時才執行task。
Include：檔案加載，在一個任務檔案中調用另一個任務檔案。
場景：一個常用的任務片段在現今或之後的任務檔案中都可能用到，我們可以将它單獨抽離編寫一個任務檔案，然後再其它檔案通過include引用即可。
擴充用法：通過定義變量或注冊變量的方式，動态控制是否執行一個任務檔案。
ignore_errors：是否忽略錯誤。
場景：執行某一步，即使該步傳回錯誤依然繼續其他的任務。常用與command和shell子產品。如示例，在安裝mysql時先去删除機器可能自帶的mariadb-libs，在不存在mariadb-libs包時會報錯，忽略此錯誤。
wait_for: 校驗檔案或端口的狀态。
場景：等待一個端口啟動、關閉或一個檔案的生成、删除，常見于啟動應用後等待應用端口啟動，然後執行接下來的任務。
擴充用法：用來校驗端口是否啟動或檔案是否存在。
setup：擷取目标機器資訊，并注冊成主機變量。
場景：擷取目标主機ip資訊，并将ip寫進某個配置檔案。任務執行第一步就會預設會調用setup子產品擷取目标機器資訊，隻需要在腳本中直接使用變量ansible_default_ipv4.address就可以引用主機ip位址。
template：自定義模闆。
場景：大多數情況，我們隻需要把配置檔案中某些需要變更的變量抽成配置即可，但像nginx這種需要動态配置或相對複雜的配置檔案，就可能會用到Jinja2強大的模闆自定義的能力了，最後這張圖是安裝DevOps叢集環境是根據group分組中的ip以及組變量中的端口配置動态生成nginx config檔案的一個片段。
Ansible作為自動化工具中的後起之秀，因其簡單易用，無代理架構的特性，已經被廣大的自動化運維愛好者和初學者所接受并使用，如果不做二次開發，甚至都不需要對Python有深入的了解，實際上它豐富的子產品也已經基本滿足日常運維所有的需求。依稀記得第一次接觸到Ansible是在部署openshift（基于k8s的容器雲平台）的時候，這種複雜應用的部署通過簡單的幾行配置就完成了，不隻是運維，相信對Linux系統有所了解的研發人員也可以通過Ansible完成複雜應用的部署。
原文釋出時間為：張子康
本文作者：2017-07-18
本文來自雲栖社群合作夥伴EAWorld，了解相關資訊可以關注EAWorld。