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

首先聊聊我們面對的問題

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

針對上述幾個問題，我們構建出了一個場景

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

結合問題、場景、容器化技術我們得出了以下的結論：

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

為什么我們選擇用gitlab ci?網上一搜索就有很多在講優(yōu)勢劣勢，這里說說我們看中的幾個原因：

1.輕量：內置在Gitlab平臺中，和代碼管理天然融合一體，而且上線的服務只用記錄commit號在后續(xù)回溯代碼時很方便

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

3.擴展性強：如果標準任務不足以滿足特定需求，可以無需侵入gitlab本身的代碼，就能定制構建和部署流程

總結下來，gitlab提供的ci從我們的角度看，夠輕量，夠簡單，擴展性強。尤其是擴展性強這一點，這點讓我們臉都笑開花了，可以低成本實現(xiàn)我們的想法，滿足我們的想象力。

先看看整體流程

圖片

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

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

1.代碼分支和環(huán)境對應

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

所以namespace是基于gitlab組和分支規(guī)范較為方便，分支規(guī)范每家不一樣沒有對錯之分，把握的原則只是分支與環(huán)境對應就好。舉一個例子，分支命名dev作為開發(fā)分支前綴，test作為測試分支前綴，master作為主分支，gitlab上有兩個組 team1,team2(team2和team1一樣的邏輯圖中就不多畫了)

圖片

這樣做了之后，可以通過在ci中解析分支命名就可以在對應的namespace下創(chuàng)建有分支后綴的服務名了

2.如何限制環(huán)境下的資源

通過k8s提供的resourcequotas限制每個namespace的資源上限，通過監(jiān)控集群資源池和namespace的資源用量，來調整集群的整體資源池，如果使用的公有云還可以通過k8s提供的CA(Cluster Autoscaler)進行伸縮

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

在CI構建打包的時候，在gitlab runner中可以通過獲取環(huán)境變量的方式來獲取本次提交的commit值并自動添加到鏡像版本號中，這樣在后續(xù)通過鏡像版本號便能追溯到對應的代碼版本。

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

這是因為ns是一個邏輯概念，是為了考慮k8s集群出現(xiàn)災難性故障時，可以方便我們快速在一個新的k8s集群中迅速重建所有服務。同時也讓一次CI部署多套集群成為可能。

5.如何實現(xiàn)自行實現(xiàn)上述流程

從圖中可知總共分成了4個大塊，可以根據自己的需求去實現(xiàn)。

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