基于docker的開發(fā)模式驅動持續(xù)集成落地實施

作者：陳能技 2015-12-02 14:56:07

云計算 今天主要交流的主題是基于Docker的開發(fā)模式如何驅動持續(xù)集成落地實施，這里會涉及兩個主要的話題，一個是所謂Docker的開發(fā)模式是怎樣的，與傳統(tǒng)的開發(fā)模式有什么區(qū)別;另外一個是持續(xù)集成作為敏捷開發(fā)的最佳實踐，結合Docker來實施會有什么樣的效果，會不會有更好的促進作用，尤其是在傳統(tǒng)企業(yè)中實施。

成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站建設、網(wǎng)站制作、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務嘉禾,10多年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:13518219792

嘉賓簡介

資深質量優(yōu)化專家，12年軟件測試與質量管理經(jīng)驗

《軟件性能測試診斷分析與優(yōu)化》等多本IT暢銷書作者

演講實錄

今天主要交流的主題是基于Docker的開發(fā)模式如何驅動持續(xù)集成落地實施，這里會涉及兩個主要的話題，一個是所謂Docker的開發(fā)模式是怎樣的，與傳統(tǒng)的開發(fā)模式有什么區(qū)別;另外一個是持續(xù)集成作為敏捷開發(fā)的最佳實踐，結合Docker來實施會有什么樣的效果，會不會有更好的促進作用，尤其是在傳統(tǒng)企業(yè)中實施。

也希望跟大家一起交流一下關于Docker的一些具體實施問題、實施經(jīng)驗

首先我們來看看，在傳統(tǒng)的開發(fā)運維模式下，會存在哪些問題。我稍微歸納總結了一下，大概會有以下三個問題：

1. 從需求到版本上線中間是個黑箱子，風險不可控
2. 開發(fā)設計時未過多考慮運維，導致后續(xù)部署及維護的困難
3. 開發(fā)各自為政，煙囪式開發(fā)，未考慮共享重用、聯(lián)調，開發(fā)的資產(chǎn)積累不能快速交移到運維手中

應對這樣的問題，我們通常倡導的解決之道是：運維前移，統(tǒng)一運維，建立持續(xù)交付服務體系。

但是這樣空喊是沒用的，我們要來點實際的，嘗試利用一些技術手段真正解決開發(fā)運維一體化的問題，具體推進DevOps的實施。

那好，我們看看最近1、2年非?；鸬腄ocker技術，看能否在解決上述問題上帶來一些具體的突破，或者給我們帶來一些解決具體問題的啟發(fā)。

我們先從Docker的一些技術特性來看，這些新的技術可能帶來的改變：

1. Docker首先是一個容器級虛擬化技術，相比傳統(tǒng)虛擬化技術，容器級的虛擬技術是操作系統(tǒng)內(nèi)核層的虛擬，所以能節(jié)省更多資源、提升性能，意味著單位機器資源消耗下，能承載更復雜更龐大的應用系統(tǒng)架構。
2. 啟動速度更快，毫秒級的啟動速度，這對于快速部署開發(fā)測試及運維環(huán)境非常有利。
3. 鏡像分層，部署時可以按需獲取鏡像生成容器并快速啟動運行，因此有利于快速的部署擴容，解決運維中水平擴容的問題。
4. 由于Docker鏡像的天然可移植性，就像集裝箱一樣快速打包應用以及依賴項，在開發(fā)、測試、運維之間移動，所以可以推進 開發(fā)-測試-運維 環(huán)境的統(tǒng)一，持續(xù)集成(CI)能發(fā)揮更大的作用，例如通過CI構建應用、檢查代碼，打包到Docker、分發(fā)部署到測試和準生產(chǎn)環(huán)境，進行各類測試，都可以更方便快捷和統(tǒng)一。

既然Docker的一些技術特性看起來確實能給開發(fā)測試運維帶來一些新的東西，那么我們接下來就具體看看，這些新的技術特性具體如何應用，以及應用過程中可能帶來的問題。

容器可以把應用以及它的依賴項進行打包，這樣帶來的好處就是應用隔離，能否把這種隔離特性用于解決一些架構問題呢?因為架構設計不好的話，給開發(fā)、測試，尤其是運維以及后續(xù)的維護管理帶來很多麻煩，例如隨著業(yè)務復雜度越來越高，可維護性和敏捷程度隨之變差。

#p#

傳統(tǒng)的應用通常采用所謂的三層架構，例如：界面層 – 業(yè)務邏輯層 – 數(shù)據(jù)層，通常我們會把所有實現(xiàn)業(yè)務邏輯層的代碼編譯構建后部署到中間件，再通過負載均衡、集群等解決分流、災備等問題。但是這種架構設計帶來的問題是：

