編者注:

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

下面我花一點時間跟大家分享下比較乾貨的東西。比如說容器的網路，之前我們也聽了一些專家談到Flannel，Calico 等等，但是我不知道大家有沒有注意到，國內外在談容器網路的時候更多的時候會再談Overlay網的構建，比如IPSec、VXLAN等等，都是標榜所謂的SDN思路，其實也就是隧道技術的構建。去年的時候我跟很多朋友去談，大家都說很好啊很先進啊，但是今年再去談的時候發現大家已經不感冒了。大家對容器已經有了深入的認識，已經開始考慮現實的問題。這裡有幾個故事分享給大家。

我們南區的一家銀行客戶，他們為什麼會不喜歡Overlay呢，他們說的是因為網路團隊不具備Troubleshooting Overlay網路的能力; 而北區一個銀行客戶，他們道理是說我們已經採用了其他SDN的解決方案，我不希望你在裡面再打個洞。還有上海的一個客戶，不喜歡任何形式的Overlay，因為它效能drop得很厲害。基於各方面的考慮，我發現越來越多的客戶不喜歡用Overlay的容器網路。而我覺得最根本的原因，無論我們作為廠商跟客戶交流還是客戶自己去談容器專案或者啟動容器專案時，我想源動力更多的是來自於開發部門、運維部門，很少有網路部門牽頭說我要弄容器。對於網路部門來說，當你去溝通需要搞什麼容器或者更牛的技術的時候，他們的反饋會是隻要不改變已有的網路你怎麼搞都行，但是如果你想動我的網路我是不會同意的，所以我想這是個很現實的問題。我們的思路是說，Overlay網路很好，但是我們基於現實考慮，怎樣構建一個跟傳統IT網路相相容的容器網路。

另外一方面是容器的儲存，大家都在談，容器最好應用在無資料狀態的場景。但是如果大家對容器是非常有信心的態度的話，我相信早晚有一天我們所有的業務，包括我們所有的有狀態應用或是無狀態應用，都會跑在容器裡面。或者說這些問題早晚有一天是要解決的。我們有容雲內部有個專案，就是要解決好容器資料的問題。比如，是否可以由程式設計師來指出他的程式希望跑到什麼型別儲存上去，當應用部署到容器平臺上的的時候，系統可以自動識別到由程式設計師提供的儲存使用標籤，比如說你希望把Application執行在IO效能很高的儲存上，那我們的 儲存控制器就能自動把 應用程式接駁到SSD這邊來。如果我們看到你的資料標籤是希望支援一個每天晚上12點的自動拍照，那我們的儲存控制器會自動幫你做這些工作。現在我們在做這方面的工作的原因之一是，傳統的storage方案都不是天然為Docker去開發的，這些storage都不是Native 的container storage。所以我們在做的就是從零開始構築一個自己的儲存體系，一個分散式儲存，我們的分散式儲存完全是根據Docker或者說容器雲的場景來開發的。這個產品將在今年下半年釋出。

下面我們來聊聊基於CaaS的PaaS平臺體系架構。但是並不是所有架構都長這個樣子，這只是個示例而已。大家都很熟悉，在剛才在上一張膠片中也見到過，下面我們就一起來看看PaaS offering能力構建，比如說大資料分析體系，大資料的一些外掛，還有一些中介軟體，這些都需要在一個良好CaaS平臺上構建起來的PaaS能力。

對於一個企業的私有映象倉庫來說，它不僅僅是經過CI進行程式碼構建映象並管理起來那麼簡單，他還涉及到一些許可權的概念在裡面。比如說，經過CI之後，你希望你預設生成的Docker映象是在企業私有映象倉庫Dev的這樣一個隔離空間之內，因為你肯定希望你的企業有一個統一的映象庫，其次你不希望你的映象被任何人都可以拉去。比如你現在通過CI自動生成的一個映象，還未經過測試，處於Dirty狀態，你肯定不希望這種Dirty狀態的映象被你Ops的同事拉取下來並且部署到本地生產環境中。即使是手誤你也不希望他這麼做，所以一個良好的企業私有映象倉庫管理應該配套一個基於專案或者是基於許可權的管理。比如說我的CI生成的映象包預設是在一個叫Dev的空間內，我的Ops的團隊現在並不能把它拉下來。但是在經過充分測試通過以後，產品經理做一個Action，把映象從Dev轉移到Staging或是Production 空間，經過這個動作之後Ops才能把它部署到生產環境中去。

