容器時代的DevOps部署

轉載本文需注明出處:微信公眾號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)報名。


閱讀原文:https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660395551&idx=1&sn=2f186d7f6099ae9336816e2d941828e1&chksm=f74248f9c035c1ef5ca1285b027a2012d9a28dbd6e52482f3000807aba243475f3ac8b612f7e#rd
最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容