?傳統(tǒng) CI/CD 處理的問題

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

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

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

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

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

云原生時代 CI/CD 面臨的挑戰(zhàn)

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

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

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

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

Jenkins+ArgoCD

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

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

現(xiàn)有很多 IT 公司都會有云資產(chǎn)，很多的正式環(huán)境都會放置在云端。這個時候就會有分歧——環(huán)境問題。

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

• 效能降低
• 環(huán)境治理困難
• 服務配置文件難以管理

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

為什么 Zadig 用的爽？

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

詳細部署圖如下：

通過一定的規(guī)劃后可以實現(xiàn) CI/CD 環(huán)境，一套主導所有。

這個時候可以算下成本，假設你環(huán)境之間是這樣區(qū)分的：

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

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

開發(fā)測試環(huán)境，4 個 slave ， 4 核 16G，本地機房虛擬機，共計消耗資源：16核，64G

如果統(tǒng)一了，那么降本增效不就出來了嗎？

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

Zadig 能解決企業(yè)數(shù)字化轉型的什么難題？

現(xiàn)有主機環(huán)境問題？

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

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

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

提供完善的分支，PR 構建

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

環(huán)境復制，開發(fā)測試，提升效能

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

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

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

Istio 子環(huán)境參考：自測聯(lián)調(diào)環(huán)境 | Zadig 文檔 [1]

環(huán)境托管功能，一個工作流，一個構建發(fā)布所有托管環(huán)境

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

環(huán)境配置（Ingress，ConfigMap，Secret）

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

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

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

Zadig 有著良好的抽象能力，能夠直接優(yōu)化比較重復的動作，就比如 CI/CD 經(jīng)常遇到的鏡像 Dockerfile，YAML 等，通過抽象成為模板實現(xiàn)配置的統(tǒng)一和規(guī)范化管理。

YAML 模板化

Helm 模板化

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

Dockerfile 模板化

構建配置模板化

我個人提供兩種思路：

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

Harbor 整合，配合正式環(huán)境的發(fā)布

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

版本管理（發(fā)版的 tag 交付物追蹤）

每個服務的 tag 制品發(fā)版管理，出現(xiàn)問題可快速回退相應的版本。

研發(fā)人員感知態(tài)

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

• 企業(yè)微信
• 釘釘
• 飛書

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

拓展功能點

測試功能的原生接入

代碼掃描的支持

自定義工作流，連接萬物

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

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

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

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

CI/CD 可觀測性

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

總結

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

參考鏈接

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

作者介紹

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