隨著大數(shù)據(jù)平臺型產(chǎn)品方向的深入應(yīng)用實踐和Docker開源社區(qū)的逐漸成熟，業(yè)界有不少的大數(shù)據(jù)研發(fā)團隊開始擁抱Docker。簡單來說，Docker會讓Hadoop平臺部署更加簡單快捷、讓研發(fā)和測試團隊集成交付更加敏捷高效、讓產(chǎn)線環(huán)境的運維更加有質(zhì)量保障，而這背后的業(yè)務(wù)場景和具體的實踐方法有哪些?在Docker容器服務(wù)逐步走向完善的過程中，大數(shù)據(jù)平臺產(chǎn)品Docker模式的應(yīng)用又是如何解決的?正是本文所著重闡述的。

實踐中發(fā)現(xiàn)問題

場景一

在大數(shù)據(jù)平臺型產(chǎn)品的開發(fā)過程中，經(jīng)常要跟許多模塊打交道，包括Hadoop、HBase、Hive、Spark、Sqoop、Solr、Zookeeper……等多達幾十個開源組件，為了不影響團隊成員間的工作任務(wù)協(xié)同，開發(fā)人員其實非常需要自己有一套獨立的集群環(huán)境，以便反復測試自己負責的模塊，可真實的企業(yè)開發(fā)環(huán)境往往只有一兩個大的虛擬集群，這可怎么辦?難道要給每個開發(fā)人員都配幾臺獨立的物理機器?

[[182550]]

場景二

針對每一次新版本的發(fā)布，產(chǎn)品測試組都需要反復的重裝整個平臺以便發(fā)現(xiàn)問題，而正如本文前面所闡述的那樣，大數(shù)據(jù)平臺所依賴的組件繁多，不同組件模塊依賴的底層庫也不盡相同，經(jīng)常會出現(xiàn)各種依賴沖突問題，而一旦安裝完成，就很難再讓Linux系統(tǒng)恢復到一個非常干凈的狀態(tài)，通過Remove、UnInstall、rpm -e等手動方式卸載，往往需要花費很長的時間，那如何才能快速地恢復大數(shù)據(jù)平臺集群的系統(tǒng)環(huán)境?

[[182551]]

場景三

當測試人員在測試大數(shù)據(jù)平臺過程中發(fā)現(xiàn)了一個Bug，需要保存現(xiàn)場，這里面包括相關(guān)的大數(shù)據(jù)組件配置、進程狀態(tài)、運行日志、還有一些中間數(shù)據(jù)，可是，平臺集群服務(wù)器節(jié)點數(shù)量很多，針對每個進程的配置目錄和日志文件，都相對較獨立，一般都需要專業(yè)的開發(fā)工程師或者運維工程師進入相關(guān)服務(wù)器節(jié)點，按照不同組件的個性化配置信息，手工方式收集所需的各個條目信息，然后打包匯集到日志中心服務(wù)器進行統(tǒng)一分析，而目前業(yè)界并沒有一款能夠自動分布式收集故障相關(guān)的日志系統(tǒng)，但測試工作還要繼續(xù)，怎么辦?

[[182552]]

場景四

如何把一個部署好的大數(shù)據(jù)平臺快速地遷移到其它地方?

你得注意以下幾點：

1. 如果是關(guān)鍵業(yè)務(wù)系統(tǒng)，數(shù)據(jù)不能丟;
2. 如果是遷移物理機，機器可能會壞;
3. 如果是不間斷實時在線業(yè)務(wù)，要保證快速平穩(wěn)切換。

[[182553]]

傳統(tǒng)解決方案的缺陷

想要解決這些問題，第一個想到的方案當然是用虛擬機，而筆者經(jīng)歷的團隊，之前也確實用的就是虛擬機，但這種方式并不能完美的解決以上問題，比如：

1. 雖然虛擬機也可以完成系統(tǒng)環(huán)境的遷移，但這并不是它所擅長的，不夠靈活，很笨重。
2. 虛擬機的快照可以保存當前的狀態(tài)，但要恢復回去，就得把當前正在運行的虛擬機關(guān)閉，所以并不適合頻繁保存當前狀態(tài)的業(yè)務(wù)場景。
3. 雖然可以給每個人都分配幾個虛擬機用，但它是一個完整的系統(tǒng)，本身需要較多的資源，底層物理機的資源很快就被用完了，所以我們需要尋找其它方式來彌補這些不足。

Docker技術(shù)的引入

Docker 項目的目標是實現(xiàn)輕量級的操作系統(tǒng)虛擬化解決方案，換句話說，它可以讓我們把一臺物理機虛擬成多臺來使用，而且它還可以保存修改、完整遷移到其它地方、性能損耗小等等好處，能夠很好解決我們之前遇到的問題。

那為什么不用虛擬機方案?

