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 的實現原理如下圖：
測試 nginx 是線上 nginx 的同步例項，配置可以同步更新。
每次部署完成後，從 vip 資源池中取出乙個可使用的 vip，記錄下部署容器和 vip 的關係；同時更新 nginx upstream 配置。
vip 攜帶著集群、版本等部署資訊，因為使用者只面對版本號，那麼容器=版本，版本=測試任務，vip 也就攜帶了測試任務的資訊，那麼通過 vip 就能定位到容器了。
原文：58趕集基於 docker 的自動化部署實踐
k8s中文文件推薦
58 趕集基於 Docker 的自動化部署實踐
編者的話 隨著 58 業務的發展，機器和服務數量也日益龐大，在多環境下，服務的管理和依賴難以維護。基於 docker 帶來的技術紅利，我們借助 docker 和 kubernetes 提供了映象的自動打包，單一映象在測試 沙箱 生產 穩定四個環境的流轉，以及測試環境統一的 nginx 入口。至此，開...
基於docker搭建jmeter自動化壓力測試平台
1.背景 2.目標 3.總體設計 3.1系統總體邏輯結構 系統總體邏輯結構說明 系統採用jenkins 作為與使用者互動的前端工具，使用ansible作為各種檔案到各個負載節點的分發工具，底層通訊使用ssh，使用jmeter作為執行壓測工具。3.2系統部署結構 系統分為兩種節點型別，一種是控制節點，...
基於docker的環境搭建
docker 是乙個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到乙個可移植的容器中，然後發布到任何流行的 linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何介面。docker這種技術跟平常用的虛擬機器很相似，但相比之下更加輕量。在工程化部署專案的時候非常好...