?傳統 CI/CD 處理的問題

說到 CI/CD 的工具，IT 圈內名聲最響亮的可能就會是傳統的老牌 CI/CD 的王者之一：Jenkins。說到它基本上 IT 人都知道。在曾經云計算時代，乃至更久遠的時代，因為那個時候軟件架構還沒有拆分成微服務，很多都是主機部署。所以 Jenkins 靠著一套 Pipeline 和自由風格流水線，打遍天下無敵手。

Jenkins 之所以能夠這么縱橫宇內有很大的一部分原因就是：開放，CI/CD，使用簡單，能夠走完一整套交付流程。

開放：意味著有著開放包容的api和插件，能夠面臨各種場合。

CI/CD：意味著能夠完整的走完一整套交付，包含代碼的拉取，制品的生成存儲以及服務的部署。

但是隨著技術的不斷迭代，Jenkins 終將有一天不再適合新的環境。各位請繼續往下看嘞。

云原生時代 CI/CD 面臨的挑戰

在云原生時代，萬物皆可云原生。隨著微服務的盛行，業務邏輯的服務拆分，容器化的興起，編排容器逐步成為了業務主流規范。進入到這一階段，新的挑戰也就隨之而來。例如：

• 以前服務少，Jenkins 能夠一把梭哈，現在服務多起來了，每個服務都要一個Jenkins Job，盡管都是一樣的邏輯，復制粘貼，但是數量多了也終將是一個麻煩事。如果十個，百個呢？
• 現在每個服務都要用 Jenkins 去做 CI/CD，那么我要封裝很多的 pipeline，還有 Dockerfile，這種有規律的文件為什么不能抽象化，每次都要自己寫。
• 每次使用都是通過 kubelet 加 shell 命令去做的構建部署，這樣合理嗎？
• 環境眾多，開發、測試、預發、壓測、生產，每個項目總有那么最少兩三個環境吧，這個時候環境多了如何管理呢？
• 通過 K8s 的標準編排，很多服務配置文件都會以 ConfigMap，Secret 的形式存在，不同環境的配置都會不一致，那么如何去做統一管理呢？
• 研發人員的感知態如何做到？研發人員需要知道這個服務上了 K8s 是否啟動成功，包含日志，事件信息，部署 Job 是否成功。這些能提供嗎？
• 發版服務的時候，如何才能合理管理版本呢？
• 開發測試找你要環境，你該如何快速部署相應呢？

以上種種就是服務遷移 K8s 后所要面臨的部分問題。Jenkins 很好，但是在新趨勢的到來后，個人還是感覺心有力而力不足。

或許你會說可以使用 Jenkins+ArgoCD 來彌補相互之間的差距啊。但是我始終還是覺得，Jenkins+ArgoCD 并非是最理想的狀態。

Jenkins+ArgoCD

Jenkins 可以做 CI，ArgoCD 可以做 CD，兩者相輔相成，可以實現基本的 K8s 環境的 CI/CD。類似示例圖如下：

兩者結合固然是可以做到持續集成和持續發布的，但是我們還是要結合實際出發。我沒有說不好，只是具體還要看使用場景和能夠解決哪些問題。

現有很多 IT 公司都會有云資產，很多的正式環境都會放置在云端。這個時候就會有分歧——環境問題。

或許我開發測試使用本地機房，但是我云端因為是生產環境，會單獨獨立區分環境。那么按照環境區分原則，我會有 2 套環境，開發測試一套 Jenkins+ArgoCD，正式環境一套 Jenkins+ArgoCD。那么這個時候如果說公司對環境更為重視還會有預發，壓測環境，那么又是一套 Jenkins+ArgoCD。好家伙，幾套環境，上線一個服務都會在以上環境中乘以 3 的操作，直接帶來的感覺就是：

• 效能降低
• 環境治理困難
• 服務配置文件難以管理

