轉載本文需注明出處：微信公眾號EAWorld，違者必究。

本文目錄：

一、企業(yè)應用的部署發(fā)展

二、普元容器云與DevOps的部署設計

三、面向微服務的部署設計

四、容器組裝化部署

五、容器云集成之路

六、結語

一、企業(yè)應用的部署發(fā)展

企業(yè)應用，指的是那些部署在企業(yè)的服務器上，為企業(yè)的生產(chǎn)與運作提供支撐的核心系統(tǒng)。隨著IT技術的發(fā)展，企業(yè)應用的部署環(huán)境不斷地發(fā)生著變化。最初，大家用的都是物理機，后來出現(xiàn)了虛擬機，再到IAAS平臺的興起，到現(xiàn)在，大家都在忙著往容器遷移。環(huán)境的變化，也促使部署模式發(fā)生著變化。部署環(huán)境，我們可以大概將它們分成三個時代：

對于應用部署來說，物理機與獨立虛擬機可以認為是一種環(huán)境，數(shù)量規(guī)模不大，使用傳統(tǒng)的手工或腳本部署就可以滿足需求。到了iaas大興其道的時候，機器的數(shù)量發(fā)生了質的變化，這促進行了部署工具的發(fā)展，自動部署工具開始出現(xiàn)，各種手動部署平臺也開始出現(xiàn)。

而到了容器時代，需要部署的機器不但量更大，變化更劇烈，有的甚至需要根據(jù)條件自動升縮。為了滿足企業(yè)敏捷的需求，持續(xù)部署也成了必須，此時持續(xù)部署平臺也應運而生。部署模式的變更，也大概可以分為如下幾個階斷：

由早期手工的介質加部署文檔，發(fā)展至主要依賴于腳本進行部署。后來隨著各種配置管理與自動部署工具（如chef, puppet, saltstack, ansible等）出現(xiàn)，以及一些paas平臺部署工具的出現(xiàn)（如cloudfoundry的bosh)，企業(yè)應用的部署進入了平臺階段。

而部署平臺，根據(jù)其它自動化程度，我們可以再細分為兩類。一類是在前期，為了減輕運維人員的工作而產(chǎn)生的手動平臺，它可以將配置集中管理，依靠自動部署工具，可以幫助運維人員輕松將應用部署至眾多的服務器，也可以幫助運維人員進行后期的批量維護。

而第二類平臺，除了擁有自動部署能力之外，它的主要特點是加入了應用持續(xù)集成與持續(xù)部署的能力，可以將應用新的代碼新的能力源源不斷地推向生產(chǎn)環(huán)境，縮短應用的開發(fā)與上線周期。第二類平臺面向的就是不只是運維人員了，開發(fā)，測試，運維，QA等都可以參與進來。

二、普元容器云與DevOps的部署設計

為了適應用戶對容器部署的需求，普元于2015年也開始了自已的容器云建設，先后經(jīng)歷了三個版本的變遷。我們的平臺使用nexus做為介質庫，harbor做為鏡像倉庫，kubernetes做為底層調度管理平臺進行搭建。

不同于有些公司的使用應用的完整鏡像進行部署，我們主要采用的是組裝化的容器部署方案，應用的部署，是基礎鏡像+介質+配置最后組裝成的容器環(huán)境。

以示例應用PetStore為例，部署時，運行節(jié)點會先下載三個基礎鏡鏡。然后根據(jù)依賴關系，會先啟動mysql5.6的容器。接著啟動Tomcat7-Jdk1.8這個容器。在啟動這個容器的時候，我們使用了kubernetes的initContainer特性，它會在啟動Tomcat7-Jdk1.8這個容器啟動之前，先啟動一個init的容器，即上圖中的MediaDownloader。

這個容器會根據(jù)提供的介質url的環(huán)境變量，將所需要的介質下載下來，并放至合適的目錄，完成解壓等操作。然后，這個init容器將退出結束，正式啟動Tomcat7-Jdk1.8這個容器。由于介質已經(jīng)下載到了指定位置，Tomcat容器只需要正常啟動即可，這樣就完成了整個部署。

普元也于2015年開始了DevOps平臺的構建。構建之初，我們的要求就是要支持多種部署環(huán)境，包括物理機，虛擬機與容器。雖然當前IAAS平臺已經(jīng)比較成數(shù)，容器也發(fā)展迅速，但相當長一段時間內(nèi)，這三種部署環(huán)境在企業(yè)中是還會是共存的。

