[[174110]]

進入2016年以后，容器技術(shù)早已經(jīng)從最初的牛逼滿天飛到了腳踏實地的大規(guī)模鋪開。很多企業(yè)都已經(jīng)在實際項目中或深或淺的使用著容器技術(shù)，享受到新技術(shù)帶來的簡潔和高效。作為國內(nèi)最早研究和使用Docker技術(shù)的企業(yè)，ThoughtWorks在2013年底就在實際項目中將Docker用于測試環(huán)境的資源復(fù)用，并在之后的許多項目中逐漸總結(jié)出許多有用的實踐和經(jīng)驗。在這篇文章里，我將聊聊Docker在我經(jīng)歷過項目中的一些比較有代表性的運用場景。

現(xiàn)實中的容器技術(shù)運用方式非常廣泛而靈活，時常讓人覺得腦洞大開，概括來說是『可小可大，可遠(yuǎn)可近』。下面用四個案例來闡示容器在非特定領(lǐng)域里的運用場景。

容器之小：小而美的容器DevOps架構(gòu)棧

圖1基于容器和DevOps理念的運維架構(gòu)

這張架構(gòu)圖來自于一個規(guī)模不到20人的小型產(chǎn)品團隊，團隊的結(jié)構(gòu)十分精巧，由兩名開發(fā)人員兼任主要的運維工作。這兩位開發(fā)人員，花了幾周時間通過Ansible陸陸續(xù)續(xù)搭建起了這套由上百個服務(wù)器節(jié)點組成的集群，并由團隊所有開發(fā)人員共同維護。整體套集群系統(tǒng)高度自動化，使得團隊的每個人都能夠十分快速而安全的完成業(yè)務(wù)功能的部署、獲取線上業(yè)務(wù)的運行狀況、以及對出現(xiàn)問題的故障點進行快速的日志錯誤定位。

麻雀雖小，五臟俱全。這套技術(shù)方案包含了集群管理、網(wǎng)絡(luò)管理、服務(wù)發(fā)現(xiàn)、日志管理、性能監(jiān)控等許多方面的設(shè)計，從架構(gòu)的角度上看，已經(jīng)儼然是一個小型私有PaaS平臺。

Swarm作為集群的管理工具，具有與Docker原生命令良好的一致性，在學(xué)習(xí)曲線比較緩和，在DevOps文化比較好的團隊中很容易讓開發(fā)人員快速上手。在這個架構(gòu)方案中使用了Consul作為集群元數(shù)據(jù)存儲的方案，Swarm的主、從節(jié)點信息以及Docker的跨節(jié)點網(wǎng)絡(luò)劃分的信息都存放在這里。Consul除了作為集群信息的存儲，還可以用于應(yīng)用服務(wù)的配置存儲和服務(wù)發(fā)現(xiàn)，以及作為內(nèi)網(wǎng)的DNS服務(wù)使用。不過出于安全性和可維護性的考慮，應(yīng)該為應(yīng)用服務(wù)單獨搭建獨立的Consul節(jié)點，與存儲集群配置的Consul分開，防止由于數(shù)據(jù)干擾和意外修改引起大規(guī)模系統(tǒng)故障。

使用Swarm的另一個潛在好處是它能夠充分利用Docker內(nèi)置的跨節(jié)點網(wǎng)絡(luò)功能，這套基于VxLAN的SDN實現(xiàn)十分簡潔易用，通信效率也很不錯。

容器集群的的性能監(jiān)控和日志管理是使得這個小團隊得以駕馭比團隊人數(shù)更多的服務(wù)節(jié)點的關(guān)鍵要素，任憑運行的服務(wù)在機器漫漫海洋中隨意穿行，這兩件工具就是開發(fā)人員的羅盤和風(fēng)向標(biāo)，在關(guān)鍵時候為線上故障的定位爭取寶貴時間，并能從中迅速找到每個服務(wù)當(dāng)前運行的節(jié)點，從而采取必要的應(yīng)急措施。cAdvisor+Influxdb+Grafana是一套為容器集群性能監(jiān)控設(shè)計的開源解決方案，利用cAdvisor對容器信息的良好監(jiān)控能力，Influxdb對時間序列數(shù)據(jù)的快速檢索能力，以及Grafana的強大圖表展示能力，形成性能數(shù)據(jù)的實時查看和歷史回溯，并反饋到開發(fā)和運營的狀態(tài)報表，形成完整閉環(huán)。不過，這個開源組合的缺陷在于缺乏現(xiàn)成的事件告警組件，在Influxdata公司的Telegraf項目逐漸成熟后，可以考慮使用它替代cAdvisor的功能，然后集成Kapacitor作為告警模塊，提前預(yù)知服務(wù)的不正常狀態(tài)。日志管理方面，這套系統(tǒng)使用了當(dāng)下最主流的容器日志開源工具組合Fluentd+EslasticSearch+Kibana，在《程序員》2016年6月刊『容器的性能監(jiān)控和日志管理』一文中已經(jīng)對這個組合進行過比較深入的探討。

