新東方利用容器技術在用戶自服務方面的探索

如何減小運維團隊的平常雜事？如何將服務平臺化，賦予用戶自我服務的能力？新東方雲利用Rancher容器管理平臺、Harbor鏡像倉庫和GitLab構建企業應用商店。賦能運維團隊和用戶，嘗試破解用戶自服務的難題。

---

開場先講個小故事：

運維團隊一線支持小哥接到某團隊的工單，要求部署一套TiDB作功能測試。小哥在雲平臺上申請機器，按照內部標準的部署文檔安裝配置，最終交付給該團隊。小哥回覆郵件後已是下午3點多了，小哥的一天就這麼過去了。平淡無奇的運維工做彷佛就應該是這樣的。

我相信這是大多數運維團隊都會面臨的問題，運維團隊面臨着不少不斷重複，事務性的工做。組織規模變大之後，像這樣有的沒的項目都會來運維團隊尋求支持。運維團隊招了不少人，忙了一年下來，發現好像也沒作成什麼事情，功勞彷佛都是別人的，成本都是本身的。爲何會這樣？由於運維團隊的大量時間和精力在服務其餘團隊的雜事中消耗掉了。

這也是咱們信管部王威老師提出建設新東方雲的初衷之一。咱們設想是否能把手中的資源和咱們的服務平臺化？經過定製和開發，最終咱們交付出去的不是針對具體項目的勞務，而是一個服務的平臺。讓大部分重複性的平常部署和維護工做由用戶本身完成。咱們將運維能力直接賦予其餘團隊和用戶，讓運維團隊能將精力集中在提升SLA和技術提高上。
這也是我今天分享的主題，今天主要分享一下新東方利用容器技術在用戶自服務方面的一些探索。

首先簡單介紹一下新東方雲和容器雲服務：

新東方雲採用自建數據中心 IDC 公有云的混合雲架構，提供包括：雲服務器、對象存儲、分佈式文件系統等IaaS層面的服務，提供消息隊列、緩存服務等中間件層面服務，以及運維大數據方案和視頻服務等等。

容器雲服務是新東方雲提供的最新服務，目前還在beta階段。咱們的容器雲平臺也是基於Docker、Harbor等主流技術做爲後臺，使用Rancher提供的Cattle做爲編排引擎。

提到Rancher你們可能也據說過，簡單介紹一下Rancher。

Rancher是一個輕量級的容器管理平臺，CNI兼容的網絡服務、存儲服務、主機管理、負載均衡等功能。Rancher如今分爲兩個分支：

X：採用Rancher本身開發的Cattle編排引擎，已經有一套完整的平臺和全球衆多的粉絲。

X：目前已經進入beta階段， 2.X分支則徹底將Rancher創建在Kubernetes之上，提供對公有云或自建的各類Kubernetes平臺的納管。

咱們選擇Rancher的主要是出於如下考慮：

項目100%開源，可選的商業支持。
提供豐富的API，可供用戶自行定製。
學習成本低，直接沿用了Docker生態，好上手。
內置的應用商店框架（Rancher Catalog）。

Rancher Catalog功能相似Kubernetes的Helm，提供對應用的打包定製，並提供一整套用戶UI。用戶只須要簡單輸入便可部署一套應用。這剛好也是咱們比較看重的功能。咱們嘗試將平常經常使用的基礎軟件經過容器雲平臺打包，發佈在企業應用商店中，這樣團隊內部在須要的時候只須要簡單的經過界面設置一下就馬上得到這個服務。

說了這麼多，應用商店是什麼樣的呢？下面就詳細介紹一下應用商店的原理和實現。繼續開場運維小哥的故事，一樣的工做，他如今只須要打開應用商店：

填寫一下表單：

大概等待3分鐘左右， 一套完整的TiDB環境就出來了，期間小哥徹底不用理會這邊建立的過程，能夠作其餘事情去了。

建立好後根據暴露出來的端口和IP，直接鏈接便可。

這就是應用商店建立應用的流程，從圖片中你們也看到，咱們還在不斷的增長企業內部應用。

好比圖片中的SQL Server 2017 on Docker，定製這樣一個應用的時間不會超過半天，複雜一些的應用兩三天也能寫完。

那麼下面就簡單說說應用商店的實現原理：

應用商店的組件

鏡像倉庫

咱們選擇的是業界廣爲使用的Harbor項目，我相信你們也很瞭解了。

簡單介紹一下：Harbor是VMware中國團隊開源的一套基於Docker Registry構建的鏡像倉庫項目。這個項目集成了CoreOS的Clair脆弱性檢查工具和Notary鏡像簽名工具，配以LDAP集成，UI等企業應用必須的功能。能夠說是目前企業鏡像倉庫的首選項目， 此項目爲開源項目。用戶能夠下載下來自行定製。

咱們對Harbor進行了簡單的定製，咱們的Harbor直接對接Ceph對象存儲（經過Swift接口）。 這樣後端存儲在性能和可靠性上都有保障。同時前端也能夠根據須要進行擴容，實際上Harbor中除了MySQL和Pg數據庫外，其餘服務都是無狀態的，徹底能夠作到自動擴縮容，目前Harbor有基於Kubernetes和Rancher（社區Catalog中）的實現，你們能夠參考。

咱們目前的實踐是經過docker-compose方式離線安裝的獨立部署的，後期會考慮以獨立的environment方式歸入Rancher的管理中，後面有進一步的實踐成果後再和你們分享。這裏就不展開說了，有興趣的朋友能夠看一下個人工做筆記：http://jiangjiang.space/2017/...://jiangjiang.space/2017/11/03/harborregistry設置ceph對象存儲/。