開發(fā)效率低

隨著應用復雜度的增加，越來越少開發(fā)人員對應用能有全局性的深度理解。新功能開發(fā)和缺陷修復難度呈幾何性增加。代碼修改的正確性無法保障。而龐大的代碼庫需要更龐大的開發(fā)團隊來維護，無形中又增添了管理、溝通和協(xié)調的成本。另外，新加入的團隊成員需要花費大量的時間和精力來熟悉一個復雜的代碼庫。

交付周期長

在單一進程的單塊架構下，任何微小的改動都需要重新編譯、集成、測試和部署整個應用。隨著應用體積的增大，交付流程和反饋周期都會相應變長，應用發(fā)布的代價也隨之增加。于是應用交付周期變緩，交付間隙積累的代碼變動增加，從而對于下次交付產(chǎn)生更大的壓力，形成惡性循環(huán)。

技術轉型難

單一進程、單塊架構意味著中心化的技術選型。比如，應用的不同邏輯組建通常需要采用相對統(tǒng)一的編程語言、框架和技術棧。這些在項目初始階段便已定型。之后，即便是應用中全新的邏輯組件，也很難采用不同的技術棧。而當應用達到一定規(guī)模后，全局化的技術棧更新會面臨很高的風險。所以，單塊架構應用一旦定型，就很難再享受行業(yè)技術變更、發(fā)展所帶來的紅利。

有了容器技術之后，微服務設計也被大家慢慢提到架構設計的前沿進行討論了，這方面推薦大家看一本書《Building Microservices》。

微服務架構的誕生和容器技術的流行，幾乎是同時發(fā)生的，這并非偶然，而是互聯(lián)網(wǎng)時代倒逼傳統(tǒng)技術和架構而產(chǎn)生的變革，而以Docker為代表的容器技術則為微服務理念提供了匹配的實現(xiàn)機制。

在微服務架構下，我們將原本單一的應用按照功能邊界分解成一系列獨立、專注的微服務。每個微服務對應傳統(tǒng)應用中的一個組件，但是可以獨立編譯、部署和擴展。相對單塊架構，微服務具備以下優(yōu)勢：

(1)復雜度可控：在將應用分解的同時，規(guī)避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率。

(2)獨立部署：由于微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發(fā)生變更時無需編譯、部署整個應用。由微服務組成的應用相當于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風險，最終縮短應用交付周期。

(3)技術選型靈活：微服務架構下，技術選型是去中心化的。每個團隊可以根據(jù)自身服務的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術棧。由于每個微服務相對簡單，當需要對技術棧進行升級時所面臨的風險較低，甚至完全重構一個微服務也是可行的。

微服務架構中，可為每個服務選擇一個新的適合業(yè)務邏輯的數(shù)據(jù)庫系統(tǒng)，比如MongoDB、PostgreSQL。這樣做的好處：首先我們可以根據(jù)業(yè)務類型(讀多還是寫多等)來決定使用哪種類型的數(shù)據(jù)庫，其次這樣可以減小單個數(shù)據(jù)庫的負載。

(4)容錯：當某一組建發(fā)生故障時，在單一進程的傳統(tǒng)架構下，故障很有可能在進程內(nèi)擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩(wěn)退化等機制實現(xiàn)應用層面的容錯。

(5)擴展：單塊架構應用也可以實現(xiàn)橫向擴展，就是將整個應用完整的復制到不同的節(jié)點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現(xiàn)出其靈活性，因為每個服務可以根據(jù)實際需求獨立進行擴展。

看起來微服務的架構設計優(yōu)勢明顯，也是未來架構設計的一大趨勢方向，但是，如果采用微服務的架構設計，基于容器包裝微服務進行部署，給運維會帶來哪些新的挑戰(zhàn)呢?我認為會從以下幾個方面體現(xiàn)：

(1)運營開銷：更多的服務也就意味著更多的運營，需要保證所有的相關服務都有完善的監(jiān)控等基礎設施，傳統(tǒng)的架構開發(fā)者只需要保證一個應用正常運行，而現(xiàn)在卻需要保證幾十甚至上百道工序高效運轉，這是一個艱巨的任務。

(2)DevOps要求：使用微服務架構后，團隊需要高品質的DevOps和自動化技術，需要懂更多不同類型的技術棧。

(3)隱式接口：服務和服務之間通過接口來“聯(lián)系”，當某一個服務更改接口格式時，可能涉及到此接口的所有服務都需要做調整。

