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

說(shuō)到 CI/CD 的工具，IT 圈內(nèi)名聲最響亮的可能就會(huì)是傳統(tǒng)的老牌 CI/CD 的王者之一：Jenkins。說(shuō)到它基本上 IT 人都知道。在曾經(jīng)云計(jì)算時(shí)代，乃至更久遠(yuǎn)的時(shí)代，因?yàn)槟莻€(gè)時(shí)候軟件架構(gòu)還沒(méi)有拆分成微服務(wù)，很多都是主機(jī)部署。所以 Jenkins 靠著一套 Pipeline 和自由風(fēng)格流水線，打遍天下無(wú)敵手。

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

開(kāi)放：意味著有著開(kāi)放包容的api和插件，能夠面臨各種場(chǎng)合。

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

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

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

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

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

以上種種就是服務(wù)遷移 K8s 后所要面臨的部分問(wèn)題。Jenkins 很好，但是在新趨勢(shì)的到來(lái)后，個(gè)人還是感覺(jué)心有力而力不足。

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

Jenkins+ArgoCD

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

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

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

或許我開(kāi)發(fā)測(cè)試使用本地機(jī)房，但是我云端因?yàn)槭巧a(chǎn)環(huán)境，會(huì)單獨(dú)獨(dú)立區(qū)分環(huán)境。那么按照環(huán)境區(qū)分原則，我會(huì)有 2 套環(huán)境，開(kāi)發(fā)測(cè)試一套 Jenkins+ArgoCD，正式環(huán)境一套 Jenkins+ArgoCD。那么這個(gè)時(shí)候如果說(shuō)公司對(duì)環(huán)境更為重視還會(huì)有預(yù)發(fā)，壓測(cè)環(huán)境，那么又是一套 Jenkins+ArgoCD。好家伙，幾套環(huán)境，上線一個(gè)服務(wù)都會(huì)在以上環(huán)境中乘以 3 的操作，直接帶來(lái)的感覺(jué)就是：

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

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

為什么 Zadig 用的爽？

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

詳細(xì)部署圖如下：

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

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

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

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

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

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

這個(gè)時(shí)候可能有人會(huì)說(shuō)，小伙子是托兒，哈哈別急，讓我慢慢道來(lái)。

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

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

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

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

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

提供完善的分支，PR 構(gòu)建

好的 CI/CD 產(chǎn)品肯定是會(huì)對(duì) Git PR 去做相關(guān)的適配的，Zadig 同樣如此，能夠在沒(méi)有合并之前提前進(jìn)行測(cè)試，無(wú)需完成合并。

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

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

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

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

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

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

同項(xiàng)目，一直迭代，每個(gè)環(huán)節(jié)的服務(wù)都是一樣的，為什么一定要區(qū)分開(kāi)呢，通過(guò)相應(yīng)的權(quán)限控制，一套構(gòu)建，部署所有的服務(wù)不香嗎？

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

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

• 上線中間件等連接依賴問(wèn)題（ConfigMap  +  Service + Endpoint + CoreDNS）a. Service  ExternalNameb. Service None  +  Endpoints
• 項(xiàng)目外部訪問(wèn)接口問(wèn)題（Ingress）
• 中間件連接賬號(hào)密碼問(wèn)題（Secret + env）

YAML，Dockerfile，Helm，服務(wù)構(gòu)建模板管理

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

YAML 模板化

Helm 模板化

這里偷懶沒(méi)搞，其實(shí)我不太熟 Helm

Dockerfile 模板化

構(gòu)建配置模板化

我個(gè)人提供兩種思路：

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

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

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

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

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

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

開(kāi)發(fā)人員啟動(dòng)發(fā)版工作流后，執(zhí)行成功會(huì)有相關(guān)的 IM 推送，例如常見(jiàn)的：

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

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

拓展功能點(diǎn)

測(cè)試功能的原生接入

代碼掃描的支持

自定義工作流，連接萬(wàn)物

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

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

一般這個(gè)時(shí)候會(huì)不斷找運(yùn)維同學(xué)提供，但是如果說(shuō)可以通過(guò)一條工作流實(shí)現(xiàn)，那么運(yùn)維同學(xué)的負(fù)擔(dān)就會(huì)降低，可以去做更多的事情。

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

CI/CD 可觀測(cè)性

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

總結(jié)

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

參考鏈接

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

作者介紹

我叫唐啟濤。目前就職于廣州某公司，哈哈，剛剛?cè)肼殯](méi)有多久，然后崗位應(yīng)該算是運(yùn)維還是運(yùn)維開(kāi)發(fā)，我也不知道。因?yàn)槲夜づ剖沁\(yùn)維開(kāi)發(fā)，但是我企業(yè)微信又是運(yùn)維，不過(guò)這個(gè)不重要，以下是我作為一個(gè)“Zadig 過(guò)來(lái)人”帶來(lái)的一些使用分享、以及方案選型對(duì)比，希望對(duì)后續(xù)大家公司的 CI/CD 優(yōu)化有所幫助。