58 趕集基於 Docker 的自動化部署實踐

【編者的話】隨着 58 業務的發展，機器和服務數量也日益龐大，在多環境下，服務的管理和依賴難以維護。基於 Docker 帶來的技術紅利，咱們藉助 Docker 和 Kubernetes 提供了鏡像的自動打包，單一鏡像在測試-沙箱-生產-穩定四個環境的流轉，以及測試環境統一的 Nginx 入口。至此，開發同窗能夠再也不爲資源和環境問題困擾，提升了生產效率。

1. 項目背景

58現有的部署系統只管理線上環境，在資源和環境兩個維度，分別存在如下問題：

資源	環境
業務線對服務器等資源利用率低	測試環境混亂
不一樣業務對資源訴求不一致	沒有穩定環境
分配效率低，資源不可控	各服務器線上環境不一致，難以遷移

在這個現狀下，咱們提出了『基於 Docker 的自動化部署』項目，在不破壞現有項目管理流程的基礎上，實現接管全部環境的部署，提升生產效率。

2. 自動打包

引入 docker 技術以後，首先給開發人員帶來了編寫 dockerfile 的問題。爲了下降使用成本，咱們提供了若干標準的 dockerfile 模板，業務線 RD 同窗能夠根據不一樣業務場景選擇合適的模板。同時提供標準 dockerfile 也帶了其它好處，相似項目之間通用的 layer 比較多，減小了同類型集羣鏡像的差別性，在鏡像存儲，和拉取鏡像的時候帶來了方便。

一個典型的 dockerfile 模板以下：

FROM registry.58corp.com/base/centos6.8:14

MAINTAINER 58op

RUN yum install -y tomcat apr tomcat-native EXPOSE 8001
ENTRYPOINT sh /sbin/startup.sh WORKDIR /opt/web/{{CLUSTER_NAME}} ARG CACHE=1
RUN mkdir -p /opt/web/{{CLUSTER_NAME}}/ /opt/log/wormhole/{{CLUSTER_NAME}}/ && rsync -ac {{BUILD_IP}}::root/root/output/ /opt/web/{{CLUSTER_NAME}}/ && chown -R work:work /opt USER work複製代碼

運行 docker build 的時候能夠加上 --build-arg 參數，給構建環境的 CACHE 變量指定不同的值，防止後面的業務代碼層被打包機緩存。

在此基礎上，咱們還實現了自動打包流程，在完成提測以後，觸發自動打包的流程，在 kubernetes 中用跑一個 Job，完成鏡像構建的步驟，同時上傳本次運行日誌，方便定位未知的問題。這樣在部署階段，業務線 RD 只須要選擇集羣名，須要部署的環境和版本號就能部署容器了。

3. 全環境流轉

目前在58趕集內部大多數業務有如下四種環境：

環境	數據源	用途
測試	線下庫	RD 開發自測，QA 線下驗證功能
沙箱	線上庫	接入少許線上流量，預上線驗證功能
線上	線上庫	生產環境
穩定	線下庫	給測試環境下游的服務提供依賴

現有的部署系統『USP』接管了線上環境的部署，能實現自動從產品庫拉取代碼包，完成部署，摘流量，重啓服務等操做。對於剩下三種環境，基本上是各自爲政的狀態，大多由RD、QA 同窗手動搭建，比較混亂。

爲了實現單一鏡像能在不一樣的環境下正常生成容器，首先要解決不一樣環境配置文件的問題。咱們寫了一個切換配置文件的腳本，而後把此腳本和全部環境的配置文件在打包階段均置入到鏡像中，而後在不一樣環境運行時，添加表明當前環境的系統環境變量，這樣在不一樣環境生成的容器就能啓用對應的配置文件了。

4. 測試 NGINX

因爲分類信息業務的特殊性，58趕集的二級域名是城市分站縮寫，不一樣業務須要經過 URL 來區分，因此咱們可能有着業內最複雜的 NGINX 配置。對於不少業務，若是沒有 NGINX 配置，直接 IP:端口 訪問後端服務，是不能正常進行測試的，再加上測試環境須要頻繁變動版本，還有多版本並行測試的狀況，更是增長了測試 NGINX 的配置複雜程度。

測試 NGINX 的實現原理以下圖：

1. 首先借助於騰訊 TGW（可用 LVS 代替），預先申請不少 VIP 放入資源池，並將後端 RS 綁定爲咱們統一提供的 NGINX 機器。
2. 測試 NGINX 是線上 NGINX 的同步實例，配置能夠同步更新。
3. 每次部署完成後，從 VIP 資源池中取出一個可以使用的 VIP，記錄下部署容器和 VIP 的關係；同時更新 NGINX UPSTREAM 配置。
4. VIP 攜帶着集羣、版本等部署信息，由於用戶只面對版本號，那麼容器=版本，版本=測試任務，VIP 也就攜帶了測試任務的信息，那麼經過 VIP 就能定位到容器了。

Q&A

Q：如何更新 nginx upstream？

A：Nginx 機器上部署有 Agent，Web 類的業務有統一的框架，服務啓動時會向 Consul 註冊。Agent 訂閱 Consul 中的節點數據，而後配合 nginx dyups 模塊，動態修改 nginx upstream。

Q：打包好鏡像後，使用鏡像還用再進行配置嗎，就是說還用手動配置嗎？

A：不用配置，不一樣環境之間流轉的是同一個鏡像，包含了各個環境的全部配置，經過啓動容器的環境變量來識別切換。

Q：Docker 的正確的使用姿式，在本地環境已經構建了企業私有 Registry Harbor，那麼我要構建基於業務的應用時，是先從 Linux 系列的像 Ubuntu 或 CentOS 的 Base 的 Docker 鏡像開始，而後經過 Dockerfile 定製業務需求，來使用嗎？

A：咱們基礎鏡像統一採用 CentOS 6.8，不一樣的業務有不一樣的 Dockerfile 模板，生成鏡像的過程業務對 Dockerfile 是透明的。

Q：這裏實現灰度發佈了嗎？可否不停交易更新？

A：實現了 PV 灰度，暫時沒實現 UV 灰度，對於無狀態的業務已經能知足需求了，對於有狀態的業務，好比交易類型的主要仍是須要程序架構來實現。

Q：請問如何保證 NGINX 的高可用？

A：域名->CNAME（快速切換IP解析）->LVS（多個rip）->多個 NGINX 實例（平行實例）；NGINX 同時和 LVS 保持心跳來自動踢掉故障的實例。

原文連接：58 趕集基於 Docker 的自動化部署實踐