洋碼頭自動化發布系統介紹
作者介紹
谷自強，洋碼頭高級運維開發工程師
負責洋碼頭的發布系統、CMDB、監控告警系統的開發和維護
本文約2400字，可參閱下面的大綱閱讀。
項目需求
設計思路
技術選型
系統架構
功能特點
總結
項目需求
結合洋碼頭的業務特點和現狀，我們的自動化發布系統需要滿足以下需求：
支持各種語言代碼發布(IIS、Java、Nodejs、Python、Windows Service)等
同時支持Windows和Linux系統
支持單台發布、一鍵發布、灰度發布、擴容發布、回滾發布等多種發布要求
支持多機房和雲端部署
流程可定製且便於修改
支持RBAC許可權管理
支持發布版本歷史記錄回溯
設計思路
整體採用微服務架構的思想，避免高度耦合，也便於以後擴展
每個應用只需要維護自身的業務邏輯
每個應用提供標準的、符合RESTful規範的API介面
統一使用JSON數據格式進行傳輸
盡量選用能夠跨平台支持的運維工具
技術選型
| Python
採用Python作為主要的開發語言，因為Python簡單易用強大，開發周期短(短，平，快)，跨平台，而且幾乎所有Linux系統都內置Python解釋器，第三方模塊多如牛毛; 更重要的是洋碼頭已有很多運維腳本和工具是用Python寫的，平台可以很容易也很方便地對其進行整合。
| Django
Python的web框架非常多，常用的有Django、Flask、Tornado、Pylons、Webpy、Bottle、Sanic等等，這裡我們為了能快速開發，省心省力而選用了Django，結合第三方神器django-rest-framework能夠輕鬆的自動生成符合RESTful規範的API。
| SaltStack
運維自動化工具也有很多，如Ansible、Bcfg2、Puppet、SaltStack等等，為了能夠支持Windows系統，我們選用SaltStack作為我們的底層工具。
| Celery
任務調度利器Celery是Python開發的分散式任務調度模塊，通過它可以輕鬆的實現任務的非同步處理。因為發布是一個非常耗時的過程，只需要將任務丟給Celery，然後該幹嘛幹嘛去，最後任務執行完成後告知用戶執行結果即可。
系統架構
發布系統架構圖
| Jira
Jira系統用於控制發布流程。我們利用Jira Workflow定製了工作流並通過用戶Group和Role進行許可權控制。開發提交發布任務申請、開發leader審批、測試通過SIT測試...，開發、測試可以在Jira上完成從SIT到PROD發布的整個流程，且所有操作均有據可查。
| WebUI
WebUI允許用戶創建發布任務，並提供比Jira系統更加詳細的數據展示，便於開發、測試、運維進行一站式監控、跟蹤及問題處理。
| CMDB
CMDB為發布系統提供數據支撐，如應用的基本信息，部署環境信息等等都從CMDB中獲取。
| 配置管理中心
配置管理中心負責保存各個應用的配置信息，如資料庫用戶名和密碼等敏感信息，在發布時，負責將配置打包並上傳到FTP伺服器中。
| FTP
FTP用於存放產物包和配置包。發布系統通過調用Saltstack腳本從FTP中獲取對應的產物包進行發布。
| Dispatch
Dispatch負責將任務下發，以及對salt-key和伺服器IP地址做映射管理，當有發布任務時，調用Saltstack執行發布腳本。
| 發布系統
發布系統用於把產物包發布到Stage和PROD環境。下面描述其核心運作邏輯：
洋碼頭目前有4套部署環境： SIT、UAT、Stage、PROD。SIT和UAT環境由測試人員通過Jenkins部署，我們的發布系統負責Stage環境和PROD環境部署。UAT環境測試通過後，測試人員通過Jenkins將UAT的產物打成zip包上傳到FTP中，發布系統驅動配置管理中心將配置文件也打成zip包上傳到FTP中；發布系統在Stage發布時從FTP中下載產物包和配置包，並在Stage發布成功後再將產物包和配置包合併打包成一個zip包上傳到FTP中供PROD發布。
為了支持各種語言代碼發布(IIS、Java、Nodejs、Python、Windows Service等)，我們分別對每種應用類型編寫Salt模塊或腳本。 發布系統通過任務類型來區分調用哪個模塊執行腳本，例如發布IIS應用調用PowerShell腳本執行，發布Java、Python、Nodejs、Static等應用調用與之對應的Salt自定義模塊執行。
採用通用化的啟動腳本以減輕維護成本。若有需要，也可以按照一定要求自定義啟動腳本。發布時會優先到指定路徑下尋找自定義的啟動腳本，否則將採用通用啟動腳本運行。
應用發布新版本後會在本地保留歷史版本的產物包，用於支持版本快速回滾，而不用再從FTP下載產物包。
功能特點
發布系統具有如下功能特點。
簡單的任務創建過程
開發人員或者運維人員創建任務時只需要填寫任務類型(環境)、應用名稱、版本號即可，服務端收到創建任務請求後，到CMDB中查詢這個應用的一些基本信息，便能知道該應用在什麼環境下有哪些機器，應用的啟動的埠，應用的類型(Nodejs還是Java或者IIS等)，根據這些信息創建發布任務。
WebUI創建任務界面
Jira界面
可視化的任務執行過程
通過自動化發布系統的WebUI界面，我們可以很清楚的看到發布任務執行狀態、進度、耗時、日誌等信息。同時為了提高用戶體驗，我們在發布的時候會對應用進行點火和健康檢測，確認應用發布上線後正常可用。
Stage發布可視化狀態截圖
PROD發布可視化狀態截圖
支持一鍵發布&灰度發布雙模式
所謂的一鍵發布是指將所有機器並行的進行部署，能提高發布速度，但如果發布失敗可能會導致整個應用業務不可用；而灰度發布能保證發布時不影響到業務，但發布速度相對一鍵發布要慢一些。開發同學可以根據自己的需要選擇合適的發布方式。
支持快速擴容和回滾
支持快速擴容發布，發布系統能自動從CMDB資源池中根據應用的類型挑選合適的機器，進行擴容發布。
當發布出現異常時，能夠直接從本地獲取上一版本或者指定版本進行版本回滾。
支持多機房和雲端部署
我們將雲主機當成普通的虛擬機，並自動同步到CMDB中，系統環境保持和IDC機房的機器一樣，網路也與IDC機房互聯互通，發布系統便能在多個機房和雲端進行部署。
嚴格的許可權控制
在運維管理中，對許可權的控制顯得尤為重要，在發布代碼時，對應用進行許可權隔離，只有與該應用相關的人員或者同屬於一個項目組的人員才能進行發布，否則無權進行發布操作。
通過django-guardian插件，能夠很輕鬆的實現對象級的許可權管控，具體可到官網查看使用方式
清晰的發布版本歷史記錄回溯
每次發布成功後，將發布版本記錄在CMDB中，並提供查詢入口，這樣可以清楚的查看該應用在哪些機房部署過哪些版本、當前的版本號等信息。
支持容器化部署
隨著容器技術的成熟，我們部署了一套Kubernetes集群，發布系統可以通過調用k8s-api介面實現Docker化的部署。具體實現方式如下： 對於需要上Docker的應用，首先將代碼包打成鏡像push到Harbor倉庫，然後在CMDB中做好標記。在發布時，發布系統會根據CMDB中應用的標記來決定採用VM的方式部署還是Docker部署，或者VM和Docker一起部署。
總結
到目前為止，這套發布平台已經平穩運行了兩年多，周發布量近1000次，而且最重要的是現在基本不需要運維人員進行發布操作，解放了運維的雙手，減輕了運維的工作壓力，大大提高了運維的工作效率。
全文完
近期分享預告：
洋碼頭搜索應用架構
洋碼頭推薦系統架構
洋碼頭數據倉庫建設實踐
每周我們都會推送一篇由洋碼頭一線工程師寫的技術分享。關注【洋碼頭技術】，第一時間獲取我們最新的技術分享推送吧。
TAG:洋碼頭技術 |