再往上可能會涉及到一些軟體版本管理，比如剛提到的灰度釋出、開發者門戶等等， 越往上可能每個企業都需要一些個性化和定製化的內容，這裡不再詳述。

這張圖早上在樑博士的分享上相信大家也看到了，這裡我們只是用它來做個舉例。因為我們看到越來越多的產品有了這種功能，基於Docker的易於部署和平臺無關性特點，建造出來的Catalog應用商店模式，我相信這個趨勢未來會越來越多，我們已經看到很多產品都在做這個功能了。簡而言之就是一個基於固定模式的配置，或者說檔案的定義，可以把一個系統整個打包到應用商店上，圖形介面可以把它看成是PaaS平臺的看板，每個圖示代表了一種構建應用或者中介軟體的PaaS能力，比如我們CICD、大資料處理的能力等等，利用以容器為基礎的輕量級的PaaS平臺，這種平臺能力的構建我們可以自己把控，而不是說一個廠商他釋出了這個軟體你才有。打個比方，我們需要一個介面，這種介面可能現在還沒有，但是我們可以自己去開發，或者說某一天你看到網上有人已經開發了，那你就可以直接把它拿過來放在你的應用商店上，就可以去用。這是我們整個構建PaaS offering能力的想法，我們正在做這個事情，我也相信未來這個市場會越來越繁榮。

我舉個具體的例子來說，不管是對於Rancher還是對於我們有容雲來說，我們怎麼從技術角度做到應用市場讓每個人貢獻，去交換和共享你的應用呢？這裡有個最關鍵的地方：Docker映象沒有什麼出奇的地方，但是需要一個方式把你整個的業務系統描述清楚，你可以看到你的系統是分幾層的。

比如我們看到，上面有一個WebLogic的中介軟體產品，大家可以看到它是分層的；上面有個負載均衡，最下面有個Weblogic容器的例項，映象來至於什麼地方等都描述得很清楚。當然，Docker-Compose就可以幫我們做這個事情，但實際上，Docker-Compose無論是第一個版本還是現在的版本，他在描述整個系統全貌的時候語法還是有些晦澀，他有一些功能是描述不清楚的。

比如說，我希望我的負載均衡能夠有一個基於Cookie Insert的會話保持的能力，我希望對我的Weblogc上的某個應用進行健康檢查的判斷、包括訪問頁面時我希望得到什麼反饋等等。你會發現你的應用程式屬性越高階，你就越需要一個更具體的、特殊化的方式去實現，而不是Docker本身自帶的元件。

對於高階屬性的東西Docker-Compose往往是預設它並不能給到你。而Rancher的做法在業界也是屬於比較創新的，也有很多人在效仿，就是在預設的Docker -Compose基礎之上擴展出一個附加一個Rancher compose的附加屬性配置，這個附加配置會更詳細的定義配置，比如說我的負載均衡的演算法是什麼樣子，我的健康檢查策略如何，我的叢集節點有多少個成員等等，這樣的話如果把這兩個檔案放在一起，他就構成了一個完整的IT系統，無論PaaS的能力外掛，是還傳統的後臺系統，都定義的很清楚，我把它定義為PaaS Offering的能力元件，或者說是一個應用商城。

接下來我們可以在部署的時候用定義的能力做一些具體配置。大家看到我在部署是基於WebLogic上應用的時候，並不是說要把你WebLogic的空的domain部署出來，而是要把你的業務部署出來，要把你的業務可以跑在環境上，這才是我要做的事情。在我實際部署的時候，你只要在配置表單中告訴我你的WAR包在什麼地方，你的JDBC資訊是怎麼樣的，那麼接下來在實際部署的時候，你的應用連同支撐它執行的環境完全可以一鍵部署出來。而不是像傳統部署流程那樣需要來來回回的流程，現在你只需要一步，到應用商店上去，選擇你需要的應用，把你的應用位置告訴我，把你的JDBC資訊告訴我，然後配置好點選，就能幫你完成。

