本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
本文目錄：
一、企業應用的部署發展
二、普元容器雲與DevOps的部署設計
三、面向微服務的部署設計
四、容器組裝化部署
五、容器雲集成之路
六、結語
一、企業應用的部署發展
企業應用，指的是那些部署在企業的服務器上，爲企業的生產與運作提供支撐的核心繫統。隨着IT技術的發展，企業應用的部署環境不斷地發生着變化。最初，大家用的都是物理機，後來出現了虛擬機，再到IAAS平臺的興起，到現在，大家都在忙着往容器遷移。環境的變化，也促使部署模式發生着變化。部署環境，我們可以大概將它們分成三個時代：
對於應用部署來說，物理機與獨立虛擬機可以認爲是一種環境，數量規模不大，使用傳統的手工或腳本部署就可以滿足需求。到了iaas大興其道的時候，機器的數量發生了質的變化，這促進行了部署工具的發展，自動部署工具開始出現，各種手動部署平臺也開始出現。
而到了容器時代，需要部署的機器不但量更大，變化更劇烈，有的甚至需要根據條件自動升縮。爲了滿足企業敏捷的需求，持續部署也成了必須，此時持續部署平臺也應運而生。部署模式的變更，也大概可以分爲如下幾個階斷：
由早期手工的介質加部署文檔，發展至主要依賴於腳本進行部署。後來隨着各種配置管理與自動部署工具（如chef, puppet, saltstack, ansible等）出現，以及一些paas平臺部署工具的出現（如cloudfoundry的bosh)，企業應用的部署進入了平臺階段。
而部署平臺，根據其它自動化程度，我們可以再細分爲兩類。一類是在前期，爲了減輕運維人員的工作而產生的手動平臺，它可以將配置集中管理，依靠自動部署工具，可以幫助運維人員輕鬆將應用部署至衆多的服務器，也可以幫助運維人員進行後期的批量維護。
而第二類平臺，除了擁有自動部署能力之外，它的主要特點是加入了應用持續集成與持續部署的能力，可以將應用新的代碼新的能力源源不斷地推向生產環境，縮短應用的開發與上線週期。第二類平臺面向的就是不只是運維人員了，開發，測試，運維，QA等都可以參與進來。
二、普元容器雲與DevOps的部署設計
爲了適應用戶對容器部署的需求，普元於2015年也開始了自已的容器雲建設，先後經歷了三個版本的變遷。我們的平臺使用nexus做爲介質庫，harbor做爲鏡像倉庫，kubernetes做爲底層調度管理平臺進行搭建。
不同於有些公司的使用應用的完整鏡像進行部署，我們主要採用的是組裝化的容器部署方案，應用的部署，是基礎鏡像+介質+配置最後組裝成的容器環境。
以示例應用PetStore爲例，部署時，運行節點會先下載三個基礎鏡鏡。然後根據依賴關係，會先啓動mysql5.6的容器。接着啓動Tomcat7-Jdk1.8這個容器。在啓動這個容器的時候，我們使用了kubernetes的initContainer特性，它會在啓動Tomcat7-Jdk1.8這個容器啓動之前，先啓動一個init的容器，即上圖中的MediaDownloader。
這個容器會根據提供的介質url的環境變量，將所需要的介質下載下來，並放至合適的目錄，完成解壓等操作。然後，這個init容器將退出結束，正式啓動Tomcat7-Jdk1.8這個容器。由於介質已經下載到了指定位置，Tomcat容器只需要正常啓動即可，這樣就完成了整個部署。
普元也於2015年開始了DevOps平臺的構建。構建之初，我們的要求就是要支持多種部署環境，包括物理機，虛擬機與容器。雖然當前IAAS平臺已經比較成數，容器也發展迅速，但相當長一段時間內，這三種部署環境在企業中是還會是共存的。
如圖，普元的DevOps先由構建引擎將應用從源碼構建成介質，並上傳至Nexus介質庫。部署階段，利用jenkins的pipeline組織部署過程，並由三種不同的pipeline來進行部署。
物理機與虛擬機，中間通過ansible自動部署工具進行部署，容器則通過普元的容器雲kunkka進行部署。雖然部署模式與部署環境有所不同，但使用的是相同的介質。
三、面向微服務的部署設計
微服務也是近兩年來越來越熱的概念。一直以來，IT界就有一個夢想，希望軟件能像工業產品那樣徹底地模塊化，最終能夠通過簡單裝配出所需要的產品。於是有了各種插件系統，有了soa，到現在的微服務。
系統應用將由多個微服務構成，一個微服就是一個擁有獨立輸入與輸出的應用組件，各微服務之間通過接口互相聯繫，構成一個整體。普元DevOps在設計部署這塊的模型的時候，就有考慮過對微服務模式的切合。
如上圖，我們先來看一下我們DevOps平臺關於部署與集成這塊的概念模型。持續集成部分，通過構建任務，將代碼最終構建成也組件的介質。部署時，我們有環境資源，對應各種環境，如虛擬機，物理機或者容器雲。部署組件是部署的最基本單元，它可以代表一個介質如war包，jar包，也可以代表箇中間件，如tomcat, jdk等，也可以代表一個系統os，安全組等。
部署容器則將部署組件組織成一個可最終轉換成運行環境的整體。部署裝配則將多個部署容器組織在一起，組成一個相互依賴的系統架構。部署裝配，部署容器通過部署環境與具體的環境建立關聯。部
署容器通過部署配置，定義在環境中需要使用到的變量，環境變量等。最終，通過執行計劃，將部署容器轉化成部署實例，部署組件轉換成一個個組件實例，並最終部署。光說概念可能不是很好理解，那我們下面以示例來說明一下：
如上圖所示爲例。在部署裝配中，定義了5個部署容器。每個部署獨立部署，通過他們之間的依賴關係定義最終的部署順序。右邊是springboot的部署容器的組件關係圖，其中的springboot-1, jdk-1等都是部署組件。
可以看出，springboot類型的組件這裏有兩個，說明這個部署容器裏，最終會啓動兩個springboot的進程。組件之間的關係，也會決定他們的最終部署順序。
在部署設計時，我們可以將部署裝配對應爲整個微服務系統，部署容器則對應整個微服務系統中的單個微服務。當然，也可整個部署裝配只對應一個微服務，粒度取決於設計者。
整個應用部署過程，我們將它分成了四個階段。
第一階段爲資源申請，先需要爲項目創建可供部署的環境，環境爲物理機，虛擬機或者容器雲均可。同時，環境還根據用途，必須選擇一個類型，Dev, SIT 或者 UAT等。
第二階段進行部署設計，爲應用創建部署裝配，部署容器等。
第三階段進行部署轉換，將部署裝配與部署容器綁定環境，並添加部署配置，定義部署模式，單節點或雙節點等。然後，創建部署計劃並執行，完成部署。
第四階段則是組件的運維了，可以對部署容器實例進行啓動停止，重啓或者卸載。
這裏我們假設架構師將整個系統應用設計成了一個部署裝配，而應用內的微服務設計成了部署容器。哪些地方可以爲微服務模式助力呢？主要有以下幾點：
依賴關係可視化 在部署裝配的系統關係中可以清楚看到系統應用各個微服務之間的部署依賴關係
架構演進版本化 部署裝配有歷史, 可以記錄整個系統應用部署架構的演進過程
服務獨立演進與構建 每個部署容器（代表一個微服務）可以獨立地演進，單獨地構建。
服務獨立運維 部署容器實例（微服務實例）可以單獨停止或重啓, 或者縮容與擴容
支持多環境混部 支持多環境混部, 某些資源佔用大的部署容器（微服務）,可以部署在資源充足的物理機或虛擬上, 其它的則可以部署在容器中
四、容器組裝化部署
前面我們說到了容器組裝化部署，那麼什麼是容器組裝化部署呢？容器組裝化部署, 是指應用所需的系統，中間件，介質以及配置等並不完全事先打包在一起，而是在最終容器運行的時候,再通過組裝的方式來搭建最終的運行容器的一種部署模式。
另一種方式，則是容器整體化部署，它是指將應用運行所需要的系統,中間件, 以及介質, 配置等完整地打包成一個鏡像，部署的時候整體地進行下載與啓動的部署方式。兩種方式最終結果是應用都運行在容器中，但中間過程卻有些不同。
那麼，兩種方式各有什麼優劣呢？爲什麼我們要選擇主要使用組裝化部署呢？下面，我們先看兩個我們一些客戶碰到過的真實場景。
場景一：某家銀行上海與廣州兩個數據中心，兩個數據中心使用專線相連。由於業務發展需要，公司構建了容器雲，應用使用容器整體化部署。兩地之間，通過鏡像庫的能力每晚進行鏡像同步。
運行一段時間之後，產生了大量的鏡像，鏡像同步的數據量越來越大，每晚花的時間也越來越多。現在，每晚進行鏡像同步的時候，幾乎佔滿了兩地之間專線的帶寬。而且，這個情況只會愈演愈烈。
場景二：某家國企也自建了容器雲，並採用整體化部署。由於管理比較寬鬆，容器雲中出現了各種來源的鏡像。某一天，linux突然爆出了一個嚴重影響安全的漏洞，上級要求對所有的應用系統都打上補丁。運維人員面對雲中成千上萬各種來源的鏡像，陷入了深深的絕望之中…
上面都是使用的容器整體化部署。那裏我們使用組裝化部署方式會怎麼樣呢？
如果使用組裝部署方式，鏡像同步問題，因爲只使用了少量的基礎鏡像，鏡像庫之間的壓力很小。當然還有應用介質也需要同步，但是介質相比鏡像的分層數據，同步的可選方式就多了，可以壓縮，也可以合併等。
如果數據量實在太大，採用組裝式部署方式，也只能部分緩解壓力，而不能解決根本問題，這種情況我們建議可以通過代碼庫同步，兩地搭建構建平臺來解決問題，當然，這只是可選方案之一。安全補丁問題，使用基礎鏡像加介質的方式，則會效果明顯，而且這樣做也有利於鏡像的規範化。
總結一下，我們認爲容器組裝化部署有以下的優點:
基礎鏡像可由專人維護,有利於鏡像的規範化
減輕同步時的網絡壓力
利於鏡像的安全維護
縮短應用構建過程（不需要打包鏡像），緩解構建系統壓力
更易於與其它系統進行集成
當然也有缺點:
部署複雜度升高 原來的複製粘貼模式，又變成了帶部署過程的方式，複雜度穩定性又有了變化。
每次部署都必須下載介質包
當然，不同的模式有利就會有弊。DevOps橫跨開發，測試與運維，開發與測試時變動頻繁，可以考慮使用組裝化部署。如果真實上生產，較爲簡單的或介質較小的也可以使用組裝化部署。部署複雜，介質大，穩定性要求高的應用，也可以考慮使用整體化部署模式。
五、容器雲集成之路
DevOps平臺要支持容器部署，必然需要集成容器雲平臺，可能還不只一個容器雲平臺。那集成容器雲平臺需要做些什麼呢？
首先我們來思考一下，集成容器雲的核心需求是什麼。很明顯，應用部署和應用運維。運維首先需要有部署好的應用，應用部署又需要哪些資源呢？ 我們認爲至少需要四個元素：用戶，環境，介質以及部署規格。應用部署前，我們需要先完成這四樣資源的對接。
用戶
容器雲一般是一套完整的系統，它有用戶，需要鑑權。用戶如何對接呢？一般有兩種方式：
單用戶全局映射 體現在devops系統中，就是集成容器雲的時候，提供單個普通用戶信息。然後後面所有的操作都通過此用戶來進行，在容器雲中部署的應用不存在用戶的隔離。
多用戶一一映射 集成時提供容器雲管理員信息，然後爲每個普通用戶在容器雲中創建對應的用戶，或綁定對應的用戶信息。以後普通用戶的操作通過對應的容器雲用戶或用戶信息來進行。
用戶信息可以是用戶名/密碼，也可以是token。如果DevOps需要租戶級的隔離，則集成的時候，可以通過使用第二種用戶映射方式，使用不同的租戶管理員添加多次容器雲來實現。
環境
環境的集成，主要通過對接企業的CMDB（配置管理數據庫）來實現。CMDB存儲與管理企業IT架構中設備的各種配置信息，DevOps平臺需要與它打通，然後從CMDB中獲取環境信息。
如果沒有CMDB，開源的CmdbBuild風評還可以，其它還有oneCMDB, itop CMDB等可以選擇。當然其實基礎的CMDB並不複雜，oneCMDB甚至以四個表就完成了數據建模，自建也是一種選擇。如果沒有CMDB，DevOps平臺還需要支持環境的手工錄入。
介質
介質的話，主要是鏡像與應用介質。需要同各種鏡像或介質庫做集成。推薦在開發與部署階段使用組裝化容器部署方案，這樣的話基礎鏡像比較少，可以降低甚至消除與鏡像倉庫的耦合。在預發與生產階段，可以考慮部分採用整體化部署。
部署規格
應用的部署規格，就是對應用部署所需參數的定義。不同的容器雲，可能部署規格輸入的方式不一樣。對於docker swarm, 可能是一個compose.yaml，定義着它的部署編排。
對於kubernetes，可能就是service與deployment的yaml，而對於普元容器雲kunkka，則是一個我們規定格式的json字符串。對於不同的容器雲，只能通過定製不同的模板，根據參數生成最終的部署規格。
當然，真正要對接一個容器雲平臺，要考慮的遠遠不止上面這一些，部署完成之後的運維，監控也是非常重要的。
六、結語
本文我從企業應用的部署發展開始，介紹了普元容器雲與DevOps平臺的部署設計，以及貼近微服務模式的助力點。然後我們介紹了一下當前容器部署的兩種主要模式，結合了兩個場景介紹了它們之間的優缺點。最後，結合我們自身DevOps平臺與容器雲的集成過程，總結了一下集成的注意點。
新思想新技術的出現，也必然帶來新的機遇，新的挑戰。我們和很多公司一樣，在DevOps與容器雲建設這條路上也是摸索前進，很多想法與實現未必就是最好的。通過公司的InsideOut計劃，我們願意與大家一起分享我們的這些想法與實踐。也歡迎大家可以分享自已的心得，一起促進整個行業的發展。
關於作者：
秦雙春
現任普元雲計算架構師。曾在PDM，雲計算，數據備份，移動互聯相關領域公司工作，10年IT工作經驗。曾任上海科企軟件桌面虛擬化產品的核心工程師，主導過愛數TxCloud雲櫃的設計與開發，主導過萬達信息的食安管理與追溯平臺的移動平臺開發。國內雲計算的早期實踐者，開源技術愛好者，容器技術專家。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
