有容雲：容器驅動的PaaS平臺實現方案（上）

編者注: 本文基於上海容器大會現場演講內容，立足於實戰跟大家分享了新一代PaaS平臺構建中遇到的問題、當下主流PaaS平臺解析、企業交付經驗及心得體會等。文章較長，分為上、下兩個部分，本文為上篇。

嘉賓介紹： 馬洪喜，有容雲聯合創始人兼首席架構師。此前擔任Rancher Labs中國區技術負責人、Citrix公司資深架構師、Oracle公司虛擬化產品開發經理等職務，在容器雲、IaaS雲、桌面雲建設方面擁有較為豐富的經驗。

本次大會的大部分朋友都是以使用者身份分享了自己家的故事和經驗，我作為廠商代表之一，首先是想從一個大的面上跟大家交流下各方面的知識點，另外也給大家分享下我們遇到的別人家的故事，相信對大家有一定借鑑的意義。

下面我們進入主題。早上樑博士（編者：指Rancher Labs CEO樑勝博士）也說了，PaaS是一個老的概念了，發展到現在有老一代PaaS也有新一代PaaS，其中新一代我管它叫容器驅動的輕量級PaaS。當下業界我們能看到的一種趨勢，大家都在逐漸擯棄老的PaaS技術而擁抱容器驅動的新一代輕量級PaaS。就拿一個我們華南地區的金融客戶來說，他們想做一個比DevOps範疇還大的開發運維繫統，他們請來了傳統PaaS廠商，但是需求始終沒能得到滿足。後來我跟他們負責人聊的時候就介紹了容器驅動的新一代的輕量級PaaS，或者說是CaaS，然後發現跟他們的需求就配套了。這是一個非常典型的代表。還有一家位於北京的全國性商業銀行，跟他們聊的時候他們也在猶豫是採用老一代的PaaS技術還是直接用容器，後來交流了容器驅動的輕量級PaaS技術之後他們就沒再邀請傳統PaaS廠商來測試了，所有入圍測試的都是基於Docker容器技術的廠商。這是一些客戶的情況。那麼為什麼會出現這種情況呢？

通過這張膠片大家可以看到，老一代PaaS技術下的產品有一個特點就是非常重，封閉性比較強。當然，這之中有開源版本也有商業版本，但是如果選擇商業版本的的話你不得不等待它的版本和元件釋出步調，比如等待一個新版本的Redis元件，程式設計師都不太喜歡封閉性的東西。而新一代的容器技術無論是基於Kubernetes還是Mesos還是其它技術，它的一個特點就是更輕量，更開放，而程式設計師會感覺自己在裡面可以有貢獻，有一種參與感，這是他們的一個區別。所以我們看到，現在的客戶有很多都有這種新一代PaaS的需求，很多企業在選擇的時候都會考慮以容器為基礎的PaaS。有趣的是有些企業可能前兩年已經採購了傳統PaaS產品，但是今年他們還是會去看看新一代採用容器技術的PaaS到底能給他帶來哪些便利。大家都相信未來是採用容器技術實現PaaS的方向，那大家在選擇這種容器的PaaS方案或廠商時會重點關注哪些問題呢？我可以給大家稍微分享一下。

某世界500強保險集團

1. 開源方案，簡單易用 - 這其實也是業界一種共識。你可以是純粹的開源，也可以是商業開源。所謂商業開源，就是說你可以不是Apache或GPL協議釋出，但是你承諾向客戶開放所有原始碼等，這也是一種開源的形式。

2. 需求匹配度高，API豐富，可定製化 – 他們的另外一個要求就是你一定要有非常豐富的API介面。我不一定會用你的portal，但可能我需要做一些功能非常豐富的整合，所有你介面上有的功能API一定都要能實現，甚至說有些隱藏的功能是介面上沒有，但是API裡一定要有。

3. 服務團隊能力強 - 服務團隊的交付能力不僅僅是廠商或是服務供應商，也包括客戶自有團隊或者說自有團隊跟廠商之間形成的合作和默契。

   某全國性股份制商業銀行

4. 容器管理能力強 - 構建在容器上的PaaS平臺，需要容器的管理能力非常強，容器排程、編排策略需求比較豐富。

5. PaaS能力快速上線 - 最好客戶團隊自己就可以快速開發出構建在基於容器之上的PaaS能力模組，不需要依賴於廠商的釋出週期。

6. 應用配置管理功能豐富 - 我的應用配置，比如說我的CI、CD部署引數並非都一樣，在開發、測試、生產等環境不也各有不同。所以我的應用有大量的定製化需求，客戶希望平臺可以提供靈活的應用配置引數，哪怕是Java棧的記憶體引數也好，總之應用程式的引數一定要可定製化。

某通訊解決方案提供商

還有某通訊解決方案提供商，看看他們的關注點：

