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

2021-09-11 09:06:03 字數 3112 閱讀 7233

【編者的話】隨著 58 業務的發展,機器和服務數量也日益龐大,在多環境下,服務的管理和依賴難以維護。基於 docker 帶來的技術紅利,我們借助 docker 和 kubernetes 提供了映象的自動打包,單一映象在測試-沙箱-生產-穩定四個環境的流轉,以及測試環境統一的 nginx 入口。至此,開發同學可以不再為資源和環境問題困擾,提高了生產效率。

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

資源環境

業務線對伺服器等資源利用率低

測試環境混亂

不同業務對資源訴求不一致

沒有穩定環境

分配效率低,資源不可控

各伺服器線上環境不一致,難以遷移

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

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

乙個典型的 dockerfile 模板如下:

user work複製**執行docker build的時候可以加上--build-arg引數,給構建環境的cache變數指定不一樣的值,防止後面的業務**層被打包機快取。

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

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

環境資料來源

用途測試

線下庫rd 開發自測,qa 線下驗證功能

沙箱線上庫

接入少量線上流量,預上線驗證功能

線上線上庫

生產環境

穩定線下庫

給測試環境下游的服務提供依賴

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

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

由於分類資訊業務的特殊性,58趕集的二級網域名稱是城市分站縮寫,不同業務需要通過 url 來區分,所以我們可能有著業內最複雜的 nginx 配置。對於很多業務,如果沒有 nginx 配置,直接 ip:埠 訪問後端服務,是不能正常進行測試的,再加上測試環境需要頻繁變更版本,還有多版本並行測試的情況,更是增加了測試 nginx 的配置複雜程度。

測試 nginx 的實現原理如下圖:

測試 nginx 是線上 nginx 的同步例項,配置可以同步更新。

每次部署完成後,從 vip 資源池中取出乙個可使用的 vip,記錄下部署容器和 vip 的關係;同時更新 nginx upstream 配置。

vip 攜帶著集群、版本等部署資訊,因為使用者只面對版本號,那麼容器=版本,版本=測試任務,vip 也就攜帶了測試任務的資訊,那麼通過 vip 就能定位到容器了。

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 的自動化部署實踐

58趕集運維開發高階工程師史祥陽 專案背景 58現有的部署系統只管理線上環境,在資源和環境兩個維度,分別存在以下問題 在這個現狀下,我們提出了 基於 docker 的自動化部署 專案,在不破壞現有專案管理流程的基礎上,實現接管所有環境的部署,提高生產效率。自動打包 引入 docker 技術之後,首先...

基於docker搭建jmeter自動化壓力測試平台

1.背景 2.目標 3.總體設計 3.1系統總體邏輯結構 系統總體邏輯結構說明 系統採用jenkins 作為與使用者互動的前端工具,使用ansible作為各種檔案到各個負載節點的分發工具,底層通訊使用ssh,使用jmeter作為執行壓測工具。3.2系統部署結構 系統分為兩種節點型別,一種是控制節點,...

基於docker的環境搭建

docker 是乙個開源的應用容器引擎,讓開發者可以打包他們的應用以及依賴包到乙個可移植的容器中,然後發布到任何流行的 linux 機器上,也可以實現虛擬化。容器是完全使用沙箱機制,相互之間不會有任何介面。docker這種技術跟平常用的虛擬機器很相似,但相比之下更加輕量。在工程化部署專案的時候非常好...