前言
早在十多年前國内外的一些大廠就開始投入研發和使用容器技術，比如google，對他們來說，使用容器能夠充分利用計算資源節省硬體成本。而這幾年——衆所周知——真正把容器技術發揚光大的是docker。docker的slogan“build，ship & run anywhere”定位非常清晰，docker的出現打破了傳統運維模式裡從打包到部署的過程中環境、語言、平台不一緻的亂象，将這一整套開發運維模式标準化了，進而真正幫助企業實踐了devops和微服務化。
但是，國内的大型企業面臨技術轉型的的時候，曆史包袱太沉重，對docker的接受和部署非常緩慢。同樣地，多數的中小型企業也并未把docker作為生産環境上部署和管理服務的标配，而選擇繼續使用傳統的運維方案。造成這種現象的原因是什麼呢？可能原因之一是企業從業人員對docker的學習認知并不夠。之二是目前市面上docker的容器編排系統很多，常見的就有k8s，mesos，swarm，rancher，newben，編排系統的學習和認知成本也進一步提升了企業應用docker的難度。
企業為什麼要使用docker
這個問題的本質是企業用docker究竟能做什麼，要回答這個問題，需要我們回歸到docker本身來分析。docker本身隻是提供了一個運作環境，除了把服務跑起來之外，要讓多個服務容器協同起來工作，實際還需要一個容器編排系統。一般來說企業期望編排系統能幫助實作如下幾個目的：
定義服務棧
提供一種機制，可以用配置檔案來定義服務的網絡端口，鏡像及版本，在需要的時候通過配置可再現的建立出一整套服務。
服務發現、注冊和登出
需要在建立服務後自動建立dns記錄用于通路相關容器，容器狀态健康後注冊srv資訊。
健康檢查
可以精細化控制服務注冊時機，以支援容器正常啟動後的初始化完成後再注冊服務，以對外提供穩定可用的服務。
自動擴容和縮容
實時監測容器cpu和記憶體使用情況，當容器平均性能名額超過門檻值一段時間後啟動自動擴容，建立更多容器以達到門檻值要求，當沒有主機資源運作新容器時，自動申請新主機。當一段時間負載持續低于門檻值啟動縮容優先删除新建立容器和主機，以釋放資源和降低營運成本。
合理的排程
要求最大限度的榨取主機資源避免浪費，并可實作快速的建立容器，減少鏡像拉取時間和磁盤空間浪費。
負載均衡和高可用
使用docker的三個階段
根據我們的觀察，根據企業規模和階段性需求的不同，在使用docker技術的時候分了三個階段來進行。
階段一：利用開源工具實作一定功能
由于一個docker容器隻是一個（或一組）程序的封裝，一個容器需要綁定主控端的端口來向主控端之外的網絡提供服務，為了避免端口沖突，對于需要暴露端口的容器，docker會随機綁定一個主控端端口，這個時候就需要服務發現來幫助不同機器上的服務來進行通信了。舉例一個簡單的方案：docker-discover和docker-register。
這個方案提供了一套系統的幾個基本功能：應用釋出，服務發現，負載均衡和程序守護。除了提供一緻的運作環境使服務的釋出和復原比較可控，這套簡單的系統在釋出流程上還是像傳統運維一樣需要遠端執行腳本，功能比較簡單，适用于小企業，随着後端系統成長起來，很快就不夠用了。
階段二：開源容器編排工具
第二個階段是選擇開源容器編排架構來管理，常見的開源容器編排工具有kubernetes，swarm和mesos 。市面上也有同時支援這三種開源容器編排引擎的容器管理打包方案，通常作為入門級容器管理平台使用。這種入門級的方案雖然是開源的，但技術上的文檔明顯欠缺，社群中的使用難題也很少有公司之外的contributor，當暴露一些難題的時候就很難解決，這點和kubernetes有很大不同。
kubernetes提供的是一個架構，要求使用者對他的元件有一定程度了解，使用之前需要不少配置工作，對docker入門者來說，學習能力要求很高，不過好在社群有各種contributor，提供了很多幫助部署的installer。除了對學習能力有要求以外，對中小企業來說，對基礎設施的投入肯定不如大企業，一般沒有專人去熟悉kubernetes這種大型開源項目。
當然，像kubernetes這樣的容器編排系統本身很複雜，體量很大，很多企業也出現過當丢包嚴重的時候問題排查起來很困難的局面，畢竟要深入到龐大的代碼中定位問題本身就是件很不容易的事情。
雖然現在kubernetes是容器排程主力軍，但我們認為排程引擎是容器最核心的子產品，在paas這個關鍵的雲計算領域不應該由國外來主導，特别是在軍工、政務、金融等領域，我們需要自主研發的排程引擎，隻有這樣我們才能掌握雲計算基礎架構的核心技術。于是就有了第三個階段的使用建議：高定制化的容器雲平台。
基于docker的paas/caas平台
為了适應國内的企業需求，出現了很多運用docker開源排程架構的容器雲平台，這些平台大都有一個特點：“服務本地化，核心開源化”。我們認為這并不是真正的本地化，真正的本地化應該是在滿足不同領域不同企業的上雲和轉型需求的同時能随時響應定制化需求。基于這樣的思想，被稱為“中國的k8s”的容器排程引擎newben應運而生。
newben是精靈雲全自主研發的容器排程引擎，也是目前國内唯一自研引擎，具備多項技術專利和著作專利，定制能力強、支撐功能豐富，能為容器化的應用提供部署運作、資源排程、服務發現和動态伸縮等一系列完整功能。如下圖所示，将newben、k8s、mesos和swarm進行詳細對比，會發現newben事實上吸取了各開源排程引擎的長處，在網絡、服務發現、負載均衡、彈性伸縮、高可用、ci/cd內建、鏡像內建、日志監控等方面都有着非常大的優勢。
（newben和開源容器排程架構的對比）
ghostcloud ecos平台是精靈雲旗下的企業級容器雲平台，内置自研容器排程引擎newben，同時适配多種開源架構，如k8s、swarm等。由ghostcloud精靈雲全自主研發的ecos平台基于精靈雲paas/caas雲核心功能子產品，能支援私有雲和混合雲部署，滿足企業的容器雲部署需求，為企業研發、運維及新業務上線部署提供了一整套解決方案和管理平台。不僅幫助企業大幅削減成本和提升效率，幫助傳統企業加速所需業務網際網路化程序，更能幫助網際網路企業加快産品疊代，提高産品市場占有率。
（ecos的平台架構）
ghostcloud ecos的應用場景
ghostcloud ecos平台作為統一的平台, 可服務于多個解決方案，應用到政務、教育、金融、網際網路、醫療等多個行業和領域。接下來我們以金融行業為例來說明。
（ecos應用場景）
傳統的金融行業受迫于銀監會的要求（容器作為兩項最核心技術之一被寫入十三五規劃）需要在企業内部推行雲計算技術，同時網際網路金融的爆發式增長，傳統金融公司在技術上無法應對自如。螞蟻金服和萬達金融等大型網際網路金融公司都在使用容器作為背景支撐平台，傳統金融企業也需要類似的paas/caas平台，但是本身沒有搭建和維護能力。
面對這些需求，需要從幾個方面解決：
• 整合系統内部資源，推行基于容器的開發、測試、生産和運維一體的paas平台；
• 推行devops，開發運維一體化，降低運維成本；
• 推行靈活和ci/cd，加快系統傳遞和部署；
• 使用基于容器的彈性負載均衡系統，适配突發流量；
• 加強開源容器系統，對鏡像及鏡像倉庫進行私有化定制。
在具體的實施中，使用ecos容器雲平台，對倉庫和鏡像進行加強，在内網和公網環境混合管理做安全隔離，借助平台自帶的ci/cd流程，标準化研發流程；借助ecos的資源排程架構，動态資源調配。通過容器隻暴露特定端口，提升了整個系統的安全性，系統開發速度和上線速度大幅度提升，團隊整體響應速度也大幅度提升。通過商用docker雲平台，提升了it部門的技術能力，更好的适應了未來業務發展需求，實體資源使用率提升，能夠很好的應對突發的流量暴增，在有限資源下提升了系統并發量。
結語
國内的企業需要在使用docker程序中選擇更本土化的容器編排系統，隻有擁有核心可控的技術才能真正開展雲計算基礎設施建設。推薦選擇能針對個性化需求做定制化解決方案的paas/caas容器雲平台——ghostcloud ecos。