簡單來說，因為它比虛擬機更輕便，啟動一個Docker容器只要幾秒種的時間，在一臺物理機上可以創(chuàng)建幾百上千個容器，而虛擬機做不到。

下面是虛擬機與Docker兩種方案的實現(xiàn)原理：

虛擬機實現(xiàn)資源隔離的方法是利用獨立的OS，并利用Hypervisor虛擬化CPU、內(nèi)存、IO設(shè)備等實現(xiàn)的。例如，為了虛擬CPU，Hypervisor會為每個虛擬的CPU創(chuàng)建一個數(shù)據(jù)結(jié)構(gòu)，模擬CPU的全部寄存器的值，在適當?shù)臅r候跟蹤并修改這些值。需要指出的是在大多數(shù)情況下，虛擬機軟件代碼是直接跑在硬件上的，而不需要Hypervisor介入。只有在一些權(quán)限高的請求下，Guest OS需要運行內(nèi)核態(tài)修改CPU的寄存器數(shù)據(jù)，Hypervisor會介入，修改并維護虛擬的CPU狀態(tài)。

Hypervisor虛擬化內(nèi)存的方法是創(chuàng)建一個shadow page table。正常的情況下，一個page table可以用來實現(xiàn)從虛擬內(nèi)存到物理內(nèi)存的翻譯。在虛擬化的情況下，由于所謂的物理內(nèi)存仍然是虛擬的，因此shadow page table就要做到：虛擬內(nèi)存->虛擬的物理內(nèi)存->真正的物理內(nèi)存。

對比虛擬機實現(xiàn)資源和環(huán)境隔離的方案，docker就顯得簡練很多。docker Engine可以簡單看成對Linux的NameSpace、Cgroup、鏡像管理文件系統(tǒng)操作的封裝。docker并沒有和虛擬機一樣利用一個完全獨立的Guest OS實現(xiàn)環(huán)境隔離，它利用的是目前Linux內(nèi)核本身支持的容器方式實現(xiàn)資源和環(huán)境隔離。簡單的說，docker利用namespace實現(xiàn)系統(tǒng)環(huán)境的隔離;利用Cgroup實現(xiàn)資源限制;利用鏡像實現(xiàn)根目錄環(huán)境的隔離。

當新建一個容器時，docker不需要和虛擬機一樣重新加載操作系統(tǒng)內(nèi)核。我們知道，引導、加載操作系統(tǒng)內(nèi)核是一個比較費時費資源的過程，當新建一個虛擬機時，虛擬機軟件需要加載Guest OS，這個新建過程是分鐘級別的。而docker由于直接利用宿主機的操作系統(tǒng)，則省略了這個過程，因此新建一個docker容器只需要幾秒鐘。另外，現(xiàn)代操作系統(tǒng)是復雜的系統(tǒng)，在一臺物理機上新增加一個操作系統(tǒng)的資源開銷是比較大的，因此，docker對比虛擬機在資源消耗上也占有比較大的優(yōu)勢。事實上，在一臺物理機上我們可以很容易建立成百上千的容器，而只能建立幾個虛擬機。

可見容器是在操作系統(tǒng)層面上實現(xiàn)虛擬化，直接復用本地主機的操作系統(tǒng)，而傳統(tǒng)方式則是在硬件層面實現(xiàn)。當然，一些容器核心模塊依賴于高版本內(nèi)核，存在部分版本兼容問題。

如何基于Docker實現(xiàn)大數(shù)據(jù)平臺的敏捷部署與運維?

第一步：搭建基礎(chǔ)的Docker環(huán)境

在實踐過程中，部署一套可用的大數(shù)據(jù)平臺Docker環(huán)境，必需做好以下前提工作：

1. 搭建私有鏡像倉庫，用來統(tǒng)一存放構(gòu)建好的鏡像文件
2. 搭建一個安裝包倉庫，用來存放我們發(fā)布的各種版本的大數(shù)據(jù)組件安裝包
3. 配置多個物理機上的Dcoker容器可以相互通信，可參考官方給出的方案

第二步：為大數(shù)據(jù)平臺定制基礎(chǔ)鏡像

1.既然要在Docker容器內(nèi)安裝我們的大數(shù)據(jù)平臺，那就需要一個統(tǒng)一的Linux系統(tǒng)做為我們的Dcoker容器，像Ubuntu、CentOS等發(fā)行商都會發(fā)布自己的Docker基礎(chǔ)鏡像到Docker Hub上，如果Docker Hub上恰好沒有你需要的鏡像，也可以自己制作。

2.比如用CentOS6.8做為我們的基礎(chǔ)鏡像，那么請先把它pull下來

3.然后我們用這個鏡像創(chuàng)建一個容器，并在里面配置一些我們大數(shù)據(jù)平臺依賴的參數(shù)，比如ntpd、httpd服務(wù)等等，最終生成我們平臺專屬的基礎(chǔ)鏡像。