這是Docker集群化實踐中運用得比較出色的一個案例，特別是對中小型產(chǎn)品團隊，會有不少可借鑒和啟發(fā)之處。在不用增加額外運維人員的情況下，這套系統(tǒng)可以比較輕松的擴容至幾百上千的規(guī)模。然而，這個架構(gòu)本身并沒有考慮譬如多數(shù)據(jù)中心、租戶隔離、訪問授權(quán)、資源配額等復(fù)雜情景，它主要的設(shè)計初衷在于解決集群易用性的問題。試想在過去使用虛擬機管理服務(wù)的時代，讓只有幾個人的團隊去維護上千個計算節(jié)點上運行的需要各種不同環(huán)境和配置的服務(wù)，這簡直是不可完成的任務(wù)，然而通過容器化的部署、DevOps思維的團隊、加上適當(dāng)?shù)募狠o助工具，他們做到了。

容器之大：大型任務(wù)集群的容器化調(diào)度

圖2基于容器的多數(shù)據(jù)中心任務(wù)平臺架構(gòu)

并不是所有的團隊都愿意從頭構(gòu)建自己的整套運維架構(gòu)和基礎(chǔ)設(shè)施環(huán)境。在許多企業(yè)里，服務(wù)的運維管理是有專門的組織負(fù)責(zé)的。這些組織可能叫做平臺部門、運維部門、或者環(huán)境支持部門，不論稱呼如何，這些組織以及部門通常都需要管理數(shù)量相當(dāng)龐大的計算資源。這些資源可能是跨機房，跨城市，甚至是分布在歐洲、美洲、非洲并且相互無法直接通信的數(shù)據(jù)中心里。他們所需要調(diào)度的作業(yè)數(shù)量和種類也遠(yuǎn)遠(yuǎn)超過一個自運維產(chǎn)品團隊所需要考慮的規(guī)模。

為這樣的組織設(shè)計基于容器的任務(wù)調(diào)度平臺需要對企業(yè)的需求和特定業(yè)務(wù)領(lǐng)域有充分的了解，越是大型的基礎(chǔ)設(shè)施集群，所需要應(yīng)對的風(fēng)險和不確定也越大，設(shè)計一個面面俱到的通用大型集群也越困難。因此針對具體業(yè)務(wù)場景做出一定的取舍是不得已、但又是必要的。例如為了獲得較高的響應(yīng)速度而將集群劃分為多個互不重疊的調(diào)度區(qū)域，因而限制了每個區(qū)域的容量;為了避免內(nèi)網(wǎng)數(shù)據(jù)網(wǎng)絡(luò)風(fēng)暴而將節(jié)點數(shù)據(jù)分層處理并逐級減少數(shù)據(jù)匯總的維度，因而增加監(jiān)控管理復(fù)雜度;或者為了增加系統(tǒng)規(guī)模而采用高度聚合而不適合多數(shù)據(jù)中心的方案。這些方案往往不需要具備普適性，而是會針對特定企業(yè)和業(yè)務(wù)場景進行恰到好處的修剪和優(yōu)化。

