1.作者介紹

2008年開始接觸linux，之后一起從事linux相關工作，先后就職于上海woyo、騰訊、匯聯、諾亞等企業，馬哥教育特約講師。

　　2.主題介紹

　　30分鐘帶你揭開運維自動化的面紗-Ansible業務自動化之路

　　難度指數：2星(滿星5星)

　　技術指數：4星(滿星5星)

　　理論指數：3星(滿星5星)

　　面向人群：運維~技術流

　　本次分享重點：跨“種族”業務發布自動化之路

　　其中：練就18式，拿下自動化。時間關系本次不做重點講解，后續會做為系列分享進行。

　　3.分享內容

　　第一章、情定Ansible

　　和談男女朋友一樣，如果不對眼再漂亮的對象也白搭，如果相互不了解，再牛也有被當成是拍黃片(PHP)的時候。

　　我選擇PHP的原因，sorry，我選擇Ansible的原因有如下幾個方面：

1.去中心化

作為 Ansible 發展至今的核心優勢極具競爭力，最大的優勢是人人皆可成為三軍將領，遷移非常方便，要求也很簡單，python 2.6+、pip/yum/apt簡單的幾條命令即可全盤搞定。據稱該特性也會一直堅持下去，不確認是不是基于這個原因紅帽才下決心收購了Ansible 呢(個人推斷也是“輕”的緣故)。無論如何作為一個新秀，如此成績實在驚為天人。

2.簡單

和saltstack/puppet不同，不用class等高級語法即可滿足業務日常所需；雖然devops是新一代運維必備，但萬丈高樓平地起，devops也非簡單幾日就能信手拈來。

　　和fabric不同，無需懂python任何語種即可快速上手掌握；好吧！也不得不承認 fabric 是開發同時的最愛，幾行簡單的代碼無需改變習慣就能完成心中所想，但應對項目日趨復雜，對開發能力要求也不斷提高，且維護成本指數增加。

　　最后，用官方原話形容Ansible簡單的特性：Stupid simple。

3.友情搜索 

　　眾所周知，未來是關系搜索的時代。身邊朋友的實踐體驗也是極為重要。想到saltstack，puppet不停反饋出來的問題，心中也是略有陰影，當然也不排除Ansible問題還沒有暴露出來的可能。

4.“大勢所趨” 

　　想想XEN，KVM，有了奶媽的支持，高低立顯。繼Ansible之前自動化工具雖如雨后春筍，但未來還不一定“鹿死誰手”。

更多： 

　　對比參見 黃博文 http://www.cnblogs.com/huang0925/p/4664608.html

　　ok！Ansible的基礎介紹到此結束。

#p#

　　第二章：跨”種族”業務發布自動化之路

　　開始之前，先為小白們普及下發布流程?！　?/p>

　　如圖為簡單的發布流程，其中涉及到運維操作的有8步。相對腳本化，Ansible更多程度上：1.降低了上手難度；2.保障了自動化質量；3.健壯了可擴展性。

　　舉個例子：

　　PHP/Java項目的發布就底層而言有非常大的不同和實現機制，同時由于開發同學多樣化需求，針對多套環境如何保障運維發布操作單一化、簡單 化，Ansible的實現方式非常針對性的考驗運維同學思維深度和全面性。Ansible在設計之初側面幫了運維同學不少忙，你會發現在運用的過程中會不 自主的靠著Ansible的“規則”來,當然這些規則對運維架構框架是有利的。下面的例子簡單來分析看看：

如圖為我們當前業務的發布方式，現在還處于腳本自動化階段，比較lower。 

　　化零為整

　　Ansible一次完整的發布可以非常靈活的按模塊拆分，場景：

　　針對測試環境不希望人工參與的背景下：化零為整，一鍵部署。

化整為零 

　　針對正式生產環境操作繁多變更不定的背景下：化整為零

　　Ansible的模塊化 & tags 功能輕松駕馭

有朋友當然會反問，上面我寫個腳本輕松搞定。 

　　確實，我們后面會講到，請稍安勿躁！

　　運維同學SHELL腳本是必備技能，相比較devops而言，SHELL腳本的學習成本和上手難度幾乎為零。再回頭看Ansible的發布方式，結合SHELL腳本的參數調用，有沒有覺得似曾相識，改變一個人的習慣何其難，所以Ansible playbook簡單是運維的福音。

　　Yml語法清晰明了，規則簡單，99%的功能都是一行命令即可實現。Ansible自帶冥等判斷機制也省去運維不省邏輯判斷傷腦費心的人腦運算。

　　寫playbook的過程就是一個思維整理的過程。

　　太過復雜的思維在寫的過程中會無意中被簡化。