4.這是很關(guān)鍵的一步，有了它以后，所有人員可以隨時創(chuàng)建一個自己需要的Linux環(huán)境出來，以便在其內(nèi)進行產(chǎn)品的研究和實驗，且每個人的環(huán)境互不相干，當容器內(nèi)的環(huán)境被破壞后，可以刪掉再創(chuàng)建，這樣一來，場景一和場景二所遇到的問題也就迎刃而解。

第三步：將已經(jīng)部署好的集群做成鏡像

我們可以把已經(jīng)部署了集群的容器保存成多種鏡像，如：只包含了Hadoop的集群、同時包含Hadoop、Zookeeper、Hbase的集群，或安裝了所有組件的集群等等，然后上傳到私有倉庫，其它人需要的時候，直接啟動自已需要的集群就可以了，因為免去了部暑與配置等步驟，因而大幅度提高了工作效率，也提高了產(chǎn)品迭代速度。

上圖是已經(jīng)做好的鏡像，圖中共三種類型的鏡像：

• 第一個箭頭指基礎(chǔ)鏡像
• 第二個箭頭指的是已經(jīng)安裝了大數(shù)據(jù)平臺的鏡像，因為是分布式，所以有五個
• 第三個是單節(jié)點版的大數(shù)據(jù)集群，所以只有一個鏡像

第四步：鏡像的修改與保存

Docker提供了commit功能可以將一個正在運行的容器保存起來，假如在測試過程中遇到一個Bug并且需要先保存下來，執(zhí)行一條簡單的命令即可，如：

# docker commit container_name image:v2 

在以后需要復現(xiàn)的時候用這個鏡像創(chuàng)建容器即可，像下面這樣

# docker run -tid –name c1 image:v2 bash 

但注意，并不是所有狀態(tài)都能被保存下來，它只保存文件層面的狀態(tài)，不能保存內(nèi)存中的狀態(tài)，所以再次啟動容器的時候，容器內(nèi)的所有服務(wù)都已經(jīng)變成了停止狀態(tài)，需要再手動啟動一次，這樣就導致有些類型的Bug不能復現(xiàn)。

不過欣慰的是，Docker官方打算在后面的版本中加入checkpiont功能，它可以保存容器中的所有狀態(tài)，這樣就可以完整地復現(xiàn)Bug，這個新功能的用法就像下面這樣：

這個功能對很多人來說，絕對是個好消息!

第五步：腳本化部署、監(jiān)視、刪除

當然了，每個人都不應(yīng)該把過多的精力放在怎么使用Docker的問題上，這樣會為團隊帶來額外的工作量，最簡單的辦法當然是把所有重復性的工作腳本化，向每個人提供最簡便的使用接口，只需要一條簡單的命令就可以創(chuàng)建自己想要的集群環(huán)境，當不需要的時候一條命令即可刪除，這樣即降低了學習成本又解決了容器管理問題。

根據(jù)筆者的實踐經(jīng)驗，腳本化的實現(xiàn)應(yīng)該著重考慮幾個方面：

1. 多種類型集群的創(chuàng)建
2. 記錄每個集群的所屬者，容器所屬的物理機，創(chuàng)建時間等等
3. 可實時查看所有容器的運行狀態(tài)，物理機資源使用情況
4. 刪除指定的集群

結(jié)語

現(xiàn)在已經(jīng)有很多開源的Docker容器管理框架，但需求總是復雜多變的，并不能適用所有的場景。比如筆者所負責的大數(shù)據(jù)平臺就需要為每個容器做端口映射、內(nèi)含大數(shù)據(jù)組件的鏡像在啟動后還需做Hostname與IP映射等，總之，目前開源容器框架的易用性還有很大的改進空間，都存在一些手動配置的工作。

關(guān)于容器服務(wù)，在具體的實踐過程中，一定還會遇到很多問題，比如服務(wù)發(fā)現(xiàn)和編排。當下在應(yīng)用層面雖還算不上特別的成熟，但已經(jīng)使原本部署與配置很復雜的大數(shù)據(jù)平臺變得簡單快速，讓一部分研發(fā)團隊的產(chǎn)品迭代得到加速。當然，不管是大數(shù)據(jù)平臺產(chǎn)品，還是Docker開源社區(qū)本身，都還在不斷的完善中。

本文由 聯(lián)想大數(shù)據(jù)團隊 投稿至36大數(shù)據(jù)，并經(jīng)由36大數(shù)據(jù)編輯發(fā)布，轉(zhuǎn)載必須獲得原作者和36大數(shù)據(jù)許可，并標注來源36大數(shù)據(jù)http://www.36dsj.com/archives/75999，任何不經(jīng)同意的轉(zhuǎn)載均為侵權(quán)。