DevOps平臺中的自動化部署框架設計

時間 2019-12-06

標籤 devops 平臺自動化部署框架設計欄目測試自動化简体版

原文原文鏈接

本文目錄：java

1、背景node

2、咱們的需求是什麼？mysql

3、概念澄清nginx

4、概念模型git

5、整體設計spring

6、關鍵點設計sql

7、總結docker

1、背景shell

說到自動化部署，你們確定都會想到一些配置管理工具，像ansible,chef,puppet, saltstack等等。雖然這些工具給運維效率和安全性帶來了不少好處。可是實際工做中，咱們仍是會遇到一些問題： npm

這些工具沒法普及到開發、測試人員，常常找運維幫忙，沒法自助；
項目人員沒法直觀的參看到系統的部署架構設計，及架構的演進過程；
從物理架構設計到最終上線，沒法造成閉環；
受差別性的基礎設施影響較大。

2、咱們的需求是什麼？

咱們DevOps平臺的部署模塊就克服上面這些問題，爲實現DevOps以產品爲核心，以項目管理爲驅動，將需求、設計、交付、運維整個鏈路打通這一目標提供有力支持。具體來看其需求涵蓋一下幾點：

將架構設計歸入DevOps管理過程當中，支持架構設計版本化；
一次架構設計屢次部署；
以最佳實踐爲基礎，實現架構設計模版重用；
多環境部署，同時支持應用在虛擬機、容器上的部署；
支持多種部署模式（單機、高可用）、部署策略（全新、藍綠、滾動升級、回滾）

3、概念澄清

在正式講解咱們的設計以前，咱們想澄清CI/CD的基本概念，由於本次的主題和持續集成、持續交付和持續部署這些名詞總有些淵源。

一、什麼是持續集成？

持續集成（Continuous Integration）指的是，頻繁地將代碼集成到主幹，以便快速發現錯誤、防止分支大幅度偏離主幹。

持續集成的目的，就是在產品快速迭代的同時保持代碼質量，它的核心措施主要有兩點：

1）代碼集成到主幹以前，必須經過自動化測試，只要有一個測試用例失敗，就不能集成。

2）經過Code Review、代碼質量分析工具對代碼質量進行把關，以便肯定是否可以集成。

Martin Flower說過，「持續集成並不能消除Bug，而是讓他們很是容易發現和改正。」

二、什麼是持續交付？

持續交付（Continuous Delivery）指的是，新版本爲了可以快速安全的交付到生產環境中，須要將新版本先交付到類生產（Production-like）環境中（如UAT／Staging／Lab環境），以便進行相應的業務驗證、安全驗證、性能驗證等過程。

一旦類生產環境驗證經過，新版本就進入到生產階段。

持續交付能夠看做是持續集成的進一步。它強調的是，無論怎麼更新，軟件是隨時隨地能夠交付的。

三、什麼是持續部署？

持續部署（Continuous Deployment）指的是，新版本經過類生產環境的驗證後，自動部署到生產環境中。

持續部署能夠當作持續交付的進一步。持續部署的前提是自動化完成測試、構建、驗證等步驟。

持續部署的目標是，代碼在任什麼時候刻均可以進入自動地進入生產階段，爲最終用戶提供服務。

持續交付和持續部署的區別能夠參考下圖：

（點擊可放大查看）

從上圖中，咱們能夠看出：

持續交付流程將自動的測試新版本應用，可是否將新版本交付到生產環境中是一個手動過程。持續部署則是自動地將新版本交付到生產環境中去。

關於持續交付／持續部署，咱們不能說哪個是最好的方案。對於不一樣的組織，適合的就是最好的。

四、什麼是自動化部署？

自動化部署（Automatic Deployment）指的是，經過自動化工具將應用介質部署到指定環境中去。

自動化部署只是持續交付和持續部署流程中的一個功能單元。

自動化部署工具：Ansible、Puppet、SaltStack等等。

