前兩篇講到了服務如何適配容器化我們在服務里做的一系列改造，服務可以很優雅的適配容器化環境了，但是有一個前提是服務得容器化，也就是說如何打包成鏡像。自己手動構建推送鏡像可不可以？當然可以，不過老話說得好，一個月幾百塊，你玩兒什命啊。你天天手動，手不累么？肩膀不酸嗎？身體受得了嗎？別再自己用手了，通過Gitlab CI來解放你的手，用你的手去做些更快樂的事情。bvy28資訊網——每日最新資訊28at.com

首先聊聊我們面對的問題bvy28資訊網——每日最新資訊28at.com

1. 測試需要一個獨立的測試環境，避免來自研發人員頻繁提交代碼帶來的干擾，但是不想給測試人員帶來額外的負擔
2. 開發環境和測試環境構建流程需要一致化，開發人員在本地就能觸發多個環境的構建和部署
3. 環境按照研發團隊進行隔離，每個團隊獨立一套開發和測試環境，團隊之間互不影響
4. 服務在開發環境能正常運行再交由測試同學
5. 部署生產環境時，保證部署的服務一定是測試后的版本，避免出現選擇錯誤版本導致的線上問題
6. 需要對生產環境中服務所需的CPU和內存用量有一個大概預估
7. 生產環境服務出現問題，如何快速追溯到是哪個版本發布后出現的，從發布版本追溯到代碼版本
8. 我們不想引入其他的平臺來增加復雜度，運維維護成本
   

針對上述幾個問題，我們構建出了一個場景bvy28資訊網——每日最新資訊28at.com

開發同學開發完成后先在開發環境里測試完成后自動部署至測試環境，測試同學進行多輪測試后標記可發布的服務版本，同時可能存在同一個服務根據不同的需求在多分支上的開發和測試問題。而生產環境部署時只能選擇測試確認的服務版本進行發布上線，并且對于服務的資源配置要提供參考。線上運行過程中遇見的問題能追溯到發布版本和代碼版本。bvy28資訊網——每日最新資訊28at.com

結合問題、場景、容器化技術我們得出了以下的結論：bvy28資訊網——每日最新資訊28at.com

• 基于k8s namespace策略做環境隔離、團隊隔離，通過資源限制策略、調度策略進行控制不同環境的資源用量，減少資源成本、維護成本
• 多個開發環境和測試環境在提交代碼后均可完成自動構建和部署
• 將代碼分支和部署環境進行匹配，同時支持根據不同環境注入不同的環境變量值(前一篇文章分享過)
• 通過監控數據向正式環境提供服務運行CPU和內存的參考值，可以考慮直接用k8s VPA的策略(生產環境暫時不推薦使用)，也可以考慮參考VPA的算法再結合監控數據進行計算,不過這個帶來的問題是需要人工調整服務的Request/Limit值
• 線上部署的應用服務記錄版本號用于問題追溯到代碼
• 在不引入其他平臺的前提下完成整個流程，我們就把目光聚焦在了gitlab提供的ci能力上了

為什么我們選擇用gitlab ci?網上一搜索就有很多在講優勢劣勢，這里說說我們看中的幾個原因：bvy28資訊網——每日最新資訊28at.com

1.輕量：內置在Gitlab平臺中，和代碼管理天然融合一體，而且上線的服務只用記錄commit號在后續回溯代碼時很方便bvy28資訊網——每日最新資訊28at.com

2.易于配置：配置使用YAML文件進行定義，具有直觀的語法。這使得構建、測試和部署流程可以以代碼的方式進行管理，易于維護和版本控制bvy28資訊網——每日最新資訊28at.com

3.擴展性強：如果標準任務不足以滿足特定需求，可以無需侵入gitlab本身的代碼，就能定制構建和部署流程bvy28資訊網——每日最新資訊28at.com

總結下來，gitlab提供的ci從我們的角度看，夠輕量，夠簡單，擴展性強。尤其是擴展性強這一點，這點讓我們臉都笑開花了，可以低成本實現我們的想法，滿足我們的想象力。bvy28資訊網——每日最新資訊28at.com

先看看整體流程bvy28資訊網——每日最新資訊28at.com

圖片bvy28資訊網——每日最新資訊28at.com

整套流程涵蓋了開發階段、線上運行階段，首先開發階段下，運維同學只需要在開發測試的k8s集群中為不同團隊創建ns并做資源限制，后續的部署更新都是基于研發同學的代碼提交觸發，研發人員可在提交代碼后通過gitlab pipeline查看ci構建、部署結果。開發環境中健康檢查通過，研發測試沒有問題后將該迭代版本的代碼合并到對應的測試分支部署至測試ns交由測試人員進行測試，整體測試完成后標記服務鏡像正式版本號。而后在平臺上進行發布操作。后續運行過程中遇見的問題通過服務鏡像號可以追溯到對應代碼，修復后重復上述過程bvy28資訊網——每日最新資訊28at.com

詳細說說流程中的幾個核心點

1.代碼分支和環境對應

首先定義namespace名稱困難不困難？困難，而且不只是這個名字困難，涉及到命名的時候都困難，方法名、變量名，尤其是變量名，當然如果說都是用i,j 這些來作為變量名也算的話那就不困難，但是別人看到了。。怕是要被刀。。bvy28資訊網——每日最新資訊28at.com

所以namespace是基于gitlab組和分支規范較為方便，分支規范每家不一樣沒有對錯之分，把握的原則只是分支與環境對應就好。舉一個例子，分支命名dev作為開發分支前綴，test作為測試分支前綴，master作為主分支，gitlab上有兩個組 team1,team2(team2和team1一樣的邏輯圖中就不多畫了)bvy28資訊網——每日最新資訊28at.com

圖片bvy28資訊網——每日最新資訊28at.com

這樣做了之后，可以通過在ci中解析分支命名就可以在對應的namespace下創建有分支后綴的服務名了bvy28資訊網——每日最新資訊28at.com

2.如何限制環境下的資源

通過k8s提供的resourcequotas限制每個namespace的資源上限，通過監控集群資源池和namespace的資源用量，來調整集群的整體資源池，如果使用的公有云還可以通過k8s提供的CA(Cluster Autoscaler)進行伸縮bvy28資訊網——每日最新資訊28at.com

3.線上問題如何追溯到代碼版本

在CI構建打包的時候，在gitlab runner中可以通過獲取環境變量的方式來獲取本次提交的commit值并自動添加到鏡像版本號中，這樣在后續通過鏡像版本號便能追溯到對應的代碼版本。bvy28資訊網——每日最新資訊28at.com

4.為何只提ns，不提集群

這是因為ns是一個邏輯概念，是為了考慮k8s集群出現災難性故障時，可以方便我們快速在一個新的k8s集群中迅速重建所有服務。同時也讓一次CI部署多套集群成為可能。bvy28資訊網——每日最新資訊28at.com

5.如何實現自行實現上述流程

從圖中可知總共分成了4個大塊，可以根據自己的需求去實現。bvy28資訊網——每日最新資訊28at.com

1. CI gitlab原生支持，只需要定義好一個ci.yml文件，然后其他的工程下引用這個文件就可以完成觸發動作
2. 開發測試環境部署這個可以通過各類語言對接k8s就能完成，不過我們推薦采用operator的形式進行實現，這樣對于服務版本，信息注入更方便
3. 生產環境部署目前市面上的k8s管理類平臺不少，都是可以達成這個效果的
4. 運行監控監控從兩個維度來做，指標和日志。指標監控首推prometheus，日志可以采用EFK套件，較為成熟不過我們覺得成本太貴，Loki是一個不錯的替代方案。我們的平臺則是采用公司自研的數據庫實現了日志模塊。

本文鏈接：http://www.tebozhan.com/showinfo-26-5758-0.html摸魚心法——CI成就夢想

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： 錯誤處理策略：Java開發者的MySQL數據庫故障解決方案

下一篇： 每個前端開發者都應知道的14個實用網站