而且最酷的不是說這是我們產品本身的功能，而是任何人都可以貢獻的，這個功能模組大家也可以去編寫和貢獻，你可以做得比它更好，而且有了模組之後可以分享，比如說我把我的地址資訊告訴我的朋友，他的系統中只要配一個我的商店的介面，它開啟自己的系統是也能看到我應用上店上的模組，而且我的應用商店模組有了改變之後，他只需要重新整理下他的應用商店門戶，也可以同步看到更新。所以我們比較看好的是這種基於容器映象的能力模組，基於上層互動的社群建設.然後還有一個AutoScale模組，AutoScale也是PaaS模組中必不可少的一塊，預設的Rancher沒有這方面的能力，但是我們剛才提到的開放式的框架，我們可以自己設計一個這樣的能力模組，它可以對你的叢集做監控。

其實其他平臺也能做到這個功能，這裡我們只是舉個例子。比如你的CPU、記憶體壓力在變化，然後你的AutoScale能力模組可以監測到壓力變化，同時觸發一個動作，把叢集規模擴容。大家都知道的是，無論哪個平臺擴容之後，同時進行負載均衡，把CPU降下來這已經不是什麼新鮮事。但是這裡缺乏的是AutoScale能力對你業務指標的能力，比如說今天是監控CPU，我改下我的模組就能去監控你的業務指標了。

傳統廠商他們也開始推出基於容器的Load Balancing的能力模組，Citrix已經有了這樣的產品，也許有一天F5也會推出基於容器版本的負載均衡能力，是否說有一天我們在做PaaS平臺的時候，可以為我的使用者提夠一個選擇，是來自於Citrix或是F5的負載均衡模組，這是行業內的一種趨勢。

剛才我們也提到一些更好的場景，比如說高可用資料庫，我們希望部署這麼一個場景，給程式設計師一個商品，我點選一下這個商品就能獲得高可用的資料庫。那麼可能這個商品是類似圖上的MySQL 資料服務，那麼其實這個是今天有容雲應用商店上已有的一個能力，你可以點選一鍵部署，高可用的MySQL就部署出來了。

接下來呢我們來談談容器的日誌和告警，當然由於時間關係，我不再一 一細講。這是我們有容雲之前做日誌研發的時候考量的其他國內外廠商情況。我知道很多人對日誌和告警這一塊也很感興趣也在看，我分享給大家的是大家在選擇的時候有幾個地方可以注意一下。你選擇的解決方案是一個託管模式還是一個部署在企業內部的On-Premise模式，這個是很重要的指標。

我們發現很多國外的好的解決方案比如說Sysdig都是預設採用的託管模式。就是說你把你的Engine 部署在本地，然後把你的資料弄到美國去，你需要註冊一個賬號，登入去看你的資料。他們的系統做得很好，但就是這條我們就把他們否了，因為國內使用者最討厭的就是把自己的資料弄到國外去。國內很多廠商在做託管形式的雲監控，這也許是一個路子，這樣的廠商之後我們也會跟他們進行合作。以上這些系統都各有特點，我們自有版本集成了兩個模組，一個是Splunk，一個是ELK+Zabbix. 接下來大家很關心的容器日誌，它能不能去收集管理呢？能不能像傳統模式一樣，有一個集中式的伺服器，把所有容器相關的日誌都上傳上來？

我的個人理解是至少有幾個方面需要你關心，第一，Docker環境產生的日誌，比如容器啟停這樣的事件等等。第二個方面是容器本身的output，放在標準輸出，Docker要求大家最好把程式都改掉，改成日誌打到標準輸出上。這裡不評判是好是壞，但是我相信我們今天上容器的大部分應用廠商還在採用第三種模式：我把我的日誌寫在應用資料夾下的 App.log的模式。對於這種模式怎麼來傳輸呢，這是一個很現實的問題。如果把你的日誌處理Agent放在你的Docker容器裡面去，就會使你的容器變大，所以我們就自己開發了一個方案，這裡面用到的兩個技術，一個叫夥伴容器技術，一個叫資料卷共享的技術。我相信對於Kubernetes也有一個類似的方案，  無論如何我在侵入你的主容器的情況下提供一個夥伴容器，這個夥伴容器能把分散的日誌上傳到集中式日誌伺服器上去，然後做一個比如分析排障，報表統計等等的工作。

最後我們聊下容器的安全性，相信這也是大家非常關心的一個話題。之前我們談過很多客戶，雖然目前還沒太多客戶談到容器安全的話題，但是我相信未來肯定會有很多使用者去關心，相比較傳統安全產品和方案，我們有容雲相信一個專為容器開發的安全產品是必要的，也符合趨勢。我們也計劃在今年下半年推出相關產品，大家可以關注下有容雲的官方微訊號。     

謝謝大家！

溫馨提示

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