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

開始之前，先為小白們普及下發布流程。

如圖為簡單的發布流程，其中涉及到運維操作的有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均可在最大化不更改運維操作習慣的前提下完成業務的(工具)自動化發布。

優點： 

◆溝通成本小

◆約束點少

缺點：

◆冗余模塊變多

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

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

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