容器網路、儲存，灰度釋出等 - 他們要求比較細節，首先一點容器網路要求比較高，其次在容器的場景上構建PaaS時我儲存的問題怎樣解決？還有一個是灰度釋出，也是比較領先的課題，包括另外一個某銀行客戶，他們也提出了這個要求，他們希望應用到的是什麼場景呢？比如我想把最新的版本只傳送給深圳的IP，而其他地區IP訪問還是舊版本，或者是想把新版本只給IT中的某個部門訪問，但是其他部門訪問的還是舊版本。所以也討論到是否可以採用比如來源IP，或者用訪問標籤來做標識和區分。其實對廠商來講我們可以在不同客戶那裡聽到很多新的的需求，而這些需求可以不斷融入到我們產品中來。

某省科技廳醫療大資料專案

另外這是某省科技廳醫療大資料專案的關注點。我們可以想象，把所有醫院血液的大資料都聚集在一起，做一個健康大資料系統，做一些腫瘤早期的預測，某些疾病的篩查等，這是非常有意義的。他們不僅僅是要構建一個PaaS的大資料平臺，他們也希望基於容器技術搭建，他們有什麼需求呢？

1. 混合雲能力構建-他們想借力類似國內阿里、騰訊這樣的公有云來運作他們的大資料分析系統；

2. 容器資料儲存，大資料與容器結合-他們希望這個PaaS平臺在大資料方面有比較大建樹，具備大資料分析能力比較強的特點；

3. 本地交付團隊-便於隨時交流和提供技術支援。

以上是我列舉的不同行業客戶對構建PaaS平臺的需求。那我們的理解是什麼呢？

我們通過大量的客戶交流、客戶交付做了一個總結：專案能成功的因素至少有這兩點，首先是基於一個優良的框架或者是產品去做你的事情，大部分使用者不可能說是完全白手起家，基於Docker就去做，另一方面是比較強的服務交付團隊，無論是自己的還是邀請合作伙伴協作的團隊，至少這兩點都是不可或缺.

大家知道，對於Docker來說，它本身只是幾十兆的幾個安裝包，本身只提供了一個命令列的方式，當然現在也提供了Docker Swarm可以實現叢集管理 ,但是在生產中還是需要一個容器的管理平臺。這樣我們通過一個Docker核心的Engine加上一個容器管理平臺就構成了完整的容器服務。Container as a Services只是容器應用場景的一部分而已，他並不等於一個完整的PaaS平臺,PaaS的範疇比它要大很多。在我們的定義中，一個完整的PaaS應該包括一個很好的容器管理平臺作為堅實的基礎，上層有部署流水線、大資料、中介軟體等PaaS能力外掛，這我們稱之為構建PaaS的基礎，但其實這距離企業完整的PaaS需求還不夠，還需要一個交付團隊去補充。

我們到一家客戶去聊的時候他們就表示，你上頭搞的portal我並不關心，上面所有的東西我都需要跟我的系統做一些對接，所以你們要保證你們產品內件有比較好的機制，豐富的API介面，團隊要有能力，能跟我們一起構建符合我們需求的PaaS平臺。大家知道，開箱即用的PaaS平臺可能並不能滿足每個企業的個性化需求，所以構建PaaS有很多個性的需求。

今天我們也看到，很多朋友基於Swarm，Kubernetes、Mesos做了PaaS技術分享，也有一些基於Rancher或者是我們有容雲AppSoar的PaaS技術分享。我列出這張圖來並非做一個優劣的對比，而是做一個比喻。最著名的三劍客Swarm、Mesos、Kubernetes，它們好比發動機的引擎技術，而Rancher、AppSoar、OpenShift等他們是基於引擎技術之上構建的範圍更廣的產品或者說平臺。可能有些使用者會說，ok，我不想花更多的心思去組裝發動機、輪子、方向盤，我只是想買一輛直接就能開的車；也有一些使用者會說我想要有一些靈活的定製化，我希望配置出來的是一個我最喜歡的效能狀態，比如底盤除錯等各種都是按照我的意願來組裝的。所以我們這張圖就是告訴大家，在選擇的時候存在這樣兩種趨勢。

我花點時間跟大家談下我對三種框架的一個粗淺認識。之前也跟樑博士有過交流，這三種技術短時間內暫時還不會出現誰幹掉誰的局面，但是就我個人的觀點來看，大家選擇Kubernetes，或者Docker Swarm的時候，至少這兩種是一個完全的不同的路線，並不是從技術層面來說，而是非技術角度。圈裡人都聽過，不管是Kubernetes社群還是Docker社群，兩者之間是一種PK的關係，包括對網路棧的支援。很有意思的一個故事， Kubernetes之前發了一篇文章說為什麼我們不支援Docker的CNM結構而支援CNI，未來會有更多Docker已有的功能 Kubernetes沒有，但是Kubernetes會拿另外一種東西來做補充。這就是兩個社群背後相關利益既得者，他們的想法不一樣。

