Docker和容器雲落地一年後的反思

我與容器的緣分起源於我在 Google 內部研發容器集羣管理系: Cluster Management。谷歌內部一切皆容器，搜索、視頻、大數據、內部工具等核心業務都以容器的方式運行在容器編排系統 Borg 上。2014年，隨着公司內部的「Ursquake」 (注：Urs 是負責基礎設施的高級副總裁)，我轉投到了公有云 Google Cloud Platform 的建設當中。2014年3月份，在由各部門基礎設計技術帶頭人蔘加的谷歌內部的雲峯會中，我作爲早期參與者之一加入到了 Kubernetes 的項目中。

         從2015年回國創業至今，我親身感覺到了國內對於 Docker 的追捧熱度。現在，Docker已經迅速在國內造成了「要是不知道 Docker 都很差意思和人打招呼」的火熱勢態；在互聯網巨頭和獨角獸企業中，甚有從「誰在用 Docker」轉變爲「誰沒用 Docker」之勢。

        Caicloud 基於 Kubernetes 開源技術，力爭爲企業提供 Gifee（Google’s Infrastructure for Everyone Else）的體驗。目前已經成功落地於多家國內大型企業，其中不乏傳統國有企業。在很多案例中，咱們都發現一個明顯的趨勢：不少企業一開始受到 Docker 現象的鼓吹，認爲 Docker 是萬靈藥，然而在本身嘗試進行開發、生產使用時才發現 Docker 帶來的不只僅是「坑」，更多的是侷限和對已有流程的顛覆。這裏我想從我在谷歌內部使用容器，並基於容器研發大規模生產平臺的經驗中談談現有 Docker 和谷歌容器環境的差異，並經過 Caicloud 的實際案例落地經驗總結下 Docker 自身所帶來的一些「謊話」和誤區。但願能拋磚引玉，並在產品上填補空白，實現 Gifee。

Docker的謊話

這裏用「謊話」略有誇大其詞之嫌，Docker 也確實爲軟件開發帶來了巨大的好處。而我想表達的是人們對於 Docker 的一些常見預期在現實使用中並不是像理論中那般完美。

Docker達到了環境一致性

 幾乎全部的 Docker 介紹或教程中提到的前幾個 Docker 帶來的好處之一，必有「環境一致性」。然而這句話表述的並不許確，「環境」是一個模糊和相對的概念。Docker 實現的是鏡像內部的小環境一致性，它保證了一個應用程序在一臺機器上使用 Jetty 9, 在另外一臺機器上也使用Jetty 9（經過封裝軟件中間件如 Jetty 9）。然而大中型企業用戶很快意識到，真正的難點在於如何保證「大環境」一致，即整個業務系統中衆多容器、組件、服務之間如何配置、互聯、依賴，如何保證開發、測試、生產環境能相互轉化、克隆等。這些環境、配置在容器概念之上，是容器自身沒法解決的，只能依賴集羣層面的管理工具。

Docker幫助了微服務

微服務與 Docker 是兩個徹底獨立的維度，微服務所帶來的好處徹底不依賴於你是否使用 Docker，同時微服務所帶來的問題 Docker 也沒法解決。例如，現在你們都流行將原來的巨石型應用進行微服務細粒度切分，而第一個難點就是切分的粒度。雖然不乏最佳實踐和 Rule of Thumb, 但總的邏輯是切分的粒度越細，軟件開發靈敏度越高。然而帶來的問題是管理成本的增長：更多的模塊如何進行各自的配置，更多的 API 通訊、互聯如何管理，更多的二進制（容器）如何發佈。這些問題都是 Docker 自身不能解決的，也必須經過第三方工具來進行彌補（例如 Kubernetes 的 Pod 機制就是谷歌基於內部的經驗教訓設計的一個解決方案）。

Docker實現了以應用爲中心

Docker 的大火也讓」App Centric」, 「Cloud Native」煥發了青春，Docker 確實在爲實現這二者的道路上提供了便利，但Docker自己還遠遠不能和這兩個詞劃等號。Docker 對應用雖然進行了封裝，可是應用的開發者在實踐中還遠沒法作到只要關心到 Docker 這一層便可。首先咱們仍是要關注操做系統，是否有合適的內核，是否有合適的 API 支持。其實咱們甚至要關心硬件，是 x86 架構仍是 power pc 架構。此外，咱們還須要關心引擎，是 Docker 仍是 Rocket 仍是 runC。最後，開發、運維者還要關心平臺，是 Kubernetes 仍是 Mesos 來進行生產集羣管理，並須要針對具體的底層平臺作徹底針對該平臺的部署、配置（甚至須要修改應用、框架等）。而這些都不是應用、業務所應該關心的範疇。