上面圖中展示的是一個企業(yè)PaaS服務(wù)平臺的結(jié)構(gòu)，架構(gòu)基于Kubernetes集群，需要應(yīng)用在多個異地數(shù)據(jù)中心，并在統(tǒng)一的部署系統(tǒng)上對服務(wù)進行管理。由于單Kubernetes集群容量有限，這個方案實際上根據(jù)地域劃分和租戶的規(guī)模構(gòu)建了多個幾十到上千節(jié)點不等的子集群，集群直接互不重合，屬于同一個任務(wù)組的服務(wù)只會在特定的某個集群內(nèi)進行部署和調(diào)度，其實就是將集群和租戶進行了綁定。在所有集群之上，通過自研的一個任務(wù)分發(fā)服務(wù)作為所有調(diào)度任務(wù)的入口，在這里處理服務(wù)的依賴關(guān)系、所屬區(qū)域、以及其他元數(shù)據(jù)信息，然后調(diào)用Kubernetes的API完成任務(wù)的部署和調(diào)度，并通過額外的組件處理網(wǎng)絡(luò)、存儲等資源的配置。

在圖中省略了系統(tǒng)采用的其他自研模塊，值得一提的是這個系統(tǒng)的性能數(shù)據(jù)管理使用了開源的Promethus軟件。Promethus是SoundCloud公司維護的一款包含信息采集、處理、分析、展示和告警的性能監(jiān)控整體解決方案，它提供了比較靈活的多數(shù)據(jù)中心級聯(lián)能力和集中式的配置管理功能，因此特別適合規(guī)模較大的計算集群。不同于前一案例中Influxdb方案每個數(shù)據(jù)采集節(jié)點發(fā)數(shù)據(jù)給存儲數(shù)據(jù)的中心節(jié)點的方式，Promethus的性能數(shù)據(jù)采集是由中心服務(wù)器主動向所有節(jié)點定時輪詢的方式拉取的，因此所有與數(shù)據(jù)采集相關(guān)的配置全部在中心服務(wù)器上進行修改即可。而節(jié)點的數(shù)量和IP地址變動則通過服務(wù)發(fā)現(xiàn)機制來告知中心服務(wù)器，這大大簡化了修改數(shù)據(jù)收集參數(shù)的流程。

這個案例是一個比較典型的大規(guī)模容器集群，在大型容器集群方面許多企業(yè)都有著自己的實踐沉淀。其中有兩個比較明顯的特點是從業(yè)務(wù)場景制定架構(gòu)和系統(tǒng)中包含許多自研的組件，因此在借鑒的時候更需要廣泛的收集信息，避免盲目照搬。

容器之遠(yuǎn)：基于容器的持續(xù)集成實踐

圖3基于容器的持續(xù)交付流水線示意

接下來，讓我們用廣角鏡頭來審視一下軟件發(fā)布的生命周期。通過持續(xù)交付的流水線，我們能夠清晰的定義出軟件從代碼提交到上線發(fā)布之前所需要經(jīng)過的每個環(huán)節(jié)，協(xié)助開發(fā)者發(fā)現(xiàn)工作流程中存在的瓶頸，并促使團隊提升端到端的自動化程度，縮短獨立功能上線的周期。

那么容器在其中能扮演什么樣的角色呢?首先是資源的隔離，為了確保每一次編譯和測試的獨立性，軟件應(yīng)該在干凈的環(huán)境中分別進行構(gòu)建、打包、并運行測試用例，而容器是非常合適用來提供這種虛擬環(huán)境的輕量級工具。其次是一致的軟件打包方式，Docker的封裝意味著不論運行的服務(wù)是用Java、Python、PHP還是Scala、Golang，平臺可以用幾乎相同的方式去完成部署，而不用考慮安裝服務(wù)所需的環(huán)境，這些都在軟件開發(fā)的時候就已經(jīng)準(zhǔn)備好了。***是成熟的調(diào)度平臺?；谌萜饔性S多現(xiàn)成的任務(wù)調(diào)度框架，也正是由于前兩個角色，容器使得任務(wù)的分發(fā)變得容易，由于應(yīng)用不需要依賴主機的配置，這就讓任務(wù)的靈活調(diào)度成為可能。

基于容器的持續(xù)交付流水線和普通交付流水線很相似，包含構(gòu)建、打包、測試、部署等環(huán)節(jié)。同時這其中也有許多技巧和專用于容器的優(yōu)化手段。這個案例中我們選取其中兩個比較具有啟發(fā)性的來說。

