iMile 利用 Zadig 多雲環境周部署千次,跨雲跨地域持續交付全球業務

語言: CN / TW / HK

iMile 是一家跨境電商物流初創公司,提供中東和拉美等新興市場的物流服務,通過自建快遞團隊、精細化運營和網際網路技術手段,致力於完善跨境物流的末端一公里。iMile 已成長為中東 Top 3 的跨境電商物流服務公司,同時也是當地行業內發展速度 Top 2 的技術效益豐碩的物流公司。

痛點分析

在以往的業務研發過程,我們遇到如下的痛點:

  1. 環境治理複雜:dev、fat、lpt、uat、prod 等多套環境分佈在不同地區的資料中心,使用 Jenkins 流水線部署交付需要大量人工干預。

  2. 研發效率低:研發團隊程式除錯、聯調測試環境不夠友好,經常需要在多個環境的不同版本里來回切換協助測試、前後端排查問題,研發時間被佔用。

  3. 測試資源不足:排期專案與日常迭代經常混合在同一套測試環境裡測試,大量程式碼變動時部署並行效率不高,影響測試進度。

  4. 維護成本高:服務部署使用 Jenkinsfile + YAML 的方式,每個工程需要維護一套配置和指令碼,當工程越來越多時,維護成本會越來越重。

Zadig 之旅

在選型 Zadig 之前,我們有多套 K8s 叢集,分別部署在了多個不同的資料中心,使用 Kubeboard 進行多叢集統一管控,對叢集統管暫無其他特殊需求。

偶遇 Zadig

無意中在 B 站看到了 KodeRover Workathon 的線上分享(如下圖),就開始同團隊成員一起研究KodeRover(Zadig)這個產品。發現它與雲原生能夠非常完美的結合,多叢集服務可統一納管,多流水線併發構建,容器服務視覺化交付,面向研發互動友好。

恰巧當時我們研發團隊立項一個重構的專案,需要一套獨立的測試環境來滿足聯調測試任務。我們抱著新鮮的態度就部署了一套 Zadig 叢集,計劃通過它來解決這個專案重構的測試環境需求。通過 3 天時間的摸索溝通交流,我們很快在 Zadig 上部署了前後端工程服務到 K8s 叢集。

網路改造

我們當時網路狀況是這樣的:辦公內網與雲端的開發、測試環境內網是連通的,但到 K8s 的 Service 和容器網路層並未打通。

重構專案小組開始使用 Zadig 進行專案測試了,但後端研發同學找到我們提了一個需求“我想 debug 這個服務打斷點”。若要實現,則必須將 K8s 內網與辦公網全面打通,我們著手對網路進行改造,這樣很快研發即可在自己的 IDEA IDE 隨時呼叫、debug 自己的某一個服務。

全面擁抱 Zadig

全面擁抱雲原生屬於運維體系的進化,那麼全面擁抱 Zadig 則是研發體系的進化

一個月後重構專案順利上線,整個專案測試未與原有測試環境使用 NS 隔離,未對日常迭代和其他需求的測試環境造成任何干擾,專案部署變得非常容易,可以邊除錯邊檢視某個容器日誌,對研發同學的操作體驗有了質的提升,已經完全拋棄了原先使用 Kubelet 進入容器的種種麻煩。

有了這個正向的反饋,我們隨即做了一個決定,將開發環境、測試環境等全面接入 Zadig。

經過 4 個月的磨合,我們將所有開發和測試環境的 K8s 叢集接入了 Zadig。程式碼工程通過 YAML 標準模板匯入即可建立部署自己需要的服務。

經過近半年的努力,我們的研發、測試、運維團隊已經將所有服務全面接入 Zadig。接入 Zadig 的服務近 400個,一週部署平均近千次,較大的提升了研發效率,讓研發專注程式碼業務實現,測試團隊專注質量提升。測試或者驗證過程可以在幾分鐘內隨時拉起一套環境,供研發和測試使用,減輕了運維工作量和成本。

簡單回顧了一下幾個非常重要的需求細節,我們在這幾個功能完善之後,將所有叢集全部接入了 Zadig。

  1. 因我們屬於多地域跨雲部署,Zadig 預設只有一個映象倉庫,我們如果使用同一個倉庫的話,不同叢集的映象拉取和推送都是通過公網進行,拉取速度受到頻寬制約,且消耗流量非常多。

  2. IM 工具訊息提示推送文案優化。

  3. 專案許可權管理的顆粒化控制。

整體收益

Zadig 通過“工作流”整體串聯了 K8s 的各個元件,也串聯起了我們整個研發團隊,極大的減輕了指令碼的維護、環境治理,同時上手也非常簡單高效。在專案迭代和交付中起到了極大的幫助,節約了大量的時間成本,讓專業的人做“專業”的事兒,讓專案研發高效並行,減少團隊間的溝通 Gap,給我們的研發交付幫助極大。

總結就是簡單,高效

五、期待和建議

  1. 服務映象版本回滾,目前只有本地叢集(Zadig 部署的叢集)可以使用映象版本回滾,通過 Agent 連線的叢集無法做到映象回滾。

  2. 細化許可權控制的顆粒化程度,可以做到許可權分組自定義或者服務自定義到使用者或者使用者組。

  3. 支援多種部署方式,例如 Android 原生 APP 工程的構建,我們嘗試通過自定義映象來構建,但是安卓原生依賴資源很大,映象也很大,拉取映象啟動映象的速度比在雲主機直接構建耗時更久。

  4. 期待測試功能和 API 功能集合更加豐富,可以考慮外掛方式完善 Zadig 的生態。

感謝 Zadig 團隊的一直以來的幫助,在此期間我們一起探討了很多需求,都得到了快速的響應和解決。同樣期待 Zadig 可以走出國門,向海外市場進發!

Zadig,讓工程師更專注創造。歡迎加入 開源吐槽群🔥

Zadig on Github
Zadig on Gitee