Docker實現了Devops

Docker 有不少開發、發佈敏捷性方面的亮點，然而很多企業用戶認爲 Docker自身就邁向了 Devops，而殘酷的現實是他們每每在真正開始使用後很快發現 Docker 帶來了額外的負擔，例如基於 Docker 的發佈流程應該是怎麼樣，應用程序打包的最佳實踐應如何（如何避免打出一個上G的包），Docker 的鏡像倉庫該如何管理（如何有效利用存儲空間、識別 Dockerhub 裏的惡意鏡像）。總之，Docker 畢竟給系統中引入了新的一層東西，業務出了問題，究竟是應用的問題仍是 Docker 的問題？最後（among many others），Docker 自身主要是進程級別的，而對於複合型、集羣化的場景（翻譯：任何一個認真的生產場景）則須要第三方的工具和系統來補足。在機器層面，如何作到跨主機的通訊、數據的遷移、跨主機的任務調度；在應用層面，如何作到用多個 Docker 鏡像/容器構形成一個複合性應用（Codis 就是一個很好的例子）。固然，Docker 的安全性也是經久不衰、流行的議題。

一個好漢三個幫

仍是要說明上述的論點旨在讓企業用戶認識到 Docker 自身不是萬靈藥，可是咱們也不能否認 Docker 對於軟件開發、發佈和計算上所帶來的變革性優點。如何基於 Docker 自身的優點更上一層樓，我認爲須要順應「社會專業化分工」，讓專業的人作專業的事，經過第三方工具一塊兒打造一個完善的生態系統。

       谷歌在十年間打造了三個集羣管理系統：Borg、Omega、Kubernetes，緣由就是基於它領先於外界多年的容器使用經驗，它清楚地意識到容器自身的侷限性（只是應用運行的一個「載體」，和其餘的載體諸入虛擬機、物理機在這個角度上甚至沒有本質區別）。在雖有 Mesos 這一開源項目的狀況下，谷歌仍是在2014年決定大力推廣 Kubernetes 項目（內部代號爲 「Project 7」），是出於幾點深思熟慮。這些出發點也在 Kubernetes 在國外衆多知名企業（如 ebay 等互聯網巨頭，或高盛、 Bloomberg 等金融巨頭）和 Caicloud 在國內一些大型甚至傳統國有企業的成功落地中獲得了驗證）：

谷歌有着更多年的大規模生產級別容器管理經驗，這裏說的「大規模」是百個數據中心、百萬臺機器、億萬個容器，且這個「經驗」既有成功也有教訓。例如經過設計 Borg 咱們清楚地意識到配置管理的重要性，聲明性管理的重要性，爲每一個服務分配獨立IP地址來避免端口衝突的重要性等。經過 Omega 也意識到了可插拔調度器的重要性，模塊化系統的重要性，以及對於任務的完成時間的不可控性等。所以 Kubernetes 但願可以將谷歌內部多年容器管理的理念、經驗、教訓以開源項目的形式傳遞給你們，而這個經驗是獨一無二的。

另外與 Mesos 的關注點不一樣（資源分配），Kubernetes 是徹底原生態面向服務和集羣化容器應用的（Mesos 面向的是「框架」），它旨在提供更多便捷的容器管理工具、機制和功能。所以除了常見的任務調度、服務發現、健康檢查和自動修復，它還提供了獨特的功能，諸如容器組管理，祕密管理，服務帳戶管理，配置管理，守護進程管理，寵物應用管理等，都是谷歌在內部形形色色應用、業務類型管理中所提煉出來的重要功能。

打造活躍、健康的開源社區：Kubernetes 是當前最活躍的開源社區，在 github 上已有1萬4千多顆星（相比於其餘容器集羣項目的數千顆星）。谷歌作開源社區也有重要意義：雖然在市場端不一樣的廠商能夠經過花樣繁多的市場手法和資金投入包裝本身的產品領先度，開源社區的健壯程度倒是沒法用錢或市場廣告買來的。谷歌經過打造開源社區能夠更客觀地展示本身在基礎設施、容器、集羣管理方面的技術優點。固然或許有誤區認爲項目不活躍是由於軟件「成熟」，項目活躍是由於項目不成熟。然而谷歌內部的代碼庫天天仍有近萬個新的 issues 被開啓，毫不是由於谷歌10多年的業務系統不成熟，而更多的是創新性的一種表現（大部分 issues 是在不斷迭代更強大的新功能——在保證穩定的基礎上）。因爲當今互聯網業務變幻無窮，創新層出不窮，任何系統都須要不斷的迭代，若是一個項目因達到「成熟」而活躍度降低，這只是該項目遭到冷落的表現。

