Docker 在 Bilibili 的實戰：由痛點推進的容器化

數人云上海&深圳兩地「容器之 Mesos/K8S/Swarm 三國演義」的嘉賓精彩實錄持續更新^_^今天小數帶來的是 Bilibili 運維開發工程師吳佳興的分享。相信很多小夥伴都是 B 站的粉絲，快來看看他們在業務高峯是如何利用容器技術應對各類壓力的吧。

吳佳興， Bilibili 運維開發工程師
同時也是 Dockone.io 社區譯者，在配置管理、運維自動化、 Python 開發、 CICD 及容器方面有必定經驗。

今天主要講 B 站在 Docker 的一些收穫和實踐經驗。我叫吳佳興，現任 Bilibili 運維開發工程師，同時也是 dockone.io 社區翻譯，過去作過 Salt 配置管理、基礎運維，目前工做重點是容器方面的一些建設。 Bilibili 是一家彈幕視頻網站，深耕於垂直領域，流量可觀，有一億的活躍用戶， 100 萬的活躍 UP 主，主要作直播、遊戲、視頻等。

上圖是本次演講的綱要， B 站定位是一家創業型的公司，並非爲了容器化而容器化，使用容器技術是爲了解決問題。 B 站在 2015 年曾作過容器的嘗試，把 SLB 的節點容器化，當時用的版本是 1.9 ，去年 8 月份重點評估了可否解決線上或者測試環境遇到的問題。

Problems ：不少……

主要存在以下列出的問題。首先應用部署不夠標準化，有不少歷史存留的問題，有些應用是 supervisord 跑起來的，有些應用沒有服務腳本，並且物理機上的混布很是嚴重，好比直播彈幕的一些消息組件在業務高峯的時候把物理機打爆，其餘的應用可能會誤傷掉。 B 站也分 BU ，各個業務方有調用的關係，這個調用的關係在測試環境沒有一個穩定的集成環境來作集成測試，也是須要解決的。

B 站常常遇到測試環境炸了的狀況，這是運維一直比較頭疼的問題，也是推進容器的一個出發點，即用故障或者是痛點來推進，這樣的推進進程會更快一點，解決方案天然就是容器化。

解決方案： Jenkins married Mesos ！

如何產出鏡像，是首先要解決的問題。有兩種方案，一種是運維幫忙作好鏡像，能夠直接用，可是代碼沒有辦法打包進去， B 站選擇的方案是用 Jenkins 加上 Mesos 來作動態可擴縮的 CI 基礎設施，實際用到的組件核心是 Mesos plugin ， Jenkins-Master 能夠經過 Mesos plugin 在 Mesos Master 起一個 Jenkins framework ， framework 是一個調度層，能夠在 Mesos Slave 上進行調度和決策，用 Mesos Plugin 組件至關於在 Slave 上動態地起 Jenkins Slave 進行構建，主要的構建就是從 Gitlab push 觸發第一次構建。構建用到了 Jenkins2.0 的 Pipeline ，就是 Pipeline as Code ，全部均可以用 groovy 腳本實現。咱們會爲每一種語言都定製一種 Pipeline 模版。

這是實際運行狀況的截圖，指定 Jenkins Slave 在 Mesos 上面起起來，而且定義環境變量，一些用來作構建的變量，調用 Pipeline 實現鏡像的產出，經過它能夠直接構建鏡像。另外， Jenkins2.0 也有很是多值得吸引人的特性，由於 Jenkins 在 1.0 的時候是主打是 CI 部分， 2.0 重點在 CD 部分有耕耘，主要是併發測試包括與 Docker 的結合。 Jenkins Pipeline 會分爲幾個步驟，從構建、打包、 Docker build 以及最終在 Marathon 運行起來。

B 站測試環境一直面臨一個問題。舉例來講，一個依賴服務有一個 V1 的穩定版本，假如這個依賴服務須要進行迭代，發佈 V2 版本，但在集成環境發佈 V2 版本，其餘的依賴方調用可能會有問題。 B 站的作法與業界沒有大差別，即作一些環境的區分。若是使用容器化基礎設施，環境的區分會很是的弱化，能夠簡單理解爲在 Slave 上有一個環境的屬性， attribute 就是 Env 等於 UAT 或者 FAT 。 B 站作到了一個效果，在跑完單元測試後，根據用戶的需求，去部署到 FAT 環境或者是 UAT 環境，爲每個跑起來的 API 對應地綁上一個 DNS 的域名，好比功能測試環境想訪問集成環境的服務，能夠經過 Add-host 的方式進行訪問。此外，從集成環境到生產環境是有一個 tag image 的過程，在集成環境產出的鏡像，通過測試經過的步驟，通過 retag 的方式，最後產出一個正式環境能夠用的鏡像。