(4)分布式系統(tǒng)的復雜性：微服務通過REST API或消息來將不同的服務聯(lián)系起來，這在之前可能只是一個簡單的遠程過程調用。分布式系統(tǒng)也就意味著開發(fā)者需要考慮網(wǎng)絡延遲、容錯、消息序列化、不可靠的網(wǎng)絡、異步、版本控制、負載等，而面對如此多的微服務都需要分布式時，整個產(chǎn)品需要有一整套完整的機制來保證各個服務可以正常運轉。

幸好，業(yè)界已經(jīng)從運維管理的角度出發(fā)，做了不少工作來嘗試解決上述問題，例如Google開源的Kubernetes容器集群管理系統(tǒng)，提供應用部署、維護、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應用，其主要功能如下：

1. 使用Docker對應用程序包裝(package)、實例化(instantiate)、運行(run)。
2. 以集群的方式運行、管理跨機器的容器。
3. 解決Docker跨機器容器之間的通訊問題。
4. Kubernetes的自我修復機制使得容器集群總是運行在用戶期望的狀態(tài)。

#p#

前面我們探討了一下基于容器的微服務架構設計給傳統(tǒng)開發(fā)運維模式帶來的改變，看起來更多的還是正面的改變。

容器化微服務解決的更多的是架構設計的問題，按軟件工程來講，設計之后的下一步就是開發(fā)實現(xiàn)的事情了，在這個階段，傳統(tǒng)的開發(fā)測試會有不少的問題，例如環(huán)境的問題：

1. 軟件安裝麻煩、來源不一致、安裝方式不一致、雜亂無章。
2. 共用一個服務器開發(fā)環(huán)境，隔離性差，互相沖突。
3. 可移植性差，例如和生產(chǎn)環(huán)境不一致，開發(fā)人員之間也無法共享;新人入職通常又折騰一遍開發(fā)環(huán)境，無法快速搭建。

那么，隨著容器技術的引入，是否能帶來一些改觀呢?答案是明顯的!開發(fā)測試環(huán)境的容器化帶來的是標準化的開發(fā)測試環(huán)境，這對開發(fā)測試及運維的意義體現(xiàn)在：

(1)對開發(fā)測試的意義：測試環(huán)境搭建效率的提高，高效利用硬件資源同時又能敏捷輕便地搭建功能完備的開發(fā)測試環(huán)境，例如在一個資源有限的環(huán)境下面(比如開發(fā)人員的筆記本電腦)例如Chef 把系統(tǒng)的各個模塊按照清晰的邏輯結構部署并運轉起來，從而快速高效地進行開發(fā)與測試

(2)對運維部署的意義：開發(fā)測試(環(huán)境、依賴包) - Docker Hub - 運維(環(huán)境、依賴包) 的環(huán)境一致性

關于Docker在測試領域的一些應用，大家可以看看我寫的一篇文章，《淺談Docker在測試領域的應用》。

在傳統(tǒng)模式下，開發(fā)自測通常沒問題，但是到了測試或生產(chǎn)環(huán)境程序無法運行，讓開發(fā)團隊排查，經(jīng)過長時間排查最后發(fā)現(xiàn)是測試環(huán)境的一個第三方庫過時了。這樣的現(xiàn)象在軟件開發(fā)中很普遍，已經(jīng)不適用如今的快速開發(fā)和部署。

而在Docker模式下，應用是以容器的形式存在，所有和該應用相關的依賴都會在容器中，因此移植非常方便，不會存在像傳統(tǒng)模式那樣的環(huán)境不一致。

在開發(fā)測試環(huán)境容器化的背景下，研發(fā)模式的改變：

項目開始，架構師根據(jù)項目預期創(chuàng)建好需要的基礎鏡像(Nginx、Tomcat、MySQL鏡像)，或者將Dockerfile分發(fā)給所有開發(fā)人員，開發(fā)人員根據(jù)Dockerfile創(chuàng)建的容器或從內(nèi)部倉庫下載的鏡像來進行開發(fā)，如果開發(fā)過程中需要添加新的軟件，則向架構師申請修改基礎鏡像的 Dockerfile;

開發(fā)任務結束后，架構師調整Dockerfile或image，分發(fā)給測試部門，測試部門馬上就可以進行測試，消除了部署困難等難纏的問題。

在開發(fā)測試環(huán)境容器化的背景下，持續(xù)集成的模式也會發(fā)生一些必然的改變：持續(xù)集成各步驟圍繞任務Docker模塊進行工作。