以上就是后續會面臨的問題，還有一些問題就是，通過 Jenkins+ArgoCD 僅僅只能做到 CI/CD，更多的呢，能夠做到嗎？這里好像還要打一個問號。

為什么 Zadig 用的爽？

Zadig 就是專門用來做效能的一款開源 CI/CD 平臺。我十分認可 Zadig 的使命：工程師是數字經濟最重要的資產，Zadig 讓工程師專注企業創新。他可以完美的解決我們遷移 K8s 后的一系列問題。如果加以規劃和使用，可以用如下流程圖來概括：

詳細部署圖如下：

通過一定的規劃后可以實現 CI/CD 環境，一套主導所有。

這個時候可以算下成本，假設你環境之間是這樣區分的：

其中正式環境 Jenkins 存在 slave 1 臺，4核16G 云主機，包月：412元/月

其中壓測，預發環境 Jenkins 存在 slave 1 臺，4核16G 云主機，包月：412元/月

開發測試環境，4 個 slave ， 4 核 16G，本地機房虛擬機，共計消耗資源：16核，64G

如果統一了，那么降本增效不就出來了嗎？

這個時候可能有人會說，小伙子是托兒，哈哈別急，讓我慢慢道來。

Zadig 能解決企業數字化轉型的什么難題？

現有主機環境問題？

很多企業在轉型剛剛開始期間，或者說業務場景需要，會有部分業務存在容器部署。如果這個時候讓你遷移，肯定不會一股腦的往 K8s 上塞，會慢慢的進行優化，這個時候 Zadig 支持主機環境的CI/CD，并且依靠 K8s 的彈性資源，能夠根據需求創建 Job 執行構建部署任務，但是天下沒有什么最好，只有更好，如果你微服務是多實例可能還真有點問題。那就是需要創建 2 個 Job。

彌補 Jenkins Job 單服務 2 任務的情況（一個構建打包，一個部署，通過 Git 修改協調（ArgoCD））

如果客官您使用的是 ArgoCD 那么我相信你肯定是基于 GitLab 去做的，Jenkins 肯定是在正式環境有 2 個 Job，一個負責構建上傳鏡像，另一個就是拉取 Git 倉庫進行服務的更改。這個時候會顯得很冗余，那么 Zadig 提供良好的構建部署的劃分，只需要你運行工作流的時候輕輕點擊是否構建即可。

提供完善的分支，PR 構建

好的 CI/CD 產品肯定是會對 Git PR 去做相關的適配的，Zadig 同樣如此，能夠在沒有合并之前提前進行測試，無需完成合并。

環境復制，開發測試，提升效能

在微服務橫行的今天，很多時候指不定那天就同時接了好幾個需求去做，那么這個時候開發需要環境，測試需要環境，怎么保證環境不沖突呢？那就是給他們一個新環境，但是提供新環境需要投入人力成本進去，有沒有什么辦法快速構建一套環境出來開發測試，后續不使用的時候銷毀？

以前可能有點麻煩，但是隨著業務容器化加上 K8s 的彈性擴縮容，這個就很好實現了，只需要找到相應的鏡像，YAML 更新到新的 Namespace 就可以了，但是這還是不夠優雅。

Zadig 提供環境的全量復制操作，一鍵就是一個基準環境，配合 Istio 進行子環境測試，直接解放雙手，原地起飛。

Istio 子環境參考：自測聯調環境 | Zadig 文檔 [1]

環境托管功能，一個工作流，一個構建發布所有托管環境

同項目，一直迭代，每個環節的服務都是一樣的，為什么一定要區分開呢，通過相應的權限控制，一套構建，部署所有的服務不香嗎？

環境配置（Ingress，ConfigMap，Secret）

項目中的配置等也有著較好的管理空間，可以直接抽象成為一個變量，每個環節的配置不同，但是引用的配置名相同，就可以實現環境之間的平滑遷移，比如：

