溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關基于Saltstack、Artifactory如何打造傳統模式下持續部署平臺，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
由于沒有建立標準的持續部署流程，導致了版本管理混亂，制品管理混亂，上線持續時間長，上線測試覆蓋不全面，業務流量上升后故障較多，排查復雜。運維、測試、開發人員每次版本迭代的時候，都要可能需要經歷一次通宵的歷練，并且這種在上線的第二天依然會出現很多線上故障。
l 自動化發布體系覆蓋率低。
l 無標準化發布的流程。
a) 只注重敏捷、忽視質量問題；
b) 變更頻繁導致故障率增加；
c) 開發語言種類多，發布制品管理混亂，發布方式復雜；
l 安全問題容易被忽視。
基于ZeroMQ的開源的配置管理工具。筆者之所以選型使用saltstack，而放棄了ansible，原因是由于ansible基于ssh通信，在管控主機超過五百臺之后，基于消息隊列的命令下發方式無論在穩定性還是速度上都優于ssh協議。筆直另外選在saltstack的原因是，在服務的開發團隊中存在著不同的技術棧并行的狀況，尤其是java和.net并存的情況下，saltstack對于windows的支持明顯要優于ansible。更容易作為多平臺的底層發布工具。
而基于SaltStack打造自動化部署平臺主要是用grains、pillar、state三個特性，grains用于獲取默認環境配置信息、pillar用于定義環境信息、state用于編排發布文件進行發布。
全語言制品倉庫管理軟件，有開源版及企業版兩種。開源版支持maven制品管理；企業版支持全語言制品管理，支持元數據管理功能，提供高可用部署方式、匹配nvd及vulnDB數據庫，提供漏洞掃描能力。
通過搭建兼容多平臺部署統一發布工具，替換掉傳統的shell腳本拷貝的方式實現發布工具標準化。通過SaltStack的state特性，實現跨平臺的基礎服務發布、服務啟停、文件發布、配置發布、遠程主機管理等90%以上手動操作。使用SaltStack的state編排文件，執行遠程命令，通過Artifactory獲取制品及配置，將需要的版本發布到線上。
主要方案在部署平臺中，通過json格式描述發布流程，通過yaml.dump(sls_json）將json文件轉換成yaml各位的配置文件，最終通過平臺調度saltstack執行編排好的任務。
轉換后的yaml文件格式如下：
l 備份
發布任務編排的第一步就是備份，備份需采用本地備份加異地備份兩種機制，本地備份用于快速回滾，異地備份用于環境重建。
l 切流量（藍綠部署）
對于服務，尤其是有狀態的服務，需要在注冊中心中進行節點下線，確保本節點所有處理結束后，再進行部署。
對于頁面，需要在負載均衡上將節點注銷，對沒有流量的web頁面進行部署操作。
l 部署
通過saltstack的sls特性，編排部署文件，對多個部署任務進行統一進行發布。
部署時我們希望可以在部署頁面查看到類似下述信息，如：部署包對應的需求id、部署包對應代碼的提交信息、部署包自動化測試的通過率、部署包的代碼掃描結果、部署包的安全掃描結果、部署包人工測試的結果等等。運維人員需要在發布過程中看到此類信息，來明確包是否通過了所有質量關卡、具備了上線條件，從而判斷此次上線是否可以繼續進行。這里我們使用了Artifactory的元數據功能，用于記錄軟件包誕生的整個生命周期的信息，并通過api方式對接到發布平臺。給運維人員一個完整的包的信息記錄。
l 自動化測試
此處自動化測試主要可以理解為檢測服務端口通信是否正常、回歸線上功能是否可用、缺陷是否被修復、新特性是否部署完成等。同時此處需要預熱服務及站點，通過自動化的測試打通業務流程。
l 流量回歸（金絲雀）
部分真實流量切換到已經部署完成的應用上，通過全鏈路日志追蹤或監控指標反饋來初步判斷新上線應用是否健康運行，并將此結果作為后續發布或回退的依據。
l 部署補全（滾動發布）
在使用低谷時間將流量牽引到已部署完成的應用上，同時將其余應用升級。
l 變更管理通告。
上線成功后需要及時的通知大家線上版本已變更，產品經理需要及時更新文檔，運營人員需要及時對用戶進行告知。
l 回滾
任何發布都需要考慮回滾方案，對于單個應用需要回滾到一個指定版本；對于多個應用，需要明確一個回滾集，通過發布時的編排任務指定回滾的編排任務。對于數據庫等更新，如果回顧復雜，則需要在升級方案制定前就明確回滾方案或在業務中做好版本兼容。
大多互聯網公司已經對源碼倉庫有了統一的管理，但對于制品依然處于一個原始的管理狀況，比如使用ftp以及每種語言開源的管理倉庫。這里遇到的問題是，運維人員需要投入大量的精力維護不同的包管理平臺（如ftp、maven、nuget、pypi、docker鏡像中心等）。浪費掉大量運維團隊的人力成本之外，也極度復雜了發布流程。發布人員需要在不同的平臺獲取上線的包，導致發布流程混亂，發布平臺配置混亂。并且大多數開源組件均不提供高可用能力，一旦硬件或軟件出現故障，都將嚴重的影響發布效率。
為了解決這種問題，我們采用Artifactory來管理所有語言的制品倉庫。與統一gitlab一個道理，我們把整個公司的制品統一管理，成為對接發布平臺的唯一包來源，從而規范了發布流程。
目前安全團隊掃描大多是在服務部署上線后進行，這種情況下和容易造成由于版本有安全漏洞導致的整個迭代廢棄，所有包需要重新編譯，重新經過測試流程以及上線過程，浪費掉大量的時間，降低迭代的速度。
解決辦法是將漏洞掃描步驟前置，在制品包構造編譯的時候，乃至開發人員code代碼的時候就對外部引用、內部公共庫進行漏洞掃描，一旦匹配到高危漏洞，直接把提交或構建終端。如果一定要繼續構建，那么可以將掃描結果記錄到制品的元數據中，供測試人員，運維人員查看。目前JFrog Xray等安全掃描故居提供此類能力。也可以使用開源軟件，如cvechecker，在編譯流水線中對包進行掃描，防止由于安全漏洞造成的整個迭代失敗。
敏捷開發模式下，開發人員和測試人員往往是匯報給同一位管理人員，出于快速迭代線上功能，往往有些團隊會投機取巧、將沒有測試完整的包發布到線上進行測試。該種問題的直接表現是，為了解決一個bug，可能多時間多次對同一個應用或頁面進行hotfix或發布新版本。這樣做是十分危險的，置線上業務穩定于不顧。為了避免此類情況發生、我們可以采用一些措施或規范來約束開發團隊。例如：
上線后觸發新bug數量
短時間內對相同問題發布次數
由于上線原因造成的P5-P0級別故障的數量
上線后故障恢復時間
上線后回滾的次數
非上線時間內緊急上線數量
…
通過收集上述數據，每月或固定周期對各個團隊進行考核。并對發布狀態復盤，通過制定規約，評估團隊的交付質量及交付能力，挖掘團隊中的發布問題及痛點，從而提高發布質量，減少線上故障率。
每團隊初始分為100分，每月重置，每月用此分作為迭代質量的一項標準，分數不掛鉤kpi考核，只用來驅動開發團隊去提高效率。
評判為兩個維度：項目組發布穩定性得分、服務（站點、app、微服務等）發布質量得分
l 非上線時間發布hotfix（項目組減1分，服務減1分）
l 代碼類hotfix，同一項目每天發布超過3次（項目組減1分，服務減2分）
l hotfix發布失敗或回滾（項目組減2分，服務減2分），發布是否失敗，由運維團隊認定。
l 數據庫等腳本異常或執行失敗（項目組減1分）
l 每月服務發布數量（取top5，服務按排序減5到1分）
l 由于hotfix原因造成P2級以上的線上事故，項目組減5分，相關服務減5分
l 項目組本月hotfix量如超過前3月平均值的30%，減10分
在google的SRE體系中，變更管理是DevOps體系中最為重要的一個部分。根據以往的經驗，90%的線上故障是由于線上變更導致的，該變更原因包括軟件、硬件、環境等所有因素。建設變更管理體系目的就是為了快速定位線上問題，止損由于變更造成的線上故障，及時通知相關人員做好故障預防工作。所以，變更管理體系也是需要我們重點去建設以及完善的。
落地方式包括但不限于下述幾點：
l 運維人員、對應的開發及測試人員、產品經理等微信通知
l 大屏滾動播放最近的變更記錄
l 變更記錄同步到監控系統
雖然在敏捷開發模式下、產品、開發、測試團隊都在小步快跑，但運維必須有自己的原則，一定要對整個上線流程制定規范、對DevOps工具鏈進行統一管理。
以上就是基于Saltstack、Artifactory如何打造傳統模式下持續部署平臺，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
