1. 程式人生 > >58趕集基於 Docker 的自動化部署實踐_Kubernetes中文社群

58趕集基於 Docker 的自動化部署實踐_Kubernetes中文社群

58趕集運維開發高階工程師史祥陽

  1. 專案背景

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

在這個現狀下,我們提出了『基於 docker 的自動化部署』專案,在不破壞現有專案管理流程的基礎上,實現接管所有環境的部署,提高生產效率。

  1. 自動打包

引入 docker 技術之後,首先給開發人員帶來了編寫 dockerfile 的問題。為了降低使用成本,我們提供了若干標準的 dockerfile 模板,業務線 RD 同學可以根據不同業務場景選擇合適的模板。同時提供標準 dockerfile 也帶了其它好處,類似專案之間通用的 layer 比較多,減少了同類型叢集映象的差異性,在映象儲存,和拉取映象的時候帶來了方便。

一個典型的 dockerfile 模板如下:

執行 docker build 的時候可以加上 –build-arg 引數,給構建環境的 CACHE 變數指定不一樣的值,防止後面的業務程式碼層被打包機快取。

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

  1. 全環境流轉

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

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

為了實現單一映象能在不同的環境下正常生成容器,首先要解決不同環境配置檔案的問題。我們寫了一個切換配置檔案的指令碼,然後把此指令碼和所有環境的配置檔案在打包階段均置入到映象中,然後在不同環境執行時,新增代表當前環境的系統環境變數,這樣在不同環境生成的容器就能啟用對應的配置檔案了。

  1. 測試 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 就能定位到容器了。