如今的空白和將來的趨勢

不管是 Docker 仍是開源第三方集羣管理工具，如要到達 Gifee 都還有很長的路要走。這裏我僅僅拋磚引玉列舉一些空白和咱們但願和正在努力的方向。

發佈管理遠大於 CI/CD

現在談到發佈，你們想到的就是持續集成（CI）和持續發佈（CD）。然而咱們在谷歌內部實踐的發佈管理系統還包括不少其餘的方方面面，例如：

如何將鏡像的構建與代碼庫的分支構建相整合

如何作微服務架構中的聯合發佈（最重要的是保證新老版本的API可以平滑兼容）

如何作版本管理（哪一個鏡像版本運行在哪一個數據中心上）

如何作灰度發佈（根據不一樣的時間節點、步調來有策略的調整新版本的上線比率，自動比對新舊版本的用戶行爲等）

Devops 遠大於 Docker

Devops 包含方方面面，其中諸多實踐都是 Docker 自身層面所不能企及的，以谷歌爲例：

配置管理：要作到真正的大環境一致，必須將配置徹底與代碼分離，這裏的配置遠不只僅是服務之間的 IP 地址（經過 DNS 服務發現能夠解決），還包括不一樣環境下對於不一樣服務、應用的配置參數等。對於這些狀態、配置、數據、文件的維護則須要額外的配置管理系統。

分佈式測試：測試是 Devops 中不可或缺的一環，可是在大規模應用系統中，如何有效地、智能地快速自動運行系統測試則須要額外的系統；在谷歌內部咱們構建了分佈式測試系統，可以基於 Borg，有選擇地識別出收到某個 commit 影響的測試集進行高效自動化測試。

智能預警：Docker 或容器只是應用運行的載體，而 Docker 自身失效後須要第三方系統來檢測並預警。谷歌打造了複雜、靈活的預警系統，能夠支持自定義的預警規則和報警行爲。

智能故障定位：微服務架構的分佈式天性將系統問題調試變得更加複雜，一個用戶的請求在系統內部要遍歷多個服務模塊，而在出現問題時如何幫助系統管理員自動定位故障也須要額外的工具和系統來完成。

集羣管理遠大於服務管理

最後想澄清的一個名詞是」集羣管理「。如今當人們談及「集羣管理」時，容易直接和 Kubernetes，Mesos 等劃等號。然而集羣管理在谷歌內部是一個很是龐大的組織，Borg 只能算做任務管理或應用管理，除此以外一個真正的集羣管理系統還須要涉及到機器管理、網絡管理、安全管理等諸多方面：

機器管理：如何自動配置、安裝機器，如何自動進行機器層面的問題檢查與修復

網絡管理：如何與 SDN 聯動

安全管理：如何在容器的基礎上作應用、業務層面的安全檢測

 

做者介紹：

才雲 聯合創始人 & CEO張鑫：

曾爲美國谷歌軟件工程師，從事谷歌核心技術底層系統研發。 2012年至2014年，做爲主要技術人員從事谷歌數據中心（IDC）集羣管理系統（Cluster Management）的研發，該集羣系統自動管理和維護95%以上的谷歌集羣機器；帶頭開發的自動故障應對系統將谷歌集羣的故障率大大下降，爲谷歌節省了每一年千萬美圓的運維成本；做爲核心技術人員參與了谷歌雲計算平臺的系統到產品的全棧式開發；開發的圖形化應用部署（Click-to-deploy）、部署經理（Deployment Manager）等產品上線後即得到用戶普遍使用；設計了谷歌倡導的新一代「雲服務」（Managed Cloud）的設計，此理念得到了美國IBM，VMWare，Redhat等雲計算巨頭公司一致響應。

於2012獲美國頂級計算機學府Carnegie Mellon University (CMU)大學計算機博士學位，發表國際學術論文數十篇，成爲分佈式系統和網絡安全方向的學術專家，曾爲美國個性醫療初創公司SMART-MD, AllPancreas提供應用軟件平臺構架、安全技術諮詢和基於雲平臺的系統開發