【編者的話】隨著 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 的實現原理如下圖：
- 首先借助於騰訊 TGW（可用 LVS 代替），預先申請很多 VIP 放入資源池，並將後端 RS 繫結為我們統一提供的 NGINX 機器。
- 測試 NGINX 是線上 NGINX 的同步例項，配置可以同步更新。
- 每次部署完成後，從 VIP 資源池中取出一個可使用的 VIP，記錄下部署容器和 VIP 的關係；同時更新 NGINX UPSTREAM 配置。
- 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 保持心跳來自動踢掉故障的例項。