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

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

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

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

鏡像倉庫

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

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

權(quán)限控制

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

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

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

鏡像同步

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

圖片

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

圖片

高可用性

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

圖片

資源調(diào)度

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

物理機集群

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

虛擬機集群

• 不少業(yè)務(wù)團隊在使用物理機集群后，發(fā)現(xiàn)物理機集群存在使用率不高、業(yè)務(wù)遷移不靈活的問題，于是紛紛轉(zhuǎn)向虛擬化方向，構(gòu)建自己的私有云。比如以 OpenStack 技術(shù)為主的私有云集群在國內(nèi)外不少業(yè)務(wù)團隊中都有大規(guī)模的應(yīng)用。
• 它的最大好處就是可以整合企業(yè)內(nèi)部的服務(wù)器資源，通過虛擬化技術(shù)進行按需分配，提高集群的資源使用率，節(jié)省成本。

公有云集群

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

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

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

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