隨著大資料平臺型產品方向的深入應用實踐和Docker開源社群的逐漸成熟，業界有不少的大資料研發團隊開始擁抱Docker。簡單來說，Docker會讓Hadoop平臺部署更加簡單快捷、讓研發和測試團隊整合交付更加敏捷高效、讓產線環境的運維更加有質量保障，而這背後的業務場景和具體的實踐方法有哪些？在Docker容器服務逐步走向完善的過程中，大資料平臺產品Docker模式的應用又是如何解決的？正是本文所著重闡述的。

實踐中發現問題

場景一

在大資料平臺型產品的開發過程中，經常要跟許多模組打交道，包括Hadoop、HBase、Hive、Spark、Sqoop、Solr、Zookeeper……等多達幾十個開源元件，為了不影響團隊成員間的工作任務協同，開發人員其實非常需要自己有一套獨立的叢集環境，以便反覆測試自己負責的模組，可真實的企業開發環境往往只有一兩個大的虛擬叢集，這可怎麼辦？難道要給每個開發人員都配幾臺獨立的物理機器？

場景二

針對每一次新版本的釋出，產品測試組都需要反覆的重灌整個平臺以便發現問題，而正如本文前面所闡述的那樣，大資料平臺所依賴的元件繁多，不同元件模組依賴的底層庫也不盡相同，經常會出現各種依賴衝突問題，而一旦安裝完成，就很難再讓Linux系統恢復到一個非常乾淨的狀態，通過Remove、UnInstall、rpm -e等手動方式解除安裝，往往需要花費很長的時間，那如何才能快速地恢復大資料平臺叢集的系統環境？

場景三

當測試人員在測試大資料平臺過程中發現了一個Bug，需要儲存現場，這裡麵包括相關的大資料元件配置、程序狀態、執行日誌、還有一些中間資料，可是，平臺叢集伺服器節點數量很多，針對每個程序的配置目錄和日誌檔案，都相對較獨立，一般都需要專業的開發工程師或者運維工程師進入相關伺服器節點，按照不同元件的個性化配置資訊，手工方式收集所需的各個條目資訊，然後打包彙集到日誌中心伺服器進行統一分析，而目前業界並沒有一款能夠自動分散式收集故障相關的日誌系統，但測試工作還要繼續，怎麼辦？

場景四

如何把一個部署好的大資料平臺快速地遷移到其它地方？

你得注意以下幾點：

1，如果是關鍵業務系統，資料不能丟；

2，如果是遷移物理機，機器可能會壞；

3，如果是不間斷實時線上業務，要保證快速平穩切換。

傳統解決方案的缺陷

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

1.雖然虛擬機器也可以完成系統環境的遷移，但這並不是它所擅長的，不夠靈活，很笨重。

2.虛擬機器的快照可以儲存當前的狀態，但要恢復回去，就得把當前正在執行的虛擬機器關閉，所以並不適合頻繁儲存當前狀態的業務場景。

3.雖然可以給每個人都分配幾個虛擬機器用，但它是一個完整的系統，本身需要較多的資源，底層物理機的資源很快就被用完了，所以我們需要尋找其它方式來彌補這些不足。

Docker技術的引入

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

那為什麼不用虛擬機器方案？

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

下面是虛擬機器與Docker兩種方案的實現原理：

VM設計圖

虛擬機器實現資源隔離的方法是利用獨立的OS，並利用Hypervisor虛擬化CPU、記憶體、IO裝置等實現的。例如，為了虛擬CPU，Hypervisor會為每個虛擬的CPU建立一個數據結構，模擬CPU的全部暫存器的值，在適當的時候跟蹤並修改這些值。需要指出的是在大多數情況下，虛擬機器軟體程式碼是直接跑在硬體上的，而不需要Hypervisor介入。只有在一些許可權高的請求下，Guest OS需要執行核心態修改CPU的暫存器資料，Hypervisor會介入，修改並維護虛擬的CPU狀態。

Hypervisor虛擬化記憶體的方法是建立一個shadow page table。正常的情況下，一個page table可以用來實現從虛擬記憶體到實體記憶體的翻譯。在虛擬化的情況下，由於所謂的實體記憶體仍然是虛擬的，因此shadow page table就要做到：虛擬記憶體->虛擬的實體記憶體->真正的實體記憶體。

Docker設計圖

對比虛擬機器實現資源和環境隔離的方案，docker就顯得簡練很多。docker Engine可以簡單看成對Linux的NameSpace、Cgroup、映象管理檔案系統操作的封裝。docker並沒有和虛擬機器一樣利用一個完全獨立的Guest OS實現環境隔離，它利用的是目前Linux核心本身支援的容器方式實現資源和環境隔離。簡單的說，docker利用namespace實現系統環境的隔離；利用Cgroup實現資源限制；利用映象實現根目錄環境的隔離。