源碼倉庫

源碼倉庫是用來做爲應用商店的載體，應用商店其實是一個Git的項目。全部的編排文件以目錄的形式存放在指定的路徑下，這樣Rancher就能讀取爲一個一個應用。

如圖：

GitLab中的目錄結構：

Templates下面是各個應用。

使用私有部署的GitLab或者直接使用GitHub也能夠。

終於說到重點了，應用商店

以前提到過Rancher的Catalog和Kubernetes的Helm很類似，好比Helm各類Charts，Values和Templates等定義，幫助用戶固化對應用的定製。Rancher的Catalog也是這個設計思路，Helm圍繞Kubernetes，Rancher則是圍繞Cattle而生。

下面以Catalog中的一個應用來解釋一下。這是剛剛TiDB應用的目錄結構：

0目錄和1目錄是版本目錄，Rancher能夠幫助維護應用的版本，能夠幫你把老版本的應用實例升級到新版本，升級動做也是經過應用商店手工完成的。

進入0目錄能夠看到文件，這就是Rancher的服務定義文件了。

看到熟悉的docker-compose.yml和陌生的rancher-compose.yml，這兩個文件的關係要從Cattle提及。

Rancher的Cattle編排引擎設計的很巧妙。 Cattle直接用docker-compose定義服務和服務的關係，好比一個服務使用哪些鏡像，暴露哪些端口，存儲卷定義等等。咱們知道docker-compose實際上是一個單機容器編排工具，直接做爲集羣編排文件的話還缺乏不少重要元素：

缺乏對服務的replica（副本）定義。
缺乏容器之間的隸屬關係（模擬Kubernetes的Pod），經過deponds_on能控制service的前後啓動，可是一個service中的多個容器之間的關係就沒有了。
缺乏對服務的編排控制，好比一個服務起來後調度到哪一個主機上。
缺乏對容器的生命週期控制，好比只在服務啓動時某容器執行一次，重啓服務也再也不啓動等。

docker-compose缺乏的定義則由rancher-compose.yml來補充。實際在執行時Cattle只是根據編排規則，將docker-compose文件中容器的定義部分直接丟給對應主機的Docker執行建立容器。利用Docker容器的label功能作標記，容器起來後Cattle從label中獲取容器的現狀，再與編排規則作對比看看是否知足要求， 好比：Scale，多了就幹掉，少了就拉起。有了這兩個文件的定義Cattle就能夠在各個主機間調度和建立容器了，舉幾個調度的例子：

a：若是要調度一個容器到某個主機上，只須要在容器上打上以下標籤：

Cattle就會將容器的定義發送到有cn.xdf.edge=true標籤的主機上，隨後啓動容器。

b：更復雜一點的調度實現，好比在每一個主機上只啓動某服務的一個容器（單例），或者說相似Kubernetes daemonset，這個在Rancher裏是怎麼實現呢？

這個標籤會把容器在每臺主機上啓動，並只啓動一個。

若是我不想佔用全部主機，只是按照Scale數目調度到目標主機，而且每一個主機只跑一個實例：

這個意思是說：

啓動時的主機上必須沒有符合冒號後面表達式的容器，而且是一個軟限制，去掉soft則是嚴格限制。
服務名字是這個服務的實例名和服務名。

也就是說只要這臺機器啓動了這個服務的一個實例就不要再調度另外一個上去。

還有其餘一些標籤：

io.rancher.sidekicks：容器名，容器名
設置從屬容器，好比作個side car容器，你但願第一個容器啓動提供存儲volume，而後啓動第二個容器跑服務，接着第三個容器作日誌的接收轉發等等。
io.rancher.container.pull_image：always

啓動服務時老是拉取容器鏡像

詳細的調度和標籤說明請參考：http://rancher.com/docs/ranch...。

rancher-compose除了定義調度外，還提供了questions功能。

questions設置一些問題，用戶在啓動的時候輸入，輸入的結果保留到answer.txt中, 這個設計相似helm的values_file，只不過value文件不是預先定義的，而是用戶啓動時輸入後產生的。

根據上面的定義，Rancher UI會爲不一樣類型的question配置輸入框，好比 enum是一個下拉列表， int是一個只能輸入整數的輸入框，Rancher會作基本的輸入檢查。

上圖的代碼會被自動轉化爲下圖中的UI。

解釋到這裏可能你們就明白了，這就是應用商店的原理：

一套服務和容器的定義（docker-compose）
一套編排的設置（rancher-compose）
一套用戶能夠輸入值的UI
用戶在UI中填入值

隨後由編排引擎交給主機上的Docker執行。

應用商店使用狀況：

目前應用商店主要是運維團隊內部使用。下一步咱們打算以Rancher做爲管理後臺，經過調用Rancher的API，對接到新東方雲平臺上。與新東方雲現有的申請和開通流程保持一致，簡化用戶的輸入，最終造成一套用戶能自服務的PaaS平臺。

我最近會將Rancher 1.X的實踐工做作一系列的總結，具體技術細節你們能夠關注個人工做日誌http://jiangjiang.space。

推薦閱讀

推薦閱讀

原創乾貨│利用Rancher構建容器服務

原創乾貨│生產環境部署容器的五大挑戰及應對之策

CaaS「容器即服務」：是營銷手段仍是有其價值？

鋼鐵電商平臺的Docker容器雲平臺建設實踐微信號：RancherLabs