咱們是如何作DevOps的？

1、DevOps的理解

DevOps的概念理解

DevOps 的概念在軟件開發行業中逐漸流行起來。愈來愈多的團隊但願實現產品的敏捷開發，DevOps 使一切成爲可能。有了 DevOps ，團隊能夠按期發佈代碼、自動化部署、並將持續集成 / 持續交付做爲發佈過程的一部分。
一句話歸納就是提升生產力,快速交付！

2、引入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帳號（本地和阿里雲），每個人員都須要上述帳號，運維管理麻煩，你們每一個平臺維護本身的帳號也麻煩
• 工單溝通：工單編寫、溝經過程花費時間較多
• 代碼規範：項目組多，微服務也多，代碼框架各自發揮，不管是流程維護仍是問題排查都增長了難度

3、研發管理平臺（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上

4、展望

目前RDMS投產一個月左右，咱們但願能將devops理念在這個系統上進行持續的優化和實踐，包括研發中心小夥伴也很踊躍參與共建，提出了不少好的方向和建議

• 完善devops鏈條功能：經過字面來看有dev、ops兩部分，咱們後期須要加入test的比重，好比在CI部分，引入靜態代碼掃描、單測覆蓋率；在CD部分集成咱們的自動化測、性能測試
• 工具平臺：RDMS的初衷是整合，針對研發中心常用的工具或者有相關工具化的需求，咱們能夠整合到rdms或者在RDMS上進行開發