當新建一個容器時，docker不需要和虛擬機器一樣重新載入作業系統核心。我們知道，引導、載入作業系統核心是一個比較費時費資源的過程，當新建一個虛擬機器時，虛擬機器軟體需要載入Guest OS，這個新建過程是分鐘級別的。而docker由於直接利用宿主機的作業系統，則省略了這個過程，因此新建一個docker容器只需要幾秒鐘。另外，現代作業系統是複雜的系統，在一臺物理機上新增加一個作業系統的資源開銷是比較大的，因此，docker對比虛擬機器在資源消耗上也佔有比較大的優勢。事實上，在一臺物理機上我們可以很容易建立成百上千的容器，而只能建立幾個虛擬機器。

可見容器是在作業系統層面上實現虛擬化，直接複用本地主機的作業系統，而傳統方式則是在硬體層面實現。當然，一些容器核心模組依賴於高版本核心，存在部分版本相容問題。

如何基於Docker實現大資料平臺的敏捷部署與運維？

第一步：搭建基礎的Docker環境

在實踐過程中，部署一套可用的大資料平臺Docker環境，必需做好以下前提工作：

1.搭建私有映象倉庫，用來統一存放構建好的映象檔案

2.搭建一個安裝包倉庫，用來存放我們釋出的各種版本的大資料元件安裝包

3.配置多個物理機上的Dcoker容器可以相互通訊，可參考官方給出的方案

第二步：為大資料平臺定製基礎映象

1.既然要在Docker容器內安裝我們的大資料平臺，那就需要一個統一的Linux系統做為我們的Dcoker容器，像Ubuntu、CentOS等發行商都會發布自己的Docker基礎映象到Docker Hub上，如果Docker Hub上恰好沒有你需要的映象，也可以自己製作。

2.比如用CentOS6.8做為我們的基礎映象，那麼請先把它pull下來

3.然後我們用這個映象建立一個容器，並在裡面配置一些我們大資料平臺依賴的引數，比如ntpd、httpd服務等等，最終生成我們平臺專屬的基礎映象。

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

第三步：將已經部署好的叢集做成映象

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

上圖是已經做好的映象，圖中共三種類型的映象：

• 第一個箭頭指基礎映象
• 第二個箭頭指的是已經安裝了大資料平臺的映象，因為是分散式，所以有五個
• 第三個是單節點版的大資料叢集，所以只有一個映象

第四步：映象的修改與儲存

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

# docker commit container_name image:v2

在以後需要復現的時候用這個映象建立容器即可，像下面這樣

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

但注意，並不是所有狀態都能被儲存下來，它只儲存檔案層面的狀態，不能儲存記憶體中的狀態，所以再次啟動容器的時候，容器內的所有服務都已經變成了停止狀態，需要再手動啟動一次，這樣就導致有些型別的Bug不能復現。

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

這個功能對很多人來說，絕對是個好訊息！

第五步：指令碼化部署、監視、刪除

當然了，每個人都不應該把過多的精力放在怎麼使用Docker的問題上，這樣會為團隊帶來額外的工作量，最簡單的辦法當然是把所有重複性的工作指令碼化，向每個人提供最簡便的使用介面，只需要一條簡單的命令就可以建立自己想要的叢集環境，當不需要的時候一條命令即可刪除，這樣即降低了學習成本又解決了容器管理問題。

根據筆者的實踐經驗，指令碼化的實現應該著重考慮幾個方面：

• 1.多種型別叢集的建立
• 2.記錄每個叢集的所屬者，容器所屬的物理機，建立時間等等
• 3.可實時檢視所有容器的執行狀態，物理機資源使用情況
• 4.刪除指定的叢集

結語

現在已經有很多開源的Docker容器管理框架，但需求總是複雜多變的，並不能適用所有的場景。比如筆者所負責的大資料平臺就需要為每個容器做埠對映、內含大資料元件的映象在啟動後還需做Hostname與IP對映等，總之，目前開源容器框架的易用性還有很大的改進空間，都存在一些手動配置的工作。

關於容器服務，在具體的實踐過程中，一定還會遇到很多問題，比如服務發現和編排。當下在應用層面雖還算不上特別的成熟，但已經使原本部署與配置很複雜的大資料平臺變得簡單快速，讓一部分研發團隊的產品迭代得到加速。當然，不管是大資料平臺產品，還是Docker開源社群本身，都還在不斷的完善中。

本文由 聯想大資料團隊 投稿至36大資料，並經由36大資料編輯釋出，轉載必須獲得原作者和36大資料許可，並標註來源36大資料http://www.36dsj.com/archives/75999，任何不經同意的轉載均為侵權。

End.