一個虛擬化老兵的Docker淺見

來自： http://dockone.io/article/1008

近來Docker原來越火，也吸引了我這個6年虛擬化從業者的注意。筆者對Docker的技術細節并不十分熟悉，也還在學習過程中。但筆者見證了虛擬化技術興起的全過程，參考對照虛擬化技術，筆者對Docker為什么會在當前這個時間點火起來，Docker與虛擬化的技術對比，我們該怎么辦等相關問題有一些自己的理解。意見不一定正確，歡迎拍磚。

Dokcer和Kubernetes為什么此時興起

嘗過虛擬化的甜，想來點應用的辣

隨著x86服務器，KVM等虛擬化技術，以及OpenStack等IaaS管理平臺的普及和成熟，VM可以在不同X86服務器廠商的硬件平臺上在線無縫遷移了。硬件差異化不斷縮小甚至消失，軟件的重要性不斷提升，IT真正進入"軟件定義數據中心"的時代。并且人們發現，虛擬化后的IT在部署簡單化，資源利用率，高可用性，維護便利性等方面收獲了的巨大的收益。在這個背景下，IT部門提出了更高的要求，如何將應用在不同操作系統間實現無縫遷移，將開發和生產統一，做到"構建一次，到處運行"？并且能否讓應用的部署，分發，負載均衡，高可用性，監控運維等方面也與虛擬機一樣有更統一和更簡單的方法呢？在這個時間點，Docker和Kubernetes出現了。

受微服務理念的“蠱惑”

微服務的思路不是開發一個巨大的單體式的應用，而是將應用分解為小的、互相連接的微服務。一個微服務一般完成某個特定的功能。一些微服務還會發布API給其它微服務和應用客戶端使用。運行時，一個微服務實例就可以是一個Docker容器，所以微服務天然需要Docker。微服務帶來的好處有：第一軟件工程上多部門更好協作，第二軟件本身的擴展性更強。下圖是微服務的搜索圖，而我們知道Docker正是2013、2014年開始火起來，所以說微服務是與Docker是"相得益彰"的關系。

互聯網公司DevOps們"搖旗吶喊"

DevOps興起于互聯網公司，基本理念是開發和運維合為一體，把開源工具拿過來再根據自己的業務特點稍加改動，測試通過后就上線支撐公司的產品和服務，并一邊運維一邊改進。

在DevOps出現之前，開發的工作流程是：市場調研，需求分析，系統設計，軟件編碼，單元測試，集成測試，系統測試，軟件發布。運維人員的工作流程是：安裝服務器，安裝軟件，配置軟件，系統運維。很明顯在老的模型中，運維人員地位低下，整天做著重復且枯燥的工作，并且開發和運維之間相互等待資源環境，軟件版本，以及buglist。所以能不能運維專注于：1）提供，維護，監控平臺；2）提供工具。開發利用運維的工具發布，維護自己的產品或服務呢？互聯網的神仙/屌絲們很快發現，Docker的“構建一次，到處運行”正是他們需要的。

組織IT服務云化，平臺化的"Next"

IaaS平臺經過長時間的市場教育和技術教育，終于在2015、2016開始大規模的普及化和落地。政府，軍工，事業單位，大中小型企業正如火如荼的進行著IT服務云化的過程。道路選擇上中小型企業選擇的是公有云，政府，軍工，事業單位，大型企業一般都是自建私有云，像12306這種某時間段對IT有大規模溢出需求的單位，更適合的是混合云。

所有的組織都需面對客戶，也都有的業務和數據。當今世界發展的趨勢是：

1. 用戶體驗越來越重要（產品過度泛濫+燒錢的大有人在+別人都在"取悅"用戶） ；
2. 業務更替越來越頻繁（N個試錯-->1個OK-->繼續N個試錯）；
3. 數據就是資產（不解釋）。

所以呢，未來，IT服務需要更輕量（100~1000容器/Node），更高效（無GuestOS開銷），更敏捷（DevOps理念）的平臺。當前，考慮原有業務遷移的便利性，筆者認為以虛擬化為核心的云平臺更勝任。

Docker與虛擬化的比對分析

淺層技術對比

對Docker稍有接觸的人應該都見過下圖，無需更多解釋，Dokcer減少Guest OS這一層級，所以更輕量和更高性能。

深層技術對比

但用戶很少直接使用Docker，而是要使用Docker為核心的平臺系統，那其實對比項還是蠻多的。

從上表可以看出：a. 容器更高效，更敏捷，更好維護；b. 虛擬化在安全性和支持廣泛性上有天然優勢；c. 管理平臺成熟度上，Docker和Kubernetes還有很長的路要走。

適用場景不同

對于高I/O要求的業務，例如數據庫服務，建議部署Docker+物理機，因為在虛擬機中部署Docker，I/O性能將受到虛擬機的限制。對于虛擬桌面服務等強調租戶權限和安全的業務，建議采用虛擬機方式，虛擬機的多租戶強隔離特性，保證租戶在擁有虛機root權限的同時，其他租戶和主機的安全。此外，大部分業務系統將適用于虛擬機+Docker形式的組合，操作系統和Docker引擎采用虛擬機鏡像封裝，平臺軟件、業務組件等與業務相關軟件采用容器鏡像封裝，為實現安全隔離和資源的高利用率，基本應該遵循：不同租戶的業務運行采用虛擬機隔離，相似類型的業務部署在同一組容器上的思路。

我們該怎么辦

首先介紹下筆者公司產品的情況，2011年開始我們以KVM為基礎自主開發了OPV-Suite平臺（IaaS云平臺）和OPV-VDI（桌面虛擬化）產品，主要面向私有云客戶，也向公有云服務商供應產品和技術。面對Docker的挑戰，我們在確定還需在虛擬化產品繼續深耕下去的同時，還該怎么辦呢？

未來云產業格局分布

盜一張我的領導對云產業玩家的分析圖。明顯看出云產業鏈里的價值高地正在往云服務商處聚集，當然這個服務可以是公有云服務，也可以是私有云服務，還可以是混合云服務。

筆者一直認為，云消費者并不關心，你這個服務商使用的是虛擬化技術還是Docker，更不關心你自己寫的還是基于開源平臺改的。他關心的是你的服務是否可靠，是否穩定，是否便宜，是否安全。所以，根據你團隊的特點，選擇你們自己最擅長的技術，為云消費者提供有競爭力的服務，才是未來我們能否立足的核心。

技術上先看看別人家怎么做

用戶不關心技術，我們的關心呀。首先聲明，下表的分析數據是從2016容器大會上各廠商PPT上了解到的，必然既不全面也不深刻。

可以明顯看出分為三個陣容：基于IaaS云平臺，基于Kubernetes，基于Mesos；單從數量上看勢均力敵。為什么會這樣，筆者認為第一Docker還在迅速發展過程中，到底怎么做大家還沒有統一的意見。第二各個互聯網公司的技術團隊擅長的東西并不一樣。

我們怎么辦

好，該得出結論了，我們該怎么辦呢？

提供用戶需要的云計算產品和服務，適合虛擬化的就虛擬化，適合Docker的就用Docker，并以自己團隊最擅長的方式構建出平臺來。

DCOS應該是怎樣的？

筆者認為融合了虛擬化和容器的平臺，我們暫且叫它DCOS（數據中心操作系統）的體系結構應該是這樣的，篇幅有限，筆者將在第二篇文章中詳細介紹各模塊的功能和實現方法。


原文鏈接