• 上線中間件等連接依賴問題（ConfigMap  +  Service + Endpoint + CoreDNS）a. Service  ExternalNameb. Service None  +  Endpoints
• 項目外部訪問接口問題（Ingress）
• 中間件連接賬號密碼問題（Secret + env）

YAML，Dockerfile，Helm，服務構建模板管理

Zadig 有著良好的抽象能力，能夠直接優化比較重復的動作，就比如 CI/CD 經常遇到的鏡像 Dockerfile，YAML 等，通過抽象成為模板實現配置的統一和規范化管理。

YAML 模板化

Helm 模板化

這里偷懶沒搞，其實我不太熟 Helm

Dockerfile 模板化

構建配置模板化

我個人提供兩種思路：

• 服務模板化：所有的服務配置一次構建，后續上線新的服務，構建鏡像的時候直接引用模板
• 語言模板化：按照語言區分進行構建模板的抽象，構建模板主要信息如下：a. 構建產物所需要的應用，比如：Go，Java，NodeJSb. 構建產物所需要配置的命令

Harbor 整合，配合正式環境的發布

可以通過對 Harbor 的整合，實現不同環境的發布，就比如：正式環境只需要托管，無需配置其他的構建信息，工作流執行構建上傳到指定的 Harbor，正式環境不需要打包更新，直接更換鏡像制品。

版本管理（發版的 tag 交付物追蹤）

每個服務的 tag 制品發版管理，出現問題可快速回退相應的版本。

研發人員感知態

開發人員啟動發版工作流后，執行成功會有相關的 IM 推送，例如常見的：

• 企業微信
• 釘釘
• 飛書

部署邏輯這里，需要等待相關的探針就緒之后才會讓工作流進入下一步。

拓展功能點

測試功能的原生接入

代碼掃描的支持

自定義工作流，連接萬物

如果前面還有沒能夠解決老板您的問題，可以嘗試用自定義工作流，自己編碼業務實現邏輯，然后通過自定義工作流實現。以下我就舉一個 RDS 慢日志查詢的例子。

如果說，正式環境使用了云上的數據庫，以阿里云為例，查詢慢日志。規范起見，開發人員是沒有阿里云賬號的，運維人員有，但是運維人員一般都會基于 RDS 做相關的慢 SQL 監控，如果有那么就需要去檢索慢 SQL 條目。

一般這個時候會不斷找運維同學提供，但是如果說可以通過一條工作流實現，那么運維同學的負擔就會降低，可以去做更多的事情。

以上是我提供的一個思路，當然自定義工作流可以使用的場景可不僅僅是這樣，還有更多的場景需要大家一起發掘，也希望大家能夠不斷的輸入場景給 Zadig。

CI/CD 可觀測性

CI/CD 可觀測性也是很核心的一點，它可以讓研發大佬清晰的知曉公司的研發效能如何，構建規律如何，測試情況如何。很多時候都能夠從這里讀出一些后續工作方向出來，Zadig 的這個概覽也是我十分喜愛的一個點，畢竟是自己打下的江山不是嗎？

總結

IT 領域的演變，就是運維人員通過不斷向上接手開發人員眼中“跟開發無關的雜活”，來不斷為開發人員減負。開發人員在得到了解放后，可以將視角更多的聚焦在自己開發的業務系統上，釋放出自己的創造力。但是運維人員也要不斷的優化現有的基礎設施架構，以及構建簡單易用的平臺化工程來給開發人員使用。平臺化工程或許是未來 CI/CD 的一個趨勢和演進方向吧。

參考鏈接

[1] https://docs.koderover.com/zadig/v1.15.0/env/self-test-env/

作者介紹

我叫唐啟濤。目前就職于廣州某公司，哈哈，剛剛入職沒有多久，然后崗位應該算是運維還是運維開發，我也不知道。因為我工牌是運維開發，但是我企業微信又是運維，不過這個不重要，以下是我作為一個“Zadig 過來人”帶來的一些使用分享、以及方案選型對比，希望對后續大家公司的 CI/CD 優化有所幫助。