經過以上概念的澄清，咱們瞭解了什麼是持續集成、持續交付、持續部署以及自動化部署。

本文的主題不是介紹持續集成、持續交付、持續部署的Pipeline與實現，而是介紹DevOps平臺中，在傳統自動化部署工具之上的自動化部署框架的設計與實現。而自動化部署模塊也是咱們DevOps平臺中的CI/CD的底層能力。

下面咱們就來聊聊具體的設計。

4、概念模型

（點擊可放大查看）

除了系統內置的一些模版概念，咱們將自動化部署流程分爲三個階段，即設計、轉換、運維。每一個階段都會有相應的基本模型。

下面，咱們分階段的去解釋一下這些概念模型。

一、設計階段

設計（Design），是在裝配（Assembly）內對應用/系統的架構的描述；而應用/系統，是由含有多個組件（Component）的系統（Platform）組成的。

Design階段的基本流程：

（1）建立裝配（Assembly）

經過選擇可用的系統模版(Platform Template)，添加一個新的Platform；
每個Platform都對應一種應用（如mysql，tomcat，springboot，nginx）；
每個Platform都是有一組組件（Component）組成的，而且已定義好了組件之間的依賴關係；
在Assembly內，用戶能夠經過設置Platform Link設置各個Platform之間的關係

（2）配置系統（Platform）內的組件（Component）的屬性值

Component是最底層的部署（或者配置）單元，如springboot中的secgroup, compute, os, jdk, fatjar, lb都是一個組件；
每個Component都有相應的配置模版

（3）提交設計

提交的過程是將已經完成的設計作一次Commit，作一次歸檔。

二、轉換階段

轉換（Transition），是在Assembly內對應用/系統在某一Environment內的部署過程。

Transition階段的基本流程：

（1）建立部署環境（Deploy Environment）

根據環境類型(如dev, test, prod等)，添加屬於某個Assembly的部署環境
部署以前，部署環境是應用/系統用於部署的配置的抽象
部署以後，部署環境就是管理和監控應用/系統的具體實例的集合

（2）配置部署環境

設置每一個Platform關聯的資源（vm/container）、部署模式（單點，高可用）

（3）選擇Assembly內的一個或多個Platform生成並提交執行計劃

根據部署策略不一樣，一個Platform的執行計劃可能包含幾個子計劃

（4）執行部署

每一個Assembly/Environment/Platform下面的每一個Component都有一個instance，這些instance能夠進行單獨Repair

三、運維階段

運維（Operation），是在Assembly內對各個部署環境內Instances的管理和監控。

Operation階段的基本任務：

（1）組件實例運維，例如

Compute: Status, Reboot, upgrade-os-security, powercycel, repair, upgrade-os-all
Tomcat/Jboss: Status, Stop, Start, Restart, Repair, Debug
Artifact: Repair, Redeploy, Custom User Attachment

（2）展示正在部署的操做，有可能還會Replace或Cancel其中一項組件部署或整個部署

（3）展現Assembly某一Environment下的組件實例圖譜

（4）日誌查詢

對基本的概念模型有了基本認識後，咱們來看一下自動化部署框架的整體思路。

5、整體思路

DevOps自動化部署框架採用DevOps平臺（設計）＋Jenkins（執行）的方式完成。

DevOps的職責

完成部署架構設計；
根據部署架構設計和部署環境的配置建立生成相應的執行計劃及子執行計劃，每個子計劃對應一個Jenkins pipeline job配置文件(config.xml)；
查詢Jenkins執行job的實時進度與結果。

Jenkins的職責

根據config.xml建立Jenkins Pipeline Job；
執行pipeline job；
Jenkins job 經過pipeline script中ansible／openshift命令進行相應的部署等執行操做；
提供查詢job執行狀況的Rest API。

結合上面提到的三個階段，具體的流程以下所示：

（點擊可放大查看）

下面是具體的部署視圖：

（點擊可放大查看）

看完總體思路和部署視圖，你們確定會問爲何選擇jenkins做爲具體的執行引擎？

