企業級Gitlab-ci實踐
前言
吐槽一波
2020年6月2號剛入職公司時，第一感覺是叢集環境是個大坑！內網一套，公網一套。內網採用單節點Kubernetes，公網採用aliyun託管的X節點Kubernetes(還有節點是2C的...)。內網Kubernetes環境幾乎無人使用(可能後端開發工程師在偶爾使用吧)。公網的X節點Kubernetes叢集，也可以是稱之為生產Kubernetes叢集，也可以稱之為測試Kubernetes叢集，天才的設想--通過名稱空間區分叢集環境！
引出話題
研發人員向部署在公網的Kubernetes叢集的gitlab程式碼管理倉庫推送程式碼，然後由部署在香港伺服器的gitlab-runner做ci，容器映象是存在gitlab上的，也就是公網kubernetes叢集上，emmm，好吧，反正是叢集重構勢在必行了。
叢集重構說的也直接點也就是針對ci的重構，用起內網環境，增加預發環境，將公網Kubernetes的測試環境給剔除掉。
架構圖
企業級叢集架構圖
由上圖可知，分三種環境：研發環境（內網環境）；預發環境（和生產環境處於同一VPC）；生產環境（原公網環境【升配】）。
研發環境
研發人員：開發的日常開發工作都在這個環境進行。大部分的基礎開發工作都會在該環境進行。
測試人員：主要用於測試驗證當前的需求開發是否符合預期。
預發環境
其實就是真實的線上環境，幾乎全部的環境配置都是一模一樣的，包括但不限於，作業系統版本以及軟體配置，開發語言的執行環境，資料庫配置等。 最後上線前的驗證環境，除了不對使用者開放外，這個環境的資料和線上是一致的。產品、運營、測試、開發都可以嘗試做最後的線上驗證，提前發現問題。
環境對比
| 分類 | 使用場景 | 使用者 | 使用時機 | 備註 |
|---|---|---|---|---|
| 研發環境 | 日常開發測試驗證 | 開發測試工程師 | 需求開發開發完成 | |
| 預發環境 | 線上驗證 | 開發、測試、產品、運營等 | 上線之前 |
gitlab-ci架構圖
如上圖所示，開發者將程式碼提交到GitLab後，可以觸發CI指令碼在GitLab Runner上執行，通過編寫CI指令碼可以完成很多使用的功能：編譯、測試、構建docker映象、推送到Aliyun映象倉庫等；