Docker的優劣分析
大小：0.6 MB 人氣： 2017-10-09 需要積分：1
責編：魏偉，歡迎投稿和咨詢報道，詳情聯系weiwei@csdn.net
本文節選自《程序員》，謝絕轉載，更多精彩，請訂閱2016年《程序員》
我與容器的緣分起源于我在Google內部研發容器集群管理系： Cluster Management。Google內部一切皆容器，搜索、視頻、大數據、內部工具等核心業務都以容器的方式運行在容器編排系統Borg上。2014年，隨著公司內部的“Ursquake” （注：Urs是負責基礎設施的高級副總裁），我轉投到了公有云Google Cloud Platform的建設當中。2014年3月份，在由各部門基礎設計技術帶頭人參加的Google內部的云峰會中，我做為早起參與者之一加入到了Kubernetes項目中。
從2015年回國創業至今，我親身感受到了國內對于Docker的追捧熱度。如今，Docker已經迅速在國內形成了“要是不知道Docker都不好意思和人打招呼”的火熱態勢；在互聯網巨頭和獨角獸企業中，甚有從“誰在用Docker”轉變為“誰沒用Docker”之勢。
然而，我發現一個 明顯的趨勢：很多企業一開始受到Docker現象的鼓舞，認為Docker是萬靈藥，然而在自己嘗試進行開發、生產使用時才發現它帶來的不僅僅是“坑”，更多的是局限和對已有流程的顛覆。這里我想從我在Google內部使用容器，并基于容器研發大規模生產平臺的經驗中 談談現有Docker和Google容器環境的差別，并通過Caicloud的實際案例落地經驗總結Docker自身的“謊言”和誤區。希望能拋磚引玉，并在產品上填補空白，實現Gifee。
Docker的“謊言”
這里用“謊言”略有夸大其詞之嫌，Docker也確實為軟件開發帶來了巨大好處。而我想表達的是人們對于Docker在現實使用中的常見預期并非像理論中那般完美。
Docker達到了環境一致性
幾乎所有的Docker介紹或教程中提到的前幾個好處，必有“環境一致性”。然而這句話表述得并不準確，“環境”是一個模糊和相對概念。Docker實現的是鏡像內部的小環境一致性，它保證了一個應用程序在一臺機器上使用Jetty 9， 在另一臺機器上也使用Jetty 9（通過封裝軟件中間件如Jetty 9）。然而大中型企業用戶很快意識到，真正的難點在于如何保證“大環境”一致，即整個業務系統中眾多容器、組件、服務之間如何配置、互聯、依賴，如何保證開發、測試、生產環境相互轉化、克隆等。這些環境、配置在容器概念之上，是容器自身無法解決的，只能依賴集群層面的管理工具。
Docker幫助了微服務
微服務與Docker是兩個完全獨立的維度，微服務所帶來的好處完全不依賴于你是否使用Docker，同時微服務所帶來的問題Docker也無法解決。例如，如今大家都流行將原來的巨石型應用進行微服務細粒度切分，而第一個難點就是切分的粒度。雖然不乏最佳實踐和Rule of Thumb， 但總的邏輯是切分的粒度越細，軟件開發靈敏度越高。然而帶來的問題是管理成本的增加：更多的模塊如何進行各自的配置，更多的API通信、互聯如何管理，更多的二進制（容器）如何發布。這些問題都是Docker自身不能解決的，也必須通過第三方工具來進行彌補（例如Kubernetes的Pod機制就是Google基于內部的經驗教訓設計的一個解決方案）。
Docker實現了以應用為中心
Docker的大火也讓“App Centric”，“Cloud Native”煥發了青春，Docker確實為實現這兩者的提供了便利，但它本身還遠遠不能和這兩個詞劃等號。Docker對應用雖然進行了封裝，但是應用的開發者在實踐中還遠無法做到只要關心到Docker這一層即可。首先我們還是要關注操作系統，是否有合適的內核，是否有合適的API支持。我們甚至要關心硬件，是x86架構還是PowerPC架構。此外，我們還需要關心引擎是Docker、Rocket還是runC。最后，開發、運維者還要關心平臺，是Kubernetes還是Mesos來進行生產集群管理，并需要針對具體的底層平臺做完全針對該平臺的部署、配置（甚至需要修改應用、框架等）。而這些都不是應用、業務所應該關心的范疇。
Docker實現了DevOps
Docker有很多開發、發布敏捷性方面的亮點，然而不少企業用戶認為Docker自身就邁向了DevOps，而殘酷的現實是他們往往在真正開始使用后很快發現Docker帶來了額外的負擔，例如基于Docker的發布流程應該是怎么樣，應用程序打包的最佳實踐應如何（如何避免打出一個上G的包），Docker的鏡像倉庫該如何管理（如何有效利用存儲空間、識別Dockerhub里的惡意鏡像）。總之，Docker畢竟給系統引入了新的一層，業務出了問題，到底是應用的問題還是Docker的問題？最后（among many others），Docker自身主要是進程級別的，而對于復合型、集群化的場景（任何一個認真的生產場景）則需要第三方的工具和系統來補足。在機器層面，如何做到跨主機的通信、數據的遷移、跨主機的任務調度；在應用層面，如何做到用多個Docker鏡像/容器構造成一個復合性應用（Codis就是一個很好的例子）。當然，Docker的安全性也是經久不衰、流行的議題。
集群工具和Kubernetes的迅猛生產落地
上述的論點旨在讓企業用戶認識到Docker自身不是萬靈藥，但是我們也不可否認Docker對于軟件開發、發布和計算上所帶來的變革性優勢。如何基于Docker自身的優勢更上一層樓，我認為需要順應“社會專業化分工”，讓專業的人做專業的事，通過第三方工具一起打造一個完善的生態系統。
Google在十年間打造了三個集群管理系統：Borg、Omega、Kubernetes，原因就是基于它領先于外界多年的容器使用經驗，清楚地意識到容器自身的局限（只是應用運行的一個“載體”，和其他的載體如虛擬機、物理機在這個角度上甚至沒有本質區別）。在雖有Mesos這一開源項目的情況下，Google還是在2014年決定大力推廣Kubernetes項目（內部代號為 “Project 7”），是出于幾點深思熟慮。 這些出發點也在國外眾多知名企業（如eBay等互聯網巨頭，或高盛、 Bloomberg等金融巨頭）和Caicloud在國內一些大型甚至傳統國有企業的成功落地中得到了驗證：
Google有著更多年的大規模生產級別容器管理經驗，這里說的“大規模”是百個數據中心、百萬臺機器、億萬個容器，且這個“經驗”既有成功也有教訓。例如通過設計Borg我們清楚地意識到配置管理的重要性，聲明性管理的重要性，為每個服務分配獨立IP地址來避免端口沖突的重要性等。通過Omega也意識到了可插拔調度器的重要性，模塊化系統的重要性，以及對于任務的完成時間的不可控等。因此Kubernetes希望能夠將Google內部多年容器管理的理念、經驗、教訓以開源項目的形式傳遞給大家，而這個經驗是獨一無二的。
另外與Mesos的關注點不同（資源分配），Kubernetes是完全原生態面向服務和集群化容器應用的（Mesos面向的是“框架”），它旨在提供更多便捷的容器管理工具、機制和功能。因此除了常見的任務調度、服務發現、健康檢查和自動修復，它還提供了獨特的功能，諸如容器組管理、秘密數據管理、服務賬戶管理、配置管理、守護進程管理，還有狀態應用管理等，都是Google在內部形形色色應用、業務類型管理中所提煉出來的重要功能。
打造活躍、健康的開源社區：Kubernetes是當前最活躍的開源社區，在GitHub上已有1萬4千多顆星（相比于其他容器集群項目的數千顆星）。Google做開源社區也有重要意義：雖然在市場端不同的廠商可以通過花樣繁多的市場手法和資金投入包裝自己的產品，開源社區的健壯程度卻是無法用錢或市場廣告買來的。Google通過打造開源社區可以更客觀地展現自己在基礎設施、容器、集群管理方面的技術優勢。當然或許有誤區認為項目不活躍是因為軟件“成熟”，項目活躍是因為項目不成熟。然而Google內部的代碼庫每天仍有近萬個新的issues被開啟，絕不是因為其十多年的業務系統不成熟，而更多的是創新的一種表現（大部分issues是在不斷迭代更強大的新功能——在保證穩定的基礎上）。由于當今互聯網業務千變萬化，創新層出不窮，任何系統都需要不斷迭代，如果一個項目因達到“成熟”而活躍度下降，這只是該項目遭到冷落的表現。
現在的空白和未來趨勢
無論Docker還是第三方開源集群管理工具，如要到達Gifee都還有很長的路要走。這里我僅僅拋磚引玉列舉一些空白及我們希望和正在努力的方向。
發布管理遠大于CI/CD
如今談到發布，大家想到的就是持續集成（CI）和持續發布（CD）。然而Google內部實踐的發布管理系統還包括很多其他方方面面，例如：
如何將鏡像構建與代碼庫的分支構建相整合；
如何做微服務架構中的聯合發布（最重要的是保證新老版本的API能夠平滑兼容）；
如何做版本管理（哪個鏡像版本運行在哪個數據中心上）；
如何做灰度發布（根據不同的時間節點、步調來有策略的調整新版本的上線比率，自動比對新舊版本的用戶行為等）。
DevOps遠大于Docker
DevOps包含方方面面，其中諸多實踐都是Docker自身層面所不能企及的，以Google為例：
配置管理：要做到真正的大環境一致，必須將配置完全與代碼分離，這里的配置遠不僅僅是服務之間的IP地址（通過DNS服務發現可以解決），還包括不同環境下對于不同服務、應用的配置參數等。對于這些狀態、配置、數據、文件的維護則需要額外的配置管理系統。
分布式測試：測試是DevOps中不可或缺的一環，但在大規模應用系統中，如何有效地、智能地快速自動運行系統測試則需要額外的系統；在Google內部構建了分布式測試系統，能夠基于Borg，有選擇地識別出收到某個commit影響的測試集進行高效自動化測試。
智能預警：Docker或容器只是應用運行的載體，而Docker自身失效后需要第三方系統來檢測并預警。Google打造了復雜、靈活的預警系統，可以支持自定義的預警規則和報警行為。
智能故障定位：微服務架構的分布式天性將系統問題調試變得更加復雜，一個用戶的請求在系統內部要遍歷多個服務模塊，而在出現問題時，如何幫助系統管理員自動定位故障也需要額外的工具和系統來完成。
集群管理遠大于服務管理
最后想澄清的一個名詞是“集群管理”。現在當人們談及“集群管理”時，容易直接和Kubernetes，Mesos等劃等號。然而集群管理在Google內部是一個非常龐大的組織，Borg只能算作任務管理或應用管理，除此之外一個真正的集群管理系統還需要諸如機器管理、網絡管理、安全管理等諸多方面：
機器管理：如何自動配置、安裝機器，如何自動進行機器層面的問題檢查與修復；
網絡管理：如何與SDN聯動；
安全管理：如何在容器的基礎上做應用、業務層面的安全檢測。
?
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%