如圖，普元的DevOps先由構建引擎將應用從源碼構建成介質，并上傳至Nexus介質庫。部署階段，利用jenkins的pipeline組織部署過程，并由三種不同的pipeline來進行部署。

物理機與虛擬機，中間通過ansible自動部署工具進行部署，容器則通過普元的容器云kunkka進行部署。雖然部署模式與部署環(huán)境有所不同，但使用的是相同的介質。

三、面向微服務的部署設計

微服務也是近兩年來越來越熱的概念。一直以來，IT界就有一個夢想，希望軟件能像工業(yè)產(chǎn)品那樣徹底地模塊化，最終能夠通過簡單裝配出所需要的產(chǎn)品。于是有了各種插件系統(tǒng)，有了soa，到現(xiàn)在的微服務。

系統(tǒng)應用將由多個微服務構成，一個微服就是一個擁有獨立輸入與輸出的應用組件，各微服務之間通過接口互相聯(lián)系，構成一個整體。普元DevOps在設計部署這塊的模型的時候，就有考慮過對微服務模式的切合。

如上圖，我們先來看一下我們DevOps平臺關于部署與集成這塊的概念模型。持續(xù)集成部分，通過構建任務，將代碼最終構建成也組件的介質。部署時，我們有環(huán)境資源，對應各種環(huán)境，如虛擬機，物理機或者容器云。部署組件是部署的最基本單元，它可以代表一個介質如war包，jar包，也可以代表個中間件，如tomcat, jdk等，也可以代表一個系統(tǒng)os，安全組等。

部署容器則將部署組件組織成一個可最終轉換成運行環(huán)境的整體。部署裝配則將多個部署容器組織在一起，組成一個相互依賴的系統(tǒng)架構。部署裝配，部署容器通過部署環(huán)境與具體的環(huán)境建立關聯(lián)。部

署容器通過部署配置，定義在環(huán)境中需要使用到的變量，環(huán)境變量等。最終，通過執(zhí)行計劃，將部署容器轉化成部署實例，部署組件轉換成一個個組件實例，并最終部署。光說概念可能不是很好理解，那我們下面以示例來說明一下：

如上圖所示為例。在部署裝配中，定義了5個部署容器。每個部署獨立部署，通過他們之間的依賴關系定義最終的部署順序。右邊是springboot的部署容器的組件關系圖，其中的springboot-1, jdk-1等都是部署組件。

可以看出，springboot類型的組件這里有兩個，說明這個部署容器里，最終會啟動兩個springboot的進程。組件之間的關系，也會決定他們的最終部署順序。

在部署設計時，我們可以將部署裝配對應為整個微服務系統(tǒng)，部署容器則對應整個微服務系統(tǒng)中的單個微服務。當然，也可整個部署裝配只對應一個微服務，粒度取決于設計者。

整個應用部署過程，我們將它分成了四個階段。

• 第一階段為資源申請，先需要為項目創(chuàng)建可供部署的環(huán)境，環(huán)境為物理機，虛擬機或者容器云均可。同時，環(huán)境還根據(jù)用途，必須選擇一個類型，Dev, SIT 或者 UAT等。

  
  

• 第二階段進行部署設計，為應用創(chuàng)建部署裝配，部署容器等。

  
  

• 第三階段進行部署轉換，將部署裝配與部署容器綁定環(huán)境，并添加部署配置，定義部署模式，單節(jié)點或雙節(jié)點等。然后，創(chuàng)建部署計劃并執(zhí)行，完成部署。

  
  

• 第四階段則是組件的運維了，可以對部署容器實例進行啟動停止，重啟或者卸載。

這里我們假設架構師將整個系統(tǒng)應用設計成了一個部署裝配，而應用內(nèi)的微服務設計成了部署容器。哪些地方可以為微服務模式助力呢？主要有以下幾點：

• 依賴關系可視化 在部署裝配的系統(tǒng)關系中可以清楚看到系統(tǒng)應用各個微服務之間的部署依賴關系

  
  

• 架構演進版本化 部署裝配有歷史, 可以記錄整個系統(tǒng)應用部署架構的演進過程

• 服務獨立演進與構建 每個部署容器（代表一個微服務）可以獨立地演進，單獨地構建。

  
  

• 服務獨立運維 部署容器實例（微服務實例）可以單獨停止或重啟, 或者縮容與擴容

  
  

• 支持多環(huán)境混部 支持多環(huán)境混部, 某些資源占用大的部署容器（微服務）,可以部署在資源充足的物理機或虛擬上, 其它的則可以部署在容器中

