引子：提到自動化，最核心的問題只有兩點，第一，是否有必要自動化，第二，如何實現自動化。本文，也是從上述兩點出發，談談品高云在應用自動化領域的部署體系設計思想。
首先從應用的生命周期看，一個應用，從開發人員構建項目開始，經過不斷的開發測試，迭代出一個可以發布的版本，于是我們部署了生產環境；對于生產環境，首先，它需要監控，還需要升級、擴容，如果是高可用的環境，還有主備切換等等運維操作。
歸納起來，有四個部分，持續集成，應用部署，應用監控，應用運維。其中持續集成暫時不在品高云應用自動化體系設計的范圍中，所以我們先一起來看應用部署。
應用部署自動化的必要性
這張圖是品高云正在運營的公有云的架構圖，它是一個有9臺機器組成的高可用架構環境。我們花費了一周的時間來準備這個環境，并測試它。但是SIP是一個產品，她有很多實施的需求，如果讓實施人員在客戶現場，花一周的時間來部署這套高可用架構的環境，效率非常的低，并且每一次實施其實都是重復性操作。
從這樣的場景中就可以看出應用自動化的必要性，我們現在給實施人員的高可用架構，通過自動化部署，只需要大概十分鐘就可以完成部署，大大提高了效率，解放了實施人員，使得他們有更多的時間，去調試系統，與客戶交流。
有些應用架構非常簡單，只有一個web，一個數據庫，但是應用總是不斷演進的，SIP的架構最初也是一個單機版，現在已經演進到了9臺機器的高可用架構，未來還會更復雜。
如何實現應用自動化部署
一切自動化都是對人工操作的還原。我們先梳理一下人工部署環境的環節。
準備虛擬資源
不管是與IT部門PK申請物理機，還是從公司的私有云上獲取云主機，首先要準備好基礎資源。
準備安裝包
將程序包和軟件的安裝包拷貝到對應的機器上。
執行安裝腳本
包括：安裝數據庫、導入數據庫腳本、安裝TOMCAT、部署WEB應用、啟動HA幾個步驟。
應用部署其實有跡可循，我們把手工部署的順序記錄下來，作為約定，讓機器幫我們執行這些腳本。
通過設計方案，記錄部署操作
我們發現，部署操作，總結起來有三部分
1）基礎資源，2）安裝包，3）部署腳本
于是，通過一個可視化的設計器，用拖拉拽的方式，拖動基礎資源，和已經上傳好的安裝包，在其中編輯部署腳本，完成了所有部署操作的定義。
將設計方案轉換為系統可讀的指令
通過向系統提交這份設計方案的部署請求，經過訂單服務的審批，扣費等管理操作，部署任務被部署服務接收，并解析為一個個的步驟，關于資源申請的步驟會交給云編排服務執行，關于文件操作的步驟會交給文件服務，客戶端需要執行的腳本會通過控制器下發給云主機執行。那么指令是如何下發執行的呢？
agent調度機制
一般這種調度有兩種，一種是服務端直接通過ssh方式進行調度，一種是客戶端安裝探針的方式，我們采用的是探針。
原始模型
通過探針與服務端交互，獲取指令進行執行，并上報執行日志。
這種方式有兩個問題，第一，所有的機器都需要能夠訪問到服務端，第二，隨著機器規模的擴大，必然產生壓力。
在現實場景中，無論是IDC級別的隔離，還是云與云之間的隔離，以及最新的SDN的網絡管控，都限制了，無法做到所有的機器都能夠訪問到一個服務端地址。
代理調度機制
于是，我們設計了代理調度機制，將所有的部署區域，按照網絡連通性，或者性能壓力劃分為部署區域，每一個部署區域安裝一個代理，各個部署區域的機器，訪問代理，既解決了網絡連通性，又解決了性能壓力。
觸發調度機制
由于agent每15s一次的輪詢，會在網絡拓撲中產生網絡流量，在招行中，這種網絡流量是不允許的，所以我們又改造了工作方式，agent一般保持靜默狀態，通過服務端喚醒的方式，執行腳本，完成任務之后，繼續靜默。
于是最終agent有三種工作模式
1）通過配置初始化，多用于已有機器或者物理機部署，2）通過云提供的元數據初始化，3）靜默模式
部署架構
由于靜默模式要求客戶端必須開放固定端口，大多數場景不能使用，所以目前我們使用的是觸發調度機制。
適用場景-多次部署
有公司同事，興致勃勃的說要使用我們的這套部署系統。我們會問，”你的應用有沒有重復部署的需求？”，如果沒有，我們就會勸他，不必要費時費力的制作設計方案。因為多次部署的限制，我們流失了很多用戶，這不禁引起我們的反思，這么好的設計，只能做多次部署嗎？
軟件安裝和IaaS+服務
于是，我們提供了軟件安裝和IaaS+服務給客戶，幫他們準備好應用的運行環境，比如tomcat，mysql集群。但是本質上利用的還是應用交付的能力。
應用自動化只能止步應用交付嗎？
我們重新審視了應用的生命周期圖，發現還有應用監控和應用運維，能不能在交付給用戶環境的基礎上，讓這個交付的環境具備監控能力，讓Mysql集群具備主從切換的在線運維能力呢？
應用監控
于是監控模板應運而生，我們將監控的數據采集，監控告警，圖表展示等定義為監控模板，各個云主機通過關聯監控模板，而重用了系統提供的監控服務。通過關聯模板，我們提供的Mysql服務，具備了基礎監控能力和Mysql監控能力，未來我們還會提供更多的監控模板。
應用運維
運維有升級、擴容、主從切換等等，數不勝數，但是大致可分為兩類。
1）沒有資源操作
只需要對各個云主機，進行指令調度，比如mysql主從切換。
2）需要對資源進行操作
橫向擴容，比如負載均衡的web節點，要彈性擴容，在高峰期度過之后，要回收資源。
縱向擴容，比如某一臺數據庫實例，由于性能不好，需要擴容，由2核4G擴容到4核8G。
無論是橫向或是縱向，在機器擴容的過程中，都需要對程序進程操作，比如要回收數據，更改配置，重啟服務等等。
通過抽象出運維動作的概念，用來承載資源操作相應的腳本，實現所有運維操作的定義。
正在進行的規劃和
未來要做的事
標準化部署
已有的設計方案，系統只規定了機器層次的標準，對于安裝包和指令由設計者自由組織。于是，交付出的環境，系統只能捕捉到機器層次的CMDB信息。
通過定義組件化的標準，交付給用戶的環境，就可以取到組件層次的信息，用戶不僅可以直觀的看到一個業務應用中，有哪些云主機，還能夠看到每一臺云主機上部署了哪些組件，這些組件之間的端口調用關系。
應用導入導出
我們已經提供了將設計方案，安裝包等打包為一個pkg的二進制文件，用戶在私有云上架的應用，可以導出到公有云平臺。
服務市場
借助于應用導入導出，我們在公有云上運營服務市場，其他的私有云，可以通過在線或者離線下載的方式，將公有云新上架的應用下載到私有云平臺中；也可以將自制的應用上傳到服務市場，讓服務在品高云的生態中流通。
京公網安備 11010502049343號