58趕集基於 Docker 的自動化部署實踐_Kubernetes中文社群
58趕集運維開發高階工程師史祥陽
- 專案背景
58現有的部署系統只管理線上環境，在資源和環境兩個維度，分別存在以下問題：
在這個現狀下，我們提出了『基於 docker 的自動化部署』專案，在不破壞現有專案管理流程的基礎上，實現接管所有環境的部署，提高生產效率。
- 自動打包
引入 docker 技術之後，首先給開發人員帶來了編寫 dockerfile 的問題。為了降低使用成本，我們提供了若干標準的 dockerfile 模板，業務線 RD 同學可以根據不同業務場景選擇合適的模板。同時提供標準 dockerfile 也帶了其它好處，類似專案之間通用的 layer 比較多，減少了同類型叢集映象的差異性，在映象儲存，和拉取映象的時候帶來了方便。
一個典型的 dockerfile 模板如下：
執行 docker build 的時候可以加上 –build-arg 引數，給構建環境的 CACHE 變數指定不一樣的值，防止後面的業務程式碼層被打包機快取。
在此基礎上，我們還實現了自動打包流程，在完成提測之後，觸發自動打包的流程，在 kubernetes 中用跑一個 Job，完成映象構建的步驟，同時上傳本次執行日誌，方便定位未知的問題。這樣在部署階段，業務線 RD 只需要選擇叢集名，需要部署的環境和版本號就能部署容器了。
- 全環境流轉
目前在58趕集內部大多數業務有以下四種環境：
現有的部署系統『USP』接管了線上環境的部署，能實現自動從產品庫拉取程式碼包，完成部署，摘流量，重啟服務等操作。對於剩下三種環境，基本上是各自為政的狀態，大多由RD、QA 同學手動搭建，比較混亂。
為了實現單一映象能在不同的環境下正常生成容器，首先要解決不同環境配置檔案的問題。我們寫了一個切換配置檔案的指令碼，然後把此指令碼和所有環境的配置檔案在打包階段均置入到映象中，然後在不同環境執行時，新增代表當前環境的系統環境變數，這樣在不同環境生成的容器就能啟用對應的配置檔案了。
- 測試 NGINX
由於分類資訊業務的特殊性，58趕集的二級域名是城市分站縮寫，不同業務需要通過 URL 來區分，所以我們可能有著業內最複雜的 NGINX 配置。對於很多業務，如果沒有 NGINX 配置，直接 IP:埠 訪問後端服務，是不能正常進行測試的，再加上測試環境需要頻繁變更版本，還有多版本並行測試的情況，更是增加了測試 NGINX 的配置複雜程度。
測試 NGINX 的實現原理如下圖：
- 首先借助於騰訊 TGW（可用 LVS 代替），預先申請很多 VIP 放入資源池，並將後端 RS 繫結為我們統一提供的 NGINX 機器。
- 測試 NGINX 是線上 NGINX 的同步例項，配置可以同步更新。
- 每次部署完成後，從 VIP 資源池中取出一個可使用的 VIP，記錄下部署容器和 VIP 的關係；同時更新 NGINX UPSTREAM 配置。
- VIP 攜帶著叢集、版本等部署資訊，因為使用者只面對版本號，那麼容器=版本，版本=測試任務，VIP 也就攜帶了測試任務的資訊，那麼通過 VIP 就能定位到容器了。