四、容器組裝化部署

前面我們說到了容器組裝化部署，那么什么是容器組裝化部署呢？容器組裝化部署, 是指應用所需的系統(tǒng)，中間件，介質以及配置等并不完全事先打包在一起，而是在最終容器運行的時候,再通過組裝的方式來搭建最終的運行容器的一種部署模式。

另一種方式，則是容器整體化部署，它是指將應用運行所需要的系統(tǒng),中間件, 以及介質, 配置等完整地打包成一個鏡像，部署的時候整體地進行下載與啟動的部署方式。兩種方式最終結果是應用都運行在容器中，但中間過程卻有些不同。

那么，兩種方式各有什么優(yōu)劣呢？為什么我們要選擇主要使用組裝化部署呢？下面，我們先看兩個我們一些客戶碰到過的真實場景。

場景一：某家銀行上海與廣州兩個數(shù)據(jù)中心，兩個數(shù)據(jù)中心使用專線相連。由于業(yè)務發(fā)展需要，公司構建了容器云，應用使用容器整體化部署。兩地之間，通過鏡像庫的能力每晚進行鏡像同步。

運行一段時間之后，產(chǎn)生了大量的鏡像，鏡像同步的數(shù)據(jù)量越來越大，每晚花的時間也越來越多。現(xiàn)在，每晚進行鏡像同步的時候，幾乎占滿了兩地之間專線的帶寬。而且，這個情況只會愈演愈烈。

場景二：某家國企也自建了容器云，并采用整體化部署。由于管理比較寬松，容器云中出現(xiàn)了各種來源的鏡像。某一天，linux突然爆出了一個嚴重影響安全的漏洞，上級要求對所有的應用系統(tǒng)都打上補丁。運維人員面對云中成千上萬各種來源的鏡像，陷入了深深的絕望之中...

上面都是使用的容器整體化部署。那里我們使用組裝化部署方式會怎么樣呢？

如果使用組裝部署方式，鏡像同步問題，因為只使用了少量的基礎鏡像，鏡像庫之間的壓力很小。當然還有應用介質也需要同步，但是介質相比鏡像的分層數(shù)據(jù)，同步的可選方式就多了，可以壓縮，也可以合并等。

如果數(shù)據(jù)量實在太大，采用組裝式部署方式，也只能部分緩解壓力，而不能解決根本問題，這種情況我們建議可以通過代碼庫同步，兩地搭建構建平臺來解決問題，當然，這只是可選方案之一。安全補丁問題，使用基礎鏡像加介質的方式，則會效果明顯，而且這樣做也有利于鏡像的規(guī)范化。

總結一下，我們認為容器組裝化部署有以下的優(yōu)點:

• 基礎鏡像可由專人維護,有利于鏡像的規(guī)范化

• 減輕同步時的網(wǎng)絡壓力

• 利于鏡像的安全維護

• 縮短應用構建過程（不需要打包鏡像），緩解構建系統(tǒng)壓力

• 更易于與其它系統(tǒng)進行集成

當然也有缺點:

• 部署復雜度升高 原來的復制粘貼模式，又變成了帶部署過程的方式，復雜度穩(wěn)定性又有了變化。

• 每次部署都必須下載介質包

當然，不同的模式有利就會有弊。DevOps橫跨開發(fā)，測試與運維，開發(fā)與測試時變動頻繁，可以考慮使用組裝化部署。如果真實上生產(chǎn)，較為簡單的或介質較小的也可以使用組裝化部署。部署復雜，介質大，穩(wěn)定性要求高的應用，也可以考慮使用整體化部署模式。

五、容器云集成之路

DevOps平臺要支持容器部署，必然需要集成容器云平臺，可能還不只一個容器云平臺。那集成容器云平臺需要做些什么呢？

首先我們來思考一下，集成容器云的核心需求是什么。很明顯，應用部署和應用運維。運維首先需要有部署好的應用，應用部署又需要哪些資源呢？ 我們認為至少需要四個元素：用戶，環(huán)境，介質以及部署規(guī)格。應用部署前，我們需要先完成這四樣資源的對接。

用戶

容器云一般是一套完整的系統(tǒng)，它有用戶，需要鑒權。用戶如何對接呢？一般有兩種方式：

1. 單用戶全局映射 體現(xiàn)在devops系統(tǒng)中，就是集成容器云的時候，提供單個普通用戶信息。然后后面所有的操作都通過此用戶來進行，在容器云中部署的應用不存在用戶的隔離。

