一、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，然后觸發接口自動化測試任務的執行

好像缺了點什么？

• 初次部署應用到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 如何理解這個平臺

工具鏈到平臺的轉變

當前的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上進行開發

總結

以上是生活随笔為你收集整理的我们是如何做DevOps的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。