一、DevOps的理解
DevOps的概念理解
DevOps 的概念在軟件開發行業中逐漸流行起來。越來越多的團隊希望實現產品的敏捷開發，DevOps 使一切成為可能。有了 DevOps ，團隊可以定期發布代碼、自動化部署、並將持續集成 / 持續交付作為發布過程的一部分。
一句話概括就是提高生產力,快速交付！
二、引入DevOps的背景
2.1 福祿技術棧介紹
-
後端開發框架：基於C#的.netCore和Java的SpringCloud,少部分項目採用python和go開發
-
前端開發框架：vue、react
-
服務部署：前端站點基於ECS的nginx部署 ，後端服務統一部署在kubernetes上
-
代碼倉庫：gitlab
-
項目環境：目前有6套，開發、測試、壓測、集成、PRE和生產
2.2 後端服務的CICD現狀
福祿後端CICD流程
CICD 流程說明
每一次的代碼push，根據創建的分支，根據在gitlab的CICD文件gitlab.yml定義構建步驟，觸發runner，從單元測試、通過dockerfile進行編譯和生成鏡像版本、將新鏡像部署到K8S生成pod，然後觸發接口自動化測試任務的執行
!!#00ffff 好像缺了點什麼 !!
-
初次部署應用到kubernetes怎麼做的？
-
服務的configmap在哪裡維護的？
-
每個服務的gitlab.yml文件都不一樣，如何維護的？
-
應用的域名解析怎麼做？
目前有6套環境進行管理，其中開發、測試、集成、壓測都是測試人員維護，預發布和生產運維人員維護；這也就要求每一個測試人員都必須對整個cicd流程和配置絕對掌握；所以當新人入職，需要掌握整個流程才能進入項目測試中，這是一個學習成本；
預發布和生產的kubernetes只有運維能夠操作，當有新的服務需要上線上述環境，或者configmap有變動，或者有時候排查問題需要查看容器日誌，我們只能通過運維的工單系統描述作業操作，中間文字描述可能存在理解差異，溝通成本和時間成本很大；
有的新應用我們去設置cicd的相關文件，比如dockerfile，我們發現應用的代碼目錄結構各種各樣，這樣往往就沒法套用一個模板快速配置完成
2.3 前端站點的CICD現狀
前端CICD流程說明
開發人員push代碼到gitlab，測試人員通過jenkins拉取最新的代碼到jenkins本地，然後通過jenkins與服務器之間的傳輸管道，將要部署的文件更新到目標服務器，並觸發UI自動化的job
完整的過程來看，也缺點內容
- 一個新的站點部署，nginx需要做一些配置初始化工作，比如域名、路徑的配置
- 前端的配置文件是如何管理的
跟後端應用一樣，前端的PRE和生產環境也是運維處理，所以當一個新的應用上線我們也需要發工單，描述具體操作，然後運維執行工單；配置文件一般不會變更，所以我們在jenkins推送更新文件到目標服務器的時候，將配置文件做了過濾處理。後續需要變更通過工單執行
2.3 痛點你看到了嗎
2.3.1 安全管控缺位
- 代碼安全：CICD的起點在gitlab裏面，所以大家都有gitlab的賬號，代碼安全管控缺位
- 線上安全：線上項目部署也是通過gitlab的cicd直接觸發，審批流程缺失
2.3.2 管理成本
- 維護賬號多：gitlab賬號、jenkins賬號、kubernetes賬號（本地和阿里雲），每一個人員都需要上述賬號，運維管理麻煩，大家每個平台維護自己的賬號也麻煩
- 工單溝通：工單編寫、溝通過程花費時間較多
- 代碼規範：項目組多，微服務也多，代碼框架各自發揮，無論是流程維護還是問題排查都增加了難度
三、研發管理平台（RDMS）應運而生
3.1 如何理解這個平台
!!#ff0000 工具鏈到平台的轉變 !!
當前的cicd是對工具鏈進行了打通，但需要大家登錄各個工具平台操作，我們希望對工具集進行功能整合，打造一個系統平台，並且將CICD的技術細節進行屏蔽，開發人員能夠專心進行業務需求的開發，測試人員能夠專註到需求測試任務中，而運維人員能夠解放繁重的工單內容，投入到服務高可用的建設上！
3.2 業務功能設計
福祿研發管理平台功能結構圖
3.2.1 功能說明
- 項目管理：項目的創建和維護，默認提供了.netcore的api和控制台，java的api和前端站點的應用初始化代碼框架，開發人員開發新的應用直接根據應用類型選擇對應的模板就可以在git默認創建代碼倉庫和初始化框架代碼，並自動生成應用的http和https的域名
- 構建記錄：獲取gitlab的pipeline,展示所有分支的構建記錄信息，可以一鍵跳轉到git倉庫
- 部署管理：部署構建的鏡像到指定的環境，提供實時部署和定時部署功能
- 容器管理：提供容器的查看功能，可以看到容器的存活狀態和容器實時日誌
- 配置字段權限申請：針對PRE和生產環境查看配置，需要先走釘釘審批申請流程
- 配置信息：進行配置的維護，包括新增、編輯、刪除，PRE和生產環境操作需要釘釘流程審批
- 操作日誌：針對應用的操作日誌記錄
- 用戶設置：在使用rdms前，需要先將用戶git倉庫的token設置在rdms上，這樣用戶在rdms操作與gitlab相關的業務才能正常使用
3.2.2 RDMS幾個核心頁面的展示
首頁-創建應用
構建記錄
部署管理
容器管理
3.3 技術架構
對接系統的說明
- 通行證：RDMS的目標用戶是研發中心人員，這些人員在通行證中都有默認的賬戶信息，與通行證打通，可以直接登錄使用
- GitlabAPI:目前RDMS的CI還是採用的gitlab的ci支撐，包括新應用在rdms的創建到git倉庫的代碼初始化等，都需要調用gitlab的api接口
- 釘釘flow：安全管控的原因，PRE和生產的任何操作都會觸發釘釘審批流，所屬項目的項目經理審批通過後才會獲取到數據或者執行操作指令
- 福祿開放平台：提供了網關相關的功能和菜單、角色等維護功能，公司所有後端服務都需要入駐開放平台
- 蜂巢：公司的調度作業平台，rdms的定時部署功能依賴該服務的支撐
- 運維工單系統：rdms的CD流程沒有直接與kubernets進行交互，而是通過運維的工單系統包裝了運維底層的shell腳本層，然後提供給rdms相關的api接口，也是基於安全控制的考慮
- shell腳本層：shell腳本層會調用kubernetes的api進行kubernetes的相關操作（部署、配置更新、容器重啟、日誌查看等）；調用阿里雲的dns解析接口，對應用的域名自動解析；調用oss的接口，進行前端站點文件目錄的維護
3.4 後端應用的devops實現詳解
舉個栗子進行介紹
根據模板，創建一個應用
根據名稱默認生成域名
初始化代碼倉庫，默認生成develop分支
在rdms第一次部署到對應環境（開發、測試、生產等）時，會默認讀取appsettings.Development.json的文件，並寫入kubernets的configmap
構建完成，進行部署
在kubernets生成pod
通過域名訪問接口文檔
3.5 前端站點的devops實現詳解
同樣的，舉個栗子介紹
首頁-創建前端站點
根據名稱生成域名
初始化代碼倉庫，默認生成develop分支
配置文件，默認生成幾套環境的配置文件,站點的配置維護就是維護這幾個文件
部署應用
kubernetes的nginx容器內可以看到部署的文件，實際就是掛載的oss到該pod上
四、展望
目前RDMS投產一個月左右，我們希望能將devops理念在這個系統上進行持續的優化和實踐，包括研發中心小夥伴也很踴躍參与共建，提出了很多好的方向和建議
- 完善devops鏈條功能：通過字面來看有dev、ops兩部分，我們後期需要加入test的比重，比如在CI部分，引入靜態代碼掃描、單測覆蓋率；在CD部分集成我們的自動化測、性能測試
- 工具平台：RDMS的初衷是整合，針對研發中心經常使用的工具或者有相關工具化的需求，我們可以整合到rdms或者在RDMS上進行開發
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※超省錢租車方案
※別再煩惱如何寫文案,掌握八大原則!
※回頭車貨運收費標準
※教你寫出一流的銷售文案?
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※網頁設計最專業,超強功能平台可客製化