首先，jenkins支持master/slave架構，能根據性能需求水平擴張，slave又能夠支持多種環境，能夠將不一樣的job分配到不一樣的slave節點。

還有很是重要的一點，就是Jenkins Pipeline的能力。

Jenkins中pipeline的設計理念是實現基於groovy腳本，靈活，可擴展的工做流。

durable持久性：在jenkins的master按計劃和非計劃的重啓後，pipeline的job仍然可以工做，不受影響。
可暫停性：pipeline基於groovy能夠實現job的暫停和等待用戶的輸入或批准而後繼續執行。
更靈活的並行執行，更強的依賴控制，經過groovy腳本能夠實現step，stage間的並行執行，和更復雜的相互依賴關係。
可擴展性：經過groovy的編程更容易的擴展插件。
豐富插件：Jenkins已經支持經過groovy命令調用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件，不須要咱們再單獨實現集成。
Rest API：Jenkins提供經過Rest API的方式獲取每個stage的執行狀況。

因爲咱們最終會將應用部署到虛擬機和容器雲中，虛擬機部署主要經過jenkins中提供的ansible插件＋jenkins pipeline script來實現；容器雲部署則根據具體的容器雲，經過openshift插件（會有必定擴展）或者http request插件＋jenkins pipeline script來實現。

下面咱們來看一下Jenkins2的主要概念。

step, 其實跟jenkins1中的概念同樣，是jenkins裏job中的最小單位，能夠認爲是一個腳本的調用和一個插件的調用。好比經過git拉取代碼就是一個step，mvn clean package也是一個step，一個http遠程調用等等。

node, 是pipleline裏groovy的一個概念，node能夠給定參數用來選擇agent，node裏的steps將會運行在node選擇的agent上。這裏與jenkins1的區別是，一個 job裏能夠有多個node，將job的steps按照需求運行在不一樣的機器上。例如一個job裏有好幾個測試集合須要同時運行在不一樣的機器上。

stage, 是pipeline裏groovy裏引入的一個虛擬的概念，是一些step的集合，經過stage咱們能夠將job的全部steps劃分爲不一樣的stage，使得整個job像管道同樣更容易維護。pipleline還有針對stage改進過的view，使得監控更清楚。這裏補充一句，多個stage能夠在一個node裏定義及執行，一個stage內的多個step能夠分到不一樣的node上執行。

6、關鍵點設計

前面咱們說的都是概念和流程上的東西，那麼用戶該如何進行部署架構設計？部署架構設計完成後，如何提交呢？如何將提交的設計在具體的部署環境中轉換成執行計劃與子執行計劃呢？子計劃又如何與jenkins pipeline job映射呢？這就是咱們下面要介紹的一些關鍵點設計。

一、模塊化

（點擊可放大查看）

前面提到，當用戶建立Platform時，咱們的DevOps平臺提供可選的Platform Template，Platform Template定義了其中能夠包含的組件類型(Component Template)等信息。也就是說，咱們的平臺提供了一種基於最佳實踐的方式，幫助用戶完成系統的架構設計。不只如此，經過對Platform Template/Component Template等相關數據準備的介紹，也對之後用戶擴展添加新的組件類型，提供了充足依據。基本思路以下：

1）定義不一樣的系統模版Platform Template(見表DPS_DLV_PLATFORM_TEMPLATE)。系統模版就是咱們經過最佳實踐的方式提供了一套應用／中間件系統的模版。如tomcat，nginx、springboot、mysql等。

一個Platform Template定義了這個模版中包含的組件模版，定義了組件模版之間的依賴關係(見表DPS_DLV_COM_RELATION_DEFINITION)，以及每一種組件類型所在的層以及每一種組件類型容許添加的組件的個數(見表DPS_DLV_COMP_CONTAINER_DEFINITION)。當用戶添加一個Platform時，必需要選擇一種Platform Template。