開發(fā)人員的代碼嵌入會觸發(fā)開發(fā)環(huán)境中新的Docker鏡像的構建(代碼的編譯、構建、檢查、部署都基于Docker進行)，測試人員發(fā)現(xiàn)有新的Docker 鏡像構建出來，就會部署到測試環(huán)境中進行各類測試和驗證，測試通過后，會把鏡像放到公共鏡像庫，由運維人員進行生產(chǎn)環(huán)境的部署和發(fā)布。

好，那看完Docker在開發(fā)測試階段的應用，尤其是對持續(xù)集成方式的改變后，我們來看看，Docker對于傳統(tǒng)業(yè)務上線方式帶來的改變。

傳統(tǒng)業(yè)務上線存在的問題是：

1. 上線環(huán)節(jié)多，跨越多個部門，溝通成本高;
2. 涉及多個部門的審核，包括資源的申請、環(huán)境權限的批準、需求測試驗收等，耗時長;
3. 再加上上線部署過程涉及到的技術環(huán)節(jié)多，例如代碼獲取、編譯構建、代碼檢查、軟硬件安裝配置、應用裝載、啟動，導致發(fā)布周期很長。

#p#

針對傳統(tǒng)應用交付過程中的這些問題，Docker的引入帶來了明顯的改變，Docker把應用及相關依賴項打包成一個輕量、可移植、自包含的容器，讓應用的部署和發(fā)布基于容器進行，而不是基于代碼部署。由此，Docker重新定義了打包程序的方法：

Docker容器 + 用戶應用 = 部署單位(構件)

容器級部署帶來的最大的好處就是開發(fā)者本地測試、CI服務器測試、測試人員測試，以及生產(chǎn)環(huán)境運行的都可以是同一個Docker鏡像。因此可以實現(xiàn)應用的自動化快速部署及上線發(fā)布。

由于Docker技術的標準化通用化，可以方便地實現(xiàn)云服務器之間的移植，不依賴具體的某一個云服務商，降低了云部署的風險，因此，從這個角度來看，Docker能極大地促進企業(yè)做應用云部署的積極性，難怪各大IaaS和PaaS供應商都熱烈地擁抱Docker容器技術。

基于Docker的應用部署和發(fā)布，還可以方便地實施藍-綠部署，例如：保持兩套一樣的生產(chǎn)環(huán)境，而實際上只有一套環(huán)境真正的對外提供服務(綠環(huán)境)，而另一套環(huán)境則處于待機狀態(tài)(藍環(huán)境)。

先上線到藍環(huán)境，如果測試沒問題，再將路由切換到新的服務上。帶來的好處是明顯的：

• 最小化停機時間
• 快速回滾
• 熱備份

但是具體實現(xiàn)藍綠部署可能還會碰到更多細節(jié)的問題，例如數(shù)據(jù)的處理，這些都有待實踐。

最后，我們來聊聊容器微服務運維，前面我們有聊到基于容器化微服務設計給運維帶來的挑戰(zhàn)以及一些應對措施。

在容器微服務的模式下，功能模塊被隔離到一個個可單獨開發(fā)、測試和部署的容器中，所以當某個功能出現(xiàn)問題的時候，可以單獨把其對應的容器撤銷，開發(fā)進行修復，再上線，在這個過程中其它的功能(容器)不受影響，仍然正常運行。

微服務帶來的運維問題：

拆分成微服務后，部署變得復雜，監(jiān)控的復雜度也隨之提高，要理解在微服務之間產(chǎn)生的復雜交互，需要優(yōu)秀的診斷與監(jiān)控工具，同時對運維技能的要求也提高了，例如要了解多種技術棧。

我覺得可以從以下幾個方面去考慮：

(1)自動化管理：自動構建、自動測試、自動部署、自動運維...，盡可能自動化一切，從而控制好復雜度、工作量、降低人為操作失誤的風險;

(2)圍繞業(yè)務能力建模服務：運維需要對開發(fā)提出需求，例如：服務部署的獨立性、失敗隔離性、可監(jiān)控性，構建中心化的配置服務管理;

(3)充分利用容器技術實施服務流控，例如：降級、限流;

(4)充分利用容器技術實施服務恢復，多考慮故障快速恢復而非避免。

最后，給大家推薦一些Docker相關的書，有些是國內(nèi)的，有些是國外的。

原文鏈接：dbaplus.cn/news-21-123-1.html

網(wǎng)頁標題：基于Docker的開發(fā)模式驅動持續(xù)集成落地實施
URL鏈接：http://www.dlmjj.cn/article/dhigico.html