2. 多用戶一一映射 集成時提供容器云管理員信息，然后為每個普通用戶在容器云中創(chuàng)建對應的用戶，或綁定對應的用戶信息。以后普通用戶的操作通過對應的容器云用戶或用戶信息來進行。

用戶信息可以是用戶名/密碼，也可以是token。如果DevOps需要租戶級的隔離，則集成的時候，可以通過使用第二種用戶映射方式，使用不同的租戶管理員添加多次容器云來實現(xiàn)。

環(huán)境

環(huán)境的集成，主要通過對接企業(yè)的CMDB（配置管理數(shù)據(jù)庫）來實現(xiàn)。CMDB存儲與管理企業(yè)IT架構中設備的各種配置信息，DevOps平臺需要與它打通，然后從CMDB中獲取環(huán)境信息。

如果沒有CMDB，開源的CmdbBuild風評還可以，其它還有oneCMDB, itop CMDB等可以選擇。當然其實基礎的CMDB并不復雜，oneCMDB甚至以四個表就完成了數(shù)據(jù)建模，自建也是一種選擇。如果沒有CMDB，DevOps平臺還需要支持環(huán)境的手工錄入。

介質

介質的話，主要是鏡像與應用介質。需要同各種鏡像或介質庫做集成。推薦在開發(fā)與部署階段使用組裝化容器部署方案，這樣的話基礎鏡像比較少，可以降低甚至消除與鏡像倉庫的耦合。在預發(fā)與生產(chǎn)階段，可以考慮部分采用整體化部署。

部署規(guī)格

應用的部署規(guī)格，就是對應用部署所需參數(shù)的定義。不同的容器云，可能部署規(guī)格輸入的方式不一樣。對于docker swarm, 可能是一個compose.yaml，定義著它的部署編排。

對于kubernetes，可能就是service與deployment的yaml，而對于普元容器云kunkka，則是一個我們規(guī)定格式的json字符串。對于不同的容器云，只能通過定制不同的模板，根據(jù)參數(shù)生成最終的部署規(guī)格。

當然，真正要對接一個容器云平臺，要考慮的遠遠不止上面這一些，部署完成之后的運維，監(jiān)控也是非常重要的。

六、結語

本文我從企業(yè)應用的部署發(fā)展開始，介紹了普元容器云與DevOps平臺的部署設計，以及貼近微服務模式的助力點。然后我們介紹了一下當前容器部署的兩種主要模式，結合了兩個場景介紹了它們之間的優(yōu)缺點。最后，結合我們自身DevOps平臺與容器云的集成過程，總結了一下集成的注意點。

新思想新技術的出現(xiàn)，也必然帶來新的機遇，新的挑戰(zhàn)。我們和很多公司一樣，在DevOps與容器云建設這條路上也是摸索前進，很多想法與實現(xiàn)未必就是最好的。通過公司的InsideOut計劃，我們愿意與大家一起分享我們的這些想法與實踐。也歡迎大家可以分享自已的心得，一起促進整個行業(yè)的發(fā)展。

關于作者：

秦雙春

現(xiàn)任普元云計算架構師。曾在PDM，云計算，數(shù)據(jù)備份，移動互聯(lián)相關領域公司工作，10年IT工作經(jīng)驗。曾任上海科企軟件桌面虛擬化產(chǎn)品的核心工程師，主導過愛數(shù)TxCloud云柜的設計與開發(fā)，主導過萬達信息的食安管理與追溯平臺的移動平臺開發(fā)。國內(nèi)云計算的早期實踐者，開源技術愛好者，容器技術專家。

關于EAWorld

致力于軟件架構創(chuàng)新與實踐，加速企業(yè)數(shù)字化轉型，EAii（Enterprise?Architecture?Innovation?Institute）企業(yè)架構創(chuàng)新研究院旗下官方微信公眾號。

微信號：eaworld，長按二維碼關注

7月至9月，普元信息主辦的PWorld 2017系列技術活動將展開，將有六場大數(shù)據(jù)主題技術活動，其中7月1日的PWorld MeetUp現(xiàn)已開放報名。在北京、廣州共話“人工智能大數(shù)據(jù)自助發(fā)現(xiàn)”，在上海、成都共話“讓移動開發(fā)工程師先用起來AI”。

點擊“閱讀原文”，即刻到達PWorld 2017官網(wǎng)報名。