2）根據不一樣的部署模式（單節點、高可用）、不一樣的目標資源（虛擬機、容器）、不一樣的部署策略（全新、藍綠、滾動升級、回滾），一個系統模版會對應到多個執行計劃模版 (見表DPS_DLV_PLATFORM_ACTION_PLAN_TEMPLATE)。

3）一個系統由多個組件組成，所以系統模版和組件模版之間也是多對多的關係。例如springboot模版對應的組件模版有：secgroup模版、os模版、jdk模版、java application模版等等。

組件模版Component Template(見表DPS_DLV_COMP_TEMPLATE)以及組件的全部屬性(見表DPS_DLV_COMP_ATTRIBUTE_DEFINITION)。組件模版就是組件的元數據，爲Platform添加的Component都是源於Component Template。

4）爲每一個Component Template定義Operation模版(見表DPS_DLV_COMP_OPERATION)，以便對單個組件實例進行操做，如restart, repair, stop等。

經過以上4步系統預置的Platform Template和Component Template以及相應的數據，就能夠提供給用戶添加一個Platform了。這些預置數據也爲後面生成部署計劃Deploy Plan作好的準備。

二、變量管理

在需求分析中，咱們就提出但願一次設計屢次部署。可是在設計階段設置各個組件屬性時，並不能肯定在不一樣的部署環境中其值是一致的，而且一個系統的不一樣組件的屬性也多是共用一個值。這時候咱們就須要引入變量管理。變量管理的主要思路以下：

1）設計階段，爲系統定義一些變量（ConfigMeta）並設置一個默認值，如install_dir。而後在設置某個組件屬性值時能夠用@P{install_dir}來表示。

2）提交設計時，也一同將變量定義做爲設計的一部分進行提交。

3）轉換階段，在部署環境中，爲每個變量設置當前環境下的值（ConfigValue）。當建立執行計劃時，會將屬性@P{install_dir}替換爲當前環境的值。

不只Platform內能夠定義變量供該Platform下的Component使用，咱們也能夠給Assembly定義變量供全部Platform及其組件使用, 形如@A{assembly_var}。

三、設計提交

（點擊可放大查看）

當用戶設計完部署架構、設置每一個組件屬性及變量後，須要將當前的設計指定好版本進行提交，即歸檔。只有提交的設計，才能在部署環境中獲取的到指定的版本。經過版本化，咱們能夠設計的不一樣版本作相關的對比。

上面的表結構是比較清晰的表述。

四、執行計劃

根據不一樣的部署模式（單節點、高可用）、不一樣的目標資源（虛擬機、容器）、不一樣的部署策略（全新、藍綠、滾動升級、回滾），一個系統模版會對應到多個執行計劃模版，而且計劃模版之間有父子關係。
每個子執行模版就是一個jenkins pipeline script模版。
當用戶在部署環境中選擇某個具體系統及部署策略生成相應的執行計劃（含子計劃）時，每個子計劃的jenkins pipeline script就是將具體的組件屬性注入到執行模版中生成的。

另外，爲何須要顯示的建立出子計劃呢？例如，對於一個高可用的應用，除了要部署具體的應用，還須要更新load balance配置，而這二者之間可能須要加入一些人工活動。因此咱們經過顯示的建立處子計劃，支持用戶按子計劃一步步的來作。

而jenkins pipeline script的stage幾乎都對應到一個具體的組件，具體能夠看下圖。

（點擊可放大查看）

五、部署策略

前面咱們提到了「部署策略」這個詞，除了全新部署，咱們常見的部署策略有藍綠髮布、滾動升級、灰度發佈／金絲雀發佈、回滾。下面來看看咱們的相應解決方案。每一種部署策略都會有相應的執行計劃模版（含子計劃）。

藍綠髮布

什麼是藍綠髮布？

在發佈的過程當中用戶無感知服務的重啓，一般狀況下是經過新舊版本並存的方式實現，也就是說在發佈的流程中，新的版本和舊的版本是相互熱備的，經過切換路由權重的方式（非0即100）實現不一樣的應用的上線或者下線。