　　好的，上面的內容大家可以先消化1min。

第三章： 不同“種族”業務Ansible的處理方式

　　以PHP/JAVA多項目為例，有如ppt所示問題：　　

　　公司現有PHP項目近10個，JAVA項目也納入運維管理，后期也可能不斷融入新項目，如何保證1.現有操作習慣不變改變；2. 簡單一致的發布操作。

　　越來越具挑戰。

　　起初希望通過git命名規范來實現簡化發布操作，但隨之發現不可能，原因如下：1.影響合作部門已有工作習慣；2.約束力太多阻力也在不斷加大；3.溝通成本大；4.非核心功能開發支持力度不及自力更生來的快。

　　最終方案：

　　多一層判斷和roles模塊，通過git的變量名來定義git拉取地址。

　　這個用ansible來實現簡單是易如反掌。

　　如此以來php，java均可在最大化不更改運維操作習慣的前提下完成業務的(工具)自動化發布。

優點： 

　　◆溝通成本小

　　◆約束點少

　　缺點：

　　◆冗余模塊變多

　　◆運維維護成本大，復雜程度增加。

　　◆來簡單對比下代碼差異化程度。

可以看出差異化地方只在執行的服務器和進程管理的各類。 

#p#

　　再來看看代碼量。 

　　第四章：練就18式，拿下自動化

　　基礎模塊13式

作為基礎模塊，熟悉掌握即能完全駕馭ansible日常工作90%自動化工作，簡單指數5星。 

　　輔助模塊5式

擁備基礎模塊，同時配合輔助模塊可使已有成果更上一層樓，簡單指數 4星。 

　　第四章：AnsibleUi -jumpserver

　　話說自動化怎么能停留在工具時代，但 tower 又收費，如何破?

　　jumpserver 完全開源的，堡壘機功能日趨完善，自動化發布平臺底層也基于 Ansible 實現，更多精彩可參考http://jumpserver.org/ 。

最新功能： 

　　第五章：后記分享目錄

　　分享目錄及方式參考

　　參考http://www.178linux.com/doc/ansible/翻譯的內容按功能模塊結合業務實踐以場景化方式逐一講解。

　　問題反饋路徑 http://www.178linux.com/qa/重復收看 http://www.osstep.com。

　　群友Q/A

　　問題1：發布為啥是用ansible去打包的?

　　最小化最簡化原則，運維需要懂的工具很多，需要熟練不會太多，精一通百的人畢竟少數，精力也是有限，就如用阿里云，ucloud就推薦使用他們的“四大件”。

　　問題2：ansible在上千機器的集群中有沒有瓶頸?

　　這個我如實回答，我知道的還沒有。數百臺的應用是有的。但我覺得RedHat都不擔心這個問題，我們更不需要擔心，看看kvm,docker的發展就是指導。

　　問題3：ansible在win上只支持nt不支持2003 如何解決？

　　A：只能說是所有開源軟件的通病，windows閉源已經深知其中的痛點，近些年不是一直有傳言會開源嗎?哈哈！

　　問題4：ansible在上千機器的集群中有沒有瓶頸?

　　有瓶頸，一次在千臺以上建議salt，萬臺建議go自己寫，主要是消息回收master受不了。

　　問題5：我想知道部署的時候，有沒有向移動端發展的趨勢!

　　A：有，前沿的大公司已經在用，如鵝廠，jumpserver.org也在首面放在 mobile的daemon。

　　問題6：感覺ansibie異常的時候不好排錯！有沒有好的方法?

　　A：這樣問是因為你還不熟悉，多被磨磨就好。python的報錯輸出和shell一樣簡單。見過JAVA的復雜日志輸出會深有體會，看完我們開發同學輸出的日志再看ansible的報錯輸出是覺得好幸福。哈哈！

　　問題7：我們可否跟監控服務器聯動，一旦執行出錯馬上報警，并且讓系統提供出錯日志。

　　A：ansible本身提供mail alert功能，你可以把ansible日志記錄到syslog里面，用ELK 或者splunk來實現報警。　　

Ansible原著翻譯團隊

　　聯系人：stanley (微信號: fengzhilinux) 5. Ansible專題分享，請把你想聽到的想學到的錄入到 http://www.178linux.com/qa/。

　　Ansible部落

　　致力全球流行技術本土化

　　運維部落---Ansible部落群功能：1. Ansible的翻譯工作馬上就要結束進行最后的 review 階段，你知道嗎?2. 為方便各位第一時間接受最新技術前沿，我們成立運維部落微信訂閱號，除了每日分享，定期更新外，還有大蝦不定期解惑，歡迎關注！