如何減少運維團隊的日常瑣事？如何將服務平臺化，賦予使用者自我服務的能力？新東方雲利用Rancher容器管理平臺、Harbor映象倉庫和GitLab構建企業應用商店。賦能運維團隊和使用者，嘗試破解使用者自服務的難題。
運維團隊一線支援小哥接到某團隊的工單，要求部署一套TiDB做功能測試。小哥在雲平臺上申請機器，按照內部標準的部署檔案安裝配置，最終交付給該團隊。小哥回覆郵件後已經是下午3點多了，小哥的一天就這麼過去了。平淡無奇的運維工作似乎就應該是這樣的。
我相信這是大多數運維團隊都會面臨的問題，運維團隊面臨著很多不斷重覆，事務性的工作。組織規模變大以後，像這樣有的沒的專案都會來運維團隊尋求支援。運維團隊招了很多人，忙了一年下來，發現好像也沒做成什麼事情，功勞似乎都是別人的，成本都是自己的。為什麼會這樣？因為運維團隊的大量時間和精力在服務其他團隊的瑣事中消耗掉了。
這也是我們信管部王威老師提出建設新東方雲的初衷之一。我們設想是否能把手中的資源和我們的服務平臺化？透過定製和開發，最終我們交付出去的不是針對具體專案的勞務，而是一個服務的平臺。讓大部分重覆性的日常部署和維護工作由使用者自己完成。我們將運維能力直接賦予其他團隊和使用者，讓運維團隊能將精力集中在提高SLA和技術提升上。
這也是我今天分享的主題，今天主要分享一下新東方利用容器技術在使用者自服務方面的一些探索。
新東方雲採用自建資料中心+IDC+公有雲的混合雲架構，提供包括：雲伺服器、物件儲存、分散式檔案系統等IaaS層面的服務，提供訊息佇列、快取服務等中介軟體層面服務，以及運維大資料方案和影片服務等等。
容器雲服務是新東方雲提供的最新服務，目前還在beta階段。我們的容器雲平臺也是基於Docker、Harbor等主流技術作為後臺，使用Rancher提供的Cattle作為編排引擎。
提到Rancher大家可能也聽說過，簡單介紹一下Rancher。
Rancher是一個輕量級的容器管理平臺，CNI相容的網路服務、儲存服務、主機管理、負載均衡等功能。Rancher現在分為兩個分支：
1.X：採用Rancher自己開發的Cattle編排引擎，已經有一套完整的平臺和全球眾多的粉絲。
2.X：目前已經進入beta階段， 2.X分支則完全將Rancher建立在Kubernetes之上，提供對公有雲或自建的各種Kubernetes平臺的納管。有興趣的同學請關註： rancher.com。
Rancher Catalog功能類似Kubernetes的Helm，提供對應用的打包定製，並提供一整套使用者UI。使用者只需要簡單輸入即可部署一套應用。這恰好也是我們比較看重的功能。我們嘗試將日常常用的基礎軟體透過容器雲平臺打包，釋出在企業應用商店中，這樣團隊內部在需要的時候只需要簡單的透過介面設定一下就立刻獲得這個服務。
說了這麼多，應用商店是什麼樣的呢？下麵就詳細介紹一下應用商店的原理和實現。繼續開場運維小哥的故事，同樣的工作，他現在只需要開啟應用商店：
大概等待3分鐘左右， 一套完整的TiDB環境就出來了，期間小哥完全不用理會這邊建立的過程，可以做其他事情去了。
這就是應用商店建立應用的流程，從圖片中大家也看到，我們還在不斷的增加企業內部應用。
比如圖片中的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/11/15/harbor-完全定製手冊-製作一個更好用的registry/和http://jiangjiang.space/2017/11/03/harborregistry設定ceph物件儲存/。
原始碼倉庫是用來作為應用商店的載體，應用商店實際上是一個Git的專案。所有的編排檔案以目錄的形式存放在指定的路徑下，這樣Rancher就能讀取為一個一個應用。
使用私有部署的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數目排程到標的主機，並且每個主機只跑一個實體：
也就是說只要這臺機器啟動了這個服務的一個實體就不要再排程另一個上去。
-
io.rancher.sidekicks：容器名，容器名
# 設定從屬容器，比如做個side car容器，你希望第一個容器啟動提供儲存volume，然後啟動第二個容器跑服務，接著第三個容器做日誌的接收轉發等等。
-
io.rancher.container.pull_image：always
# 啟動服務時總是拉取容器映象
詳細的排程和標簽說明請參考：http://rancher.com/docs/rancher/latest/en/cattle/labels/。
rancher-compose除了定義排程外，還提供了questions功能。
questions設定一些問題，使用者在啟動的時候輸入，輸入的結果保留到answer.txt中, 這個設計類似helm的values_file，只不過value檔案不是預先定義的，而是使用者啟動時輸入後產生的。
根據上面的定義，Rancher UI會為不同型別的question配置輸入框，比如 enum是一個下拉串列， int是一個只能輸入整數的輸入框，Rancher會做基本的輸入檢查。
解釋到這裡可能大家就明白了，這就是應用商店的原理：
目前應用商店主要是運維團隊內部使用。下一步我們打算以Rancher作為管理後臺，透過呼叫Rancher的API，對接到新東方雲平臺上。與新東方雲現有的申請和開通流程保持一致，簡化使用者的輸入，最終形成一套使用者能自服務的PaaS平臺。
我最近會將Rancher 1.X的實踐工作做一系列的總結，具體技術細節大家可以關註我的工作日誌http://jiangjiang.space。
Q：為什麼不直接使用Kubernetes提供的編排方式？
A：新東方的IT人員與業務人員比值是比較低的，因此在小團隊下直接搞Kubernetes是個不現實的事情，小團隊，專案時間緊 ，先解決“有”的問題，綜合起來看最後選擇了Rancher，我們的二期專案將基於Kubernetes。
A：用的Rancher 內建的VXLAN，現在部署的環境完全在私有雲部分部署。
A：監控暫時使用的是Rancher社群內建的普羅米修斯，宿主機層面沿用了Zabbix，我們目前Zabbix監控非常完善了。普羅米修斯還在研究中。
Q：請問為什麼不直接用Helm？ 相關的包管理功能更加強大。
A：確實Kubernetes和Helm更強大。 但是對於一個剛剛接觸容器的團隊直接搞Kubernetes的成本還是有些大。我們不可能讓所有人等我們一年半年埋頭搞，因此我們選擇了Rancher，大家都會Docker，都知道docker-compose，稍微學一下就上手了。
Q：請問Rancher在CI/CD方面是如何做的？
A：CI/CD這部分，之前我們自己搞過Jenkins，後來Rancher出了Pipeline工具。Rancher Pipeline也是基於Jenkins，集成了GitLab和GitHub，並配置了UI，使用者體驗還不錯。我們自己的映象打包現在都切換到Pipeline了。Jenkins部分準備直接交給測試部門來搞，我們配合他們，因為他們搞Jenkins更專業。
本次培訓內容包括：容器原理、Docker架構及工作原理、Docker網路與儲存方案、Harbor、Kubernetes架構、元件、核心機制、外掛、核心模組、Kubernetes網路與儲存、監控、日誌、二次開發以及實踐經驗等。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