容器化基礎運行設施

爲了支撐這套構建以及實際容器的運行，須要建設容器化的基礎運行設施，在 CI 方面最終的產出物是一個鏡像，如何支撐它的運行？首先是服務發現。由於 Docker 容器是飄動的，要作到在 LB 上可發現。 B 站使用的 Consul ，即 Marathon 的 app 在啓動的時候會有 instance 出來，咱們會監聽 Marathon 的 eventbus ，並把這個事件記錄到 Consul 裏面，同時對應的會有一個 APP-LB ，在上面綁定一個 consul template 作動態渲染，實現服務的註冊和服務發現。

容器監控，以前也有調研過 Cadvisor 、普羅米修斯之類。由於一些痛點， B 站最終選擇的方案是自研，主要是收集基礎層面的還有應用層面的監控數據，應用層面能夠複用現有的部分，好比代碼埋點或者按期採集的數據，這裏提供一個自研的 monitor agent ，能夠經過 Docker exec 的方式去採集容器的監控數據，而後打到 influxdb 並用 grafana 作展現。

網絡也是作容器的時候一個使人苦惱的問題， B 站以前花了不少時間在網絡選型方面作調研，最終選擇的方案是 Macvlan 。調研過 VXLAN 、 Calico ，最終選擇 Macvlan 的緣由是由於 VXLAN 作過壓力測試，發現私有云方面覆蓋網絡的損耗比較大。若是使用 Calico 的話要作一個 BGP 網絡，當時網絡工程師否決了這個建議，最終選擇了 Macvlan 這個損耗和侵入性比較小的方式。咱們自研了一個 ipam plugin ，由於 Docker12 開始就支持 network plugin ，能夠經過 ipam plugin 來實現 IP 地址的管理，而且註冊到 consul 。

Logging 方面比較簡單。 Docker 提供 log driver ，經過 syslog 的方式打到遠端。另外 APP 應用層面的一些日誌，直接與原有的 VM 同樣，用 UDP 或者是 TCP 打到 Flume 。

Registry 沒有使用 Harbor ，目前是 LVS 後面掛了兩臺 Docker Registry ， registry 是 V2 版本。也遇到一些痛點，好比鏡像， Docker Registry V2 版本以前許諾使能夠實現鏡像徹底刪除的，但 Docker 官方也說暫時尚未實現這一點，若是要徹底刪除一個鏡像，還須要經過 GC 的手段，目前在考慮 Habor ，由於 Harbor 能夠實現很關鍵的一點就是鏡像權限的區分。

B 站開發了一套 BiliPaaS 管理工具，作用戶的入口或者是鏡像發佈的需求，包括鏡像的管理，並開發了一個 Web Console 直接登陸到容器進行操做，包括監控、告警、配置等。 Jenkins 發佈出來的鏡像，打到集成環境以後，經過 retag ， retag 成 v5.1.3 ，在生產環境作一個灰度發佈的界面。容器 Console 能夠在 Web 上進行編輯。

Autoscale ，即彈性擴縮，目前決策的依據監控數據是基礎的監控數據，也作過一些嘗試，發現不太理想，由於 CPU 跟 memory 飆升極可能是異常狀況形成的，並非業務的上升致使的，後期會考慮加入 QPS ， SLB 或者 CDN 層面的監控數據業務層面來作這個 Autoscale 決策。

在容器的基礎設施建設過程當中， B 站遇到了不少問題。咱們使用的是 1.12 ，在 3.16 的使用過程當中發現內核 CFS 支持的時候會有一個 crash 的狀況，只能升到 4.4.27 ，可是 4.4.27 已經把 AUFS 默認的內置給取消掉了，因而只能被迫升到了 overlayfs2 ， overlayfs2 也遇到了問題， XFS 與 overlayfs2 搭配起來後，好比鏡像，會出現鏡像文件的損壞，還有 Docker registry 刪除的問題，以及 Docker 自身的問題、 Mesos 的問題，剛纔提到的 Jenkins 拉起過程當中也遇到一些坑，它會忽然拉不起來了，變得不可控，由於是 Mesos Plugin 直接經過 Jenkins Framework 調用的。

後期展望

B 站會經過 QPS 的業務層指標實現彈性擴縮，另外想引入 Harbor 作開發環境的即開即用，這方面開發已經提過需求，好比但願消費鏡像，在開發環境作開發。 B 站目前實現的是 web 服務和無狀態服務容器化，如大數據無狀態服務的容器化，一些 TCP 應用包括 Cache 、 MQ 尚未實現容器化。 B 站會有短暫性的業務高峯或者是波動性的數次高峯，須要進行彈性擴縮，這方面也在調研，作混合雲方面的基礎建設。

分享就到這裏，謝謝你們。