比如說Kubernetes，他們想做的事是未來大家只要用Kubernetes就好，至於底層你採用的Engine、到底是Rocket 還是Docker，你不用關心，你只需要知道Kubernetes就好。對Docker來說，主要的優勢是他們有大量使用者基礎。所羅門曾在一次技術採訪被問到面對谷歌這樣強大的競爭對手是否有壓力時，所羅門的回答是我們並不懼怕任何困難和挑戰，因為90%以上的容器使用者只用Docker。大家也可以看到，Docker馬上就會有自己的生態系統，它會逐步壯大起來。雖然今天的Swarm還相對弱小，但是大家會看到他會逐漸強大起來，所以說對於Rancher也好，對於我們有容雲自己也好，我們的選擇都是不選邊不站隊，都支援。

下面我們來談下整個CaaS框架的示例。本示例雖然是基於我們自有的產品，但是我會用一種通用的方式來告訴大家是什麼意思。簡單來說，我想用這幅圖來告訴大家一個完整的容器管理系統他應該包含哪些方面的功能。首先一點就是對底層多主機的管理。可能有人會說，大部分平臺都支援多主機管理，但我相信有一天，我們需要的是一個混合雲的狀態，我們希望企業在應對我們業務的時候，可以像流水一樣把我們的業務任意在企業私有云、或者租用的公有云之間漂移。

比如平時我的業務都部署在私有云上，遇到特殊活動比如雙十一雙十二，充紅包、促銷等時候我們擴充套件出來的業務可以自動遷移到公有云上，而且遷移的流量入口也可以從公有云那裡進來。未來如果企業要想達成這些能力，Docker是一個非常好的技術元件去完成這件事，但是我們一定要選擇一個合適的平臺，在未來或者說今天可以很好的管理混合雲業務場景的模型。

在這基礎之上我們有不同方式會對租戶或者說業務場景的切割，例如測試、生產等環境的資源等進行切割，實現類似於“多租戶”的管理。之前聽了一些朋友關於儲存、網路的介紹，都講得非常好，大家也意識到，容器時代我們面臨的來自儲存、網路的挑戰跟虛擬機器時代是一樣的。並不能說，虛擬機器時代我們踩過的坑比如說在VMware上的標準交換機、分散式交換機已經做得很好，自然在容器時代就這些問題都得到了解決。其實在虛擬機器上遇到的問題我們在容器上還要再解決一遍，這是IT的現實，甚至說以前虛擬機器沒遇到的一些新的問題和挑戰，也需要容器來解決。

就比如虛擬機器時代，他們還沒有很強的模板和映象管理功能，但是容器靠近應用，有很多新的玩法，比如你要考慮的應用配置的管理、企業私有映象的管理等，這些問題你都需要去解決。可能有很多人都在用比較傳統的Registry版本一版本二的命令列的方式在做，也可能有另外一些朋友在採取Portus、Harbor這樣的開源專案在做，我們有容雲有一款產品AppHouse，企業級私有映象倉庫，正是針對這類需求開發的，大家可以去試用下。

再往上可能會涉及到更靠近應用方面的功能。比如說應用的排程和編排，就像剛才提到的發動機之說。我想跟大家分享的是：發動機本身非常好，但是我們不應該把所有精力都放在發動機上，因為還要大的全景圖需要我們去關注，從大的趨勢來說我們的Kubernetes、Mesos、Swarm都只是其中的元件，它的地位很核心，但並不代表你選擇Kubernetes就能馬上把容器跑起來，你選擇一個發動機不能馬上就能把車開走。

更深入交流的時候有使用者甚至提出來，我的ITSM系統，我的像CMDB這樣的系統、要怎麼樣跟PaaS平臺做一個對接，這些可能未來都是大家需要考慮的問題。再往上來說就是應用商店了，對於我們今天的主題來說，其實我更想把它叫做一個PaaS Offering 的Layer。這是一個統一管理的門戶，也是我認為在一個完整的CaaS中不可或缺的部分。因為我們的PaaS還有很多能力元件在此基礎上建立起來。這張圖就是為了給大家展示一個完整的CaaS應該包括的能力。

（上篇完，下篇更新中。。。）

本文來源：http://www.youruncloud.com/blog/76.html

溫馨提示

對Docker容器技術或容器生產實施感興趣的朋友歡迎加群454565480討論。我們彙集了Docker容器技術落地實施團隊精英及業內技術派高人，線上為您分享Docker技術乾貨。我們的宗旨是為了大家擁有更專業的平臺交流Docker實戰技術，我們將定期邀請嘉賓做各類話題分享及回顧，共同實踐研究Docker容器生態圈。