***個例子是關(guān)于容器構(gòu)建的優(yōu)化。容器的構(gòu)建通常都是由某個基礎(chǔ)鏡像開始，通過Dockerfile的描述自動化逐步執(zhí)行，直至完成預(yù)期的狀態(tài)。幾乎所有項目的Dockerfile都不會每次從一個原始的Ubuntu或者CentOS的鏡像做為基礎(chǔ)，從頭構(gòu)建整個運行環(huán)境，因為那樣會使得每次構(gòu)建花費非常長的時間。制作用于繼承的公共基礎(chǔ)鏡像是早已世人皆知的鏡像構(gòu)建提速優(yōu)化的方法，這樣可以讓費時而又不常改變的步驟固定下來，每次構(gòu)建時候就只需要基于這個鏡像再進行增量修改就可以了。但這種方法其實也有潛在問題，那就是當(dāng)我們需要升級基礎(chǔ)鏡像的時候，不得不重新構(gòu)建所有基于它制作的所有服務(wù)鏡像。

這個問題被稱為『脆弱的基礎(chǔ)鏡像』，該問題的應(yīng)對策略有很多。例如簡單的延遲子級鏡像的升級時間，直到每個子鏡像下次重新構(gòu)建發(fā)布時自然會獲得更新。又例如比較激進的方式，通過流水線建立鏡像的依賴關(guān)系，在父級鏡像一旦更新時，自動觸發(fā)所有子級鏡像的自動重建，這種方式要慎重采用，因為它很可能會導(dǎo)致同時產(chǎn)生大量的鏡像構(gòu)建任務(wù)，對網(wǎng)絡(luò)和磁盤造成嚴(yán)重的壓力。那么，有沒有在一種辦法既能獲得具有時效性的更新，又不會產(chǎn)生短時間內(nèi)的構(gòu)建風(fēng)暴呢?其實對于一些場景是可以有取巧方法的，通過Docker的外掛存儲能力，將經(jīng)?？赡茏兓膬?nèi)容做成單獨的鏡像，然后利用Docker的『–volume-from』參數(shù)在服務(wù)啟動時覆蓋掉運行容器的特定目錄。典型的場景就是用于編譯其他服務(wù)的容器，這些容器中一般都會有一些編譯服務(wù)時所需的時依賴庫，這些依賴庫隨著項目所需依賴的變化也要跟著變，像Maven的~/.m2/repository目錄，Node的全局node_module目錄等就很適合這樣管理。當(dāng)這個目錄下面的內(nèi)容需要更新時，只需重新構(gòu)建提供目錄內(nèi)容的一個鏡像，而不會產(chǎn)生鏡像構(gòu)建的鏈?zhǔn)椒磻?yīng)，服務(wù)下次啟動時候就會獲得新的依賴庫目錄了。

第二個例子是流水線中的測試環(huán)節(jié)。進行自動化測試的時候，容器的優(yōu)勢發(fā)揮尤其明顯。對于外部服務(wù)的依賴，比如與數(shù)據(jù)庫相關(guān)的測試，由于測試過程需要反復(fù)運行，過去時候，如果測試運行完沒有正確的清理留下的數(shù)據(jù)，特別容易影響后續(xù)測試的運行結(jié)果。容器恰恰是提供這種即用即棄基礎(chǔ)設(shè)施***的方式，完全可以在測試腳本中先啟動一個全新的MySQL服務(wù)，然后測試完就銷毀，保證了每次測試的獨立性。關(guān)于這方面的應(yīng)用在下個案例中再介紹更多細(xì)節(jié)。

類似的技巧還有很多。持續(xù)交付流水線是最能體現(xiàn)容器在軟件領(lǐng)域帶來各方面改進的大觀園。許多現(xiàn)成的工具可以***化的避免手工操作對流程的干擾，讓軟件發(fā)布開上高速公路。

容器之近：容器在自動化測試平臺的運用

圖4基于容器的自動化測試平臺架構(gòu)

***這個案例是一個針對軟件自動化測試環(huán)節(jié)的容器化基礎(chǔ)設(shè)施設(shè)計。它是軟件持續(xù)交付流水線上的一個重要環(huán)節(jié)，讓我們帶上長焦鏡，近距離審視容器在軟件測試場景中能解決怎樣的問題。

容器快速啟動、快速銷毀的特性與軟件測試時所需的每次干凈獨立的臨時運行環(huán)境十分匹配。使得在這方面容器可以大有作為。特別是在集成測試和功能性測試的階段，被測系統(tǒng)的運行往往會需要涉及多個要獨立運行的子組件或子模塊。還有外部模塊的依賴，如果進行的是界面相關(guān)的測試用例，往往還會用到Selenium和瀏覽器的組件。而運行數(shù)據(jù)庫相關(guān)的測試則會需要MySQL、Mongodb等組件。手工為每個測試用例準(zhǔn)備并維護這些環(huán)節(jié)依賴是十分讓人抓狂的事情。過去做這類測試時候為了解決依賴問題，通常做法是額外部署一套專用于測試依賴的環(huán)境，所有模塊測試需要別的模塊時都統(tǒng)一指向這套測試環(huán)境作為目標(biāo)。由于過于頻繁的升級這個依賴環(huán)境可能會打斷正在運行的測試用例，因此只能對它進行定期的更新，這種無形中限制了的時效性和可靠性。

特別是一些比較重要并且耗時較短的回歸測試和冒煙測試用例，理想情況下應(yīng)該在每次代碼提交后都全量的更新并執(zhí)行，以便***時間發(fā)現(xiàn)一些潛在的功能缺陷。但為每次提交創(chuàng)建一套測試環(huán)境不論是手工操作還是過去基于虛擬機的自動化方式都過于繁瑣。

案例中的測試平臺正是意圖通過容器和簡單的依賴描述，來解決測試環(huán)境管理的問題。它基于所有被測組件和所依賴的組件都使用Docker鏡像來提供的前提之上，將所有組件抽象成一致的模型寫成描述文件，描述文件的主要內(nèi)容就是整個測試環(huán)境所需的鏡像和啟動順序。

示意圖中的『運行調(diào)度器模塊』是接入持續(xù)交付流水線的調(diào)用入口，可以采用譬如Jenkins的形式插件實現(xiàn)，它用來創(chuàng)建和保存特定測試用例所需的環(huán)境描述文件內(nèi)容。在流水線觸發(fā)該測試環(huán)節(jié)時，這個模塊調(diào)用『測試執(zhí)行器模塊』，將描述模型用特定的結(jié)構(gòu)體傳遞給后者，后者解析這個數(shù)據(jù)模型，轉(zhuǎn)化為接近Kubernetes服務(wù)模型的形式，然后在『服務(wù)依賴管理模塊』的協(xié)助下，通過Kubernetes創(chuàng)建臨時的Namespace，并依次創(chuàng)建每個服務(wù)。當(dāng)測試環(huán)境就緒后，『測試執(zhí)行器模塊』就開始執(zhí)行測試用例，***又通過『服務(wù)依賴管理模塊』通知Kubernetes銷毀整套環(huán)境。

整個過程對于平臺的用戶而言，僅僅是增加了一個測試環(huán)境描述的內(nèi)容，寫在持續(xù)交付流水線測試步驟的定義(例如Jenkins插件配置)里。而這套系統(tǒng)內(nèi)部頗為復(fù)雜的執(zhí)行過程，能夠有效的利用整個集群的資源，恰到好處的為測試的過程提供支持。

總結(jié)

這四個案例由淺入深、由遠(yuǎn)及近的展現(xiàn)了容器在現(xiàn)代軟件和基礎(chǔ)設(shè)施設(shè)計中舉足輕重的作用。有些技術(shù)會直接改變?nèi)藗兊纳睿硪恍┘夹g(shù)則會改變技術(shù)本身以及技術(shù)的發(fā)展方向，容器技術(shù)屬于后者。

隨著容器運用的普及，當(dāng)下的主流媒體對容器周邊技術(shù)的關(guān)注還在持續(xù)升溫。不僅是《程序員》推出了本期的容器技術(shù)?？?，在***一期的ThoughtWorks公開刊物《技術(shù)雷達(dá)【1】》中，容器和Docker相關(guān)的關(guān)鍵詞同樣占據(jù)了大量版面。在越來越多的技術(shù)領(lǐng)域里，無論是移動設(shè)備、物聯(lián)網(wǎng)、大數(shù)據(jù)，都能看到容器技術(shù)各種形式的延伸，作為現(xiàn)實容器運用的一道縮影，此文可作為窺斑見豹、拋磚引玉之用。

參考鏈接：

【1】https://assets.thoughtworks.com/assets/technology-radar-apr-2016-cn.pdf