為什么微服務容器化的運維又成了新問題？

在大部分業務團隊中，進行容器化之前，服務通常部署于物理機或者虛擬機上，而運維一般會有一套既定的運維平臺來發布服務。以微博的運維平臺 JPool 為例，當有服務要發布時，JPool 會依據服務所屬的集群（通常一個業務線對應一個集群）以及運行在哪個服務池（一般一個業務線有多個服務池），確定對應的物理機或者虛擬機 IP，接著通過 Puppet 等工具將最新的應用程序代碼分批逐次地發布到這些物理機或者虛擬機上，隨后重新啟動服務，如此便完成了一個服務的發布流程。

然而，現在情況發生了變化。業務容器化后，運維所面對的不再是一臺臺實實在在的物理機或者虛擬機，而是一個個 Docker 容器，它們可能沒有固定的 IP。在這種情況下，要進行服務發布該如何操作呢？此時就需要一個面向容器的新型運維平臺，它能夠在現有的物理機或者虛擬機上創建容器，并且可以像運維物理機或者虛擬機一樣，對容器的生命周期進行管理，通常我們將其稱為 “容器運維平臺”。

根據我的經驗，一個容器運維平臺通常包含以下幾個組成部分：鏡像倉庫、資源調度、容器調度和服務編排。

鏡像倉庫

Docker 容器的運行依賴于 Docker 鏡像，所以要發布服務，首先得把鏡像發布到各個機器上。此時就產生了問題，這個鏡像該放在哪里呢？又如何將鏡像發布到各個機器上去呢？在這種情況下，就得依靠鏡像倉庫了。鏡像倉庫的概念與 Git 代碼倉庫類似，即有一個集中存儲的地方，將鏡像存儲于此。在服務發布時，各個服務器都訪問這個集中存儲來拉取鏡像，然后啟動容器。Docker 官方提供了一個鏡像倉庫地址：https://hub.docker.com/，對于測試應用或者小規模的業務可以直接使用。但對于大部分業務團隊而言，出于安全和訪問速度的考慮，都會搭建一套私有的鏡像倉庫。

那么，具體該如何搭建一套私有的鏡像倉庫呢？下面我就結合微博的實踐，和你聊聊這里面的門道。

權限控制

鏡像倉庫首先面臨的是權限控制問題，即確定哪些用戶可以拉取鏡像，哪些用戶可以修改鏡像。

一般來說，鏡像倉庫設有兩層權限控制。其一，必須登錄才可以訪問，這是最外層的控制，規定了哪些人能夠訪問鏡像倉庫。其二，對鏡像按照項目的方式進行劃分，每個項目擁有自己的鏡像倉庫目錄，并為每個項目設置項目管理員、開發者以及客人三個角色。只有項目管理員和開發者擁有自己鏡像倉庫目錄下鏡像的修改權限，客人只擁有訪問權限，且項目管理員可以設置哪些人是開發者。

個權限控制與大廈辦公樓的管理類似。要進入大廈里的一個辦公室，首先必須具備進入大廈的權限，這是在大廈里所有辦公的人都有的。然后還得具備大廈里辦公室所在樓層的門禁，才能進入辦公室。不同樓層的人權限不同，只能進入自己樓層的辦公室。如果某個辦公室有新來的員工，首先要給他分配大廈的進入權限，然后由這個辦公室的管理員給他分配辦公室的權限。這樣講解權限控制，是不是更好理解一些呢？

鏡像同步

在實際的生產環境中，常常需要把鏡像同時發布到幾十臺甚至上百臺集群節點上。單個鏡像倉庫實例往往由于帶寬原因限制，無法同時滿足大量節點的下載需求。此時，就需要配置多個鏡像倉庫實例來進行負載均衡，同時也會產生鏡像在多個鏡像倉庫實例之間同步的問題。顯然，通過手工維護十分繁瑣，那有什么好的辦法呢？一般來說，有兩種方案。一種是一主多從、主從復制的方案，比如開源鏡像倉庫 Harbor 就采用了這種方案。另一種是 P2P 的方案，比如阿里的容器鏡像分發系統蜻蜓采用了 P2P 方案。微博的鏡像倉庫是基于 Harbor 搭建的，所以這里我就以 Harbor 為例，介紹鏡像同步機制。Harbor 所采取的主從復制的方案是，將鏡像傳到一個主鏡像倉庫實例上，然后其他從鏡像倉庫實例都從主鏡像倉庫實例同步。它的實現就像下圖所描述的一樣。

圖片

除此之外，Harbor 還支持層次型的發布方式，如果集群部署在多個 IDC，可以先從一個主 IDC 的鏡像倉庫同步到其他從 IDC 的鏡像倉庫，再從各個從 IDC 同步給下面的分 IDC，它的實現就像下圖所描述的一樣。

圖片

高可用性

既然 Docker 鏡像是 Docker 容器運行的基礎，那么鏡像倉庫的高可用性便不言而喻。一般來說，高可用性設計無非是將服務部署在多個 IDC，這樣即便有 IDC 出現問題，也可以把服務遷移到其他正常的 IDC 中。同樣，對于鏡像倉庫的搭建，也可以采用多 IDC 部署，此時需要做到不同 IDC 之間的鏡像同步。以微博的鏡像倉庫為例，就如下圖所示，鏡像倉庫會部署在永豐、土城兩個內網 IDC 內。兩個 IDC 內的鏡像同步采用 Harbor 的雙主復制策略，互相復制鏡像。這樣一來，即使有一個 IDC 出現問題，另外一個 IDC 仍然能夠提供服務，并且不會丟失數據。

圖片

資源調度

解決了 Docker 鏡像存儲和訪問的問題后，新問題又隨之而來了，Docker 鏡像要分發到哪些機器上去？這些機器是從哪里來的？這其實涉及的是資源調度的問題。

物理機集群

• 大部分中小團隊通常擁有自己的物理機集群，且大多按照集群 - 服務池 - 服務器的模式進行運維。
• 物理機集群面臨的問題主要是服務器配置不統一。尤其對于計算節點而言，普遍存在這樣一種情況：幾年前采購的機器配置可能是 12 核 16G 內存，而近些年采購的機器至少是 32 核 32G 內存的配置。對于這兩種機器往往需要區別對待，比如舊機器用于跑一些非核心、占用資源量不大的業務，新采購的機器則用于跑一些核心且服務調用量高的業務。

虛擬機集群

• 不少業務團隊在使用物理機集群后，發現物理機集群存在使用率不高、業務遷移不靈活的問題，于是紛紛轉向虛擬化方向，構建自己的私有云。比如以 OpenStack 技術為主的私有云集群在國內外不少業務團隊中都有大規模的應用。
• 它的最大好處就是可以整合企業內部的服務器資源，通過虛擬化技術進行按需分配，提高集群的資源使用率，節省成本。

公有云集群

• 現在越來越多的業務團隊，尤其是初創公司，由于公有云快速靈活的特性，紛紛在公有云上搭建自己的業務。
• 公有云最大的好處除了快速靈活、分鐘級即可實現上百臺機器的創建，還有一個好處就是配置統一、便于管理，不存在機器配置碎片化問題

為了解決資源調度的問題，Docker 官方提供了 Docker Machine 功能。通過 Docker Machine，可以在企業內部的物理機集群、虛擬機集群（如 OpenStack 集群）或者公有云集群（如 AWS 集群）等上面創建機器并且直接部署容器。

雖然 Docker Machine 的功能很不錯，但是對于大部分已經發展了一段時間的業務團隊來說，并不能直接拿來使用。這主要是因為資源調度最大的難點并不在于機器的創建和容器的部署，而在于如何對接各個不同的集群，統一管理來自不同集群的機器權限管理、成本核算以及環境初始化等操作。在這種情況下，就需要有一個統一的層來完成這個操作。對于有歷史包袱的團隊，比如公司內網的物理機集群已經有一套運維體系的團隊來說，這是一個不小的挑戰，需要針對新的模式重新開發這套運維平臺。

以微博的業務為例，為了滿足內部三種不同集群資源的統一管理，專門研發了容器運維平臺 DCP，來實現對接多個不同的集群。它的難點在于不僅對外要對接不同的云廠商，針對不同云廠商提供的 ECS 創建的 API，統一封裝一層 API 來實現機器管理；對內也要針對私有云上不同集群的機器進行管理，進行上下線和配置初始化等操作。以 DCP 配置初始化操作為例，在創建完主機后，還需要在主機上進行安裝 NTP 服務、修改 sysctl 配置、安裝 Docker 軟件等操作。這時候就需要借助配置管理軟件來向主機上進行分發。因為微博內網的主機之前都是通過 Puppet 進行分發的，考慮到穩定性并沒有對這一部分進行修改；而針對阿里云上創建的主機，則使用的是編程功能更為強大的 Ansible 進行分發