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

首先聊聊我們面對(duì)的問題

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

針對(duì)上述幾個(gè)問題，我們構(gòu)建出了一個(gè)場(chǎng)景

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

結(jié)合問題、場(chǎng)景、容器化技術(shù)我們得出了以下的結(jié)論：

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

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

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

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

3.擴(kuò)展性強(qiáng)：如果標(biāo)準(zhǔn)任務(wù)不足以滿足特定需求，可以無需侵入gitlab本身的代碼，就能定制構(gòu)建和部署流程

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

先看看整體流程

圖片

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

詳細(xì)說說流程中的幾個(gè)核心點(diǎn)

1.代碼分支和環(huán)境對(duì)應(yīng)

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

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

圖片

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

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

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

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

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

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

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

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

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

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