WePack —— 助力企業漸進式 DevOps 轉型

本文爲 CODING 高級產品經理俞典在騰訊雲 CIF 工程效能峯會上所做的分享。文末可前往峯會官網,觀看回放並下載 PPT。

大家好,我是 CODING 高級產品經理俞典。DevOps 對於大家而言應該已經不是一個陌生的概念,它爲研發團隊帶來了更快的交付速度、響應變化和更好的團隊協作方式,幫助企業實現幾天到幾周內交付和部署軟件。在 DevOps 流程中,大家可能更容易關注到代碼、流水線、測試、發佈等工具帶來的效能升級,那麼我們在構建什麼、測試應用的來源是什麼、發佈什麼?——這三個問題的答案都是「製品包」。

軟件開發中的製品管理就如同傳統制造業中的貨倉管理,它連接着產品的生產和發佈兩個階段。前幾天我簡單統計了一下 CODING 研發團隊自身的製品數據,在一天中,整個團隊推送了 6000 多個製品,同時產生了 1 萬多次製品拉取操作。製品不僅數量大,還因爲開發語言不同、面向的環境不同有着不同的屬性,需要分門別類的管理。而製品的推拉穩定性、安全性與信息準確性決定了整個產品的生產質量。那麼圍繞企業級製品管理面臨的各種複雜問題,我今天爲大家介紹 CODING 自主研發的企業級製品管理服務——「WePack」的設計理念和落地實踐。

說到痛點,大家可以和我一起來對你所在的團隊的疼痛指數做一個評估。首先是疼痛指數最高的一類用戶:我們之前遇到過很多的用戶,因爲整個研發團隊有 Java、C++、前端等不同技術棧,生產的製品類型也各有不同。很多用戶使用傳統的 Ftp 或者 SVN 倉庫來管理軟件壓縮包,自己搭一個 Nexus 來管理開源的第三方 Maven、Npm 依賴。隨着容器鏡像的普及,研發團隊逐漸產生了一些 Docker 鏡像需要管理,於是用戶再自己搭了一套 Harbor 來管理鏡像。

這些系統各有各的一套管理體系和賬號體系,給運維人員帶來了較高的管理成本。製品的管理尚且沒有打通,和其他 DevOps 模塊的打通就更是難上加難。因此集中管理製品是企業用戶建立 DevOps 製品管理體系的第一步。

很多用戶意識到了這個問題,因此開始基於 Nexus 這樣的開源製品庫自建,或者採買 JFrog 這類統一的製品管理平臺來管理製品。此時集中化的管理又帶來了新的問題:這些工具雖然提供了統一的賬號、權限管理功能,讓我們能夠統一管理所有的團隊製品,但隨着企業產品規模的擴大,集中在一起的製品如何劃分管理權限成爲了問題。比如這時一旦有新的項目誕生,或者臨時項目、外包項目出現,製品管理員就需要重新爲整個企業的用戶組,配置這些新項目的各種權限;沒有項目隔離的製品管理也會產生安全問題,這將給運維團隊帶來很大的負擔,讓製品管理成爲 DevOps 流程加速的瓶頸。

當我們解決了前面兩點製品管理的單點問題後,新的問題來了:由於製品管理承上啓下的屬性,需要和上下游的工具進行信息與功能調用的集成。很多企業在 DevOps 的每一環選擇了不同的工具,那麼就會需要進行若干次的集成與對接。許多企業選擇購買如國外的 Azure、Gitlab, 或者國內的 CODING DevOps 這樣的一站式產品來解決多次集成的問題,好不容易打通 DevOps 工具鏈,但是又出現了新的問題。

我們在面對很多私有化的客戶時,都提到了對於製品安全掃描功能的需求。無論是出於國家安全監管規定,還是企業自身的信息安全訴求,DevSecOps 的概念出現了。

有的客戶購買了 Black Duck、Checkmarx 這樣功能強大的安全工具,可以掃描出各種漏洞,並提供多維度的統計報告,但是這個報告只停留在安全工具系統中,最多可以展示在 Jenkins 的插件中。如何把這些漏洞拆分到對應的項目團隊去解決,爲這個報告找一個負責人,並且追蹤報告內漏洞的解決情況?這些工具其實都沒有提供解決方案。這是安全工具和 DevOps 工具鏈割裂而造成的問題,同時因爲這樣的割裂,我們很難建立起一個自動化的管控流程來限制安全問題的右移。

還有一個關鍵問題是這些安全工具掃描出的漏洞很難被修復。我們無法迴避大多數研發團隊的安全能力都是有限的這一現狀,可能一個團隊有 100 個研發,只有 1 個安全人員,他無法兼顧到整個團隊引入的安全問題。並且目前安全工具提供的漏洞信息和解決方案還是相對專業,可能一個普通的開發都難以理解安全軟件提供的修復建議,他按照建議進行了修復,其實也沒有比他更專業的人員去驗證結果,而英文信息也加大了這一過程的難度,因此修復安全漏洞比發現漏洞難得多。

圍繞這些層層遞進的痛點,我們希望提供給用戶一套完善的製品管理解決方案,因此誕生了企業級製品管理服務——「WePack」,接下來我將爲大家介紹 WePack 的設計理念。

我們在設計 WePack 時,首先考慮的便是製品管理最基本的痛點——集中管理的問題。我們希望 WePack 不單是做到製品類型的統一,還可以統一管理企業內部自研的第一方構建包、第二方的平臺基礎製品包、以及來自外網的第三方開源組件,保證自研製品在研發、測試、發佈的生命週期信息得到記錄,而第三方製品的來源與使用信息都可以在 WePack 系統中追溯,以此建立起企業唯一的可信製品來源。

同時,由於企業製品管理對於精細化權限、項目資源隔離的訴求,WePack 沿用了 CODING 經過用戶驗證的權限管理體系。普通的製品管理工具,比如 JFrog Artifactory、Nexus 的用戶管理體系。企業下若干個項目組共享所有制品資源,製品僅通過倉庫隔離。面對擴張的項目管理需求,用戶就需要靠增加節點來實現項目權限隔離。最近這些工具也意識到了多項目管理的問題,推出了 Project-based 的產品能力,但項目的個數卻受到付費等級的限制。WePack 繼承了 CODING 項目的管理層級,爲用戶提供了命名空間的管理層級,命名空間也可以理解爲項目或者研發團隊,可以用於管理不同的用戶組,給這些用戶配置不用的製品操作的權限。系統內的用戶可以隨時加入或退出命名空間,且命名空間的個數也沒有限制,企業因此無需擔心臨時項目和外包項目的管理成本。

WePack 目前的權限粒度精確到了倉庫層級,企業管理員可以通過設置倉庫可見範圍和用戶組,對指定倉庫的製品操作權限實現精細化的控制,滿足企業複雜的權限管理訴求。我們同時也在規劃將這一權限粒度再細化到製品層級。

介紹了 WePack 基本的設計理念後,可能有些熟悉 CODING 的朋友會產生一個疑問,無論是公有云還是私有部署版的 CODING DevOps 中已經有了製品管理這一個模塊,爲什麼還要單獨設計一款私有化場景下的製品管理單品系統呢?我們主要有以下三個方面的考慮。

首先,CODING 製品管理可以幫助用戶實現基本製品管理功能,連接上下游 CI/CD,彙集信息,打通整個 DevOps 流程。而對於軟件開發、測試、生產等多環境隔離的用戶,他可以選擇部署多套 Wepack 在多個環境,通過製品同步功能將各個環境打通。或是製品需要分發到多個地域的用戶,在每個環境或是地域部署一套 CODING 顯然是不合適的,而 WePack 可以幫助他們實現各個環境、地域的製品集中管理。

另一方面,許多用戶如果已有自建的 DevOps 工作流,WePack 也能提供很好的開放能力,幫助用戶將製品管理模塊和自建的工具便捷打通,實現信息的匯聚。

最後,製品其實和代碼一樣,是企業的核心資源,無論是公有云還是私有云,都可能需要這樣的一套系統,在相對隔離的環境單獨存儲製品資源。

接下來我將會詳細介紹 WePack 的功能設計。首先是一些製品管理的基本功能:WePack 目前已經基本覆蓋了主流的製品類型,可以實現多種類型的製品統一管理。並且不同於市面上大多數製品管理工具只提供製品文件結構信息,WePack 還展示了製品自帶的描述、標籤、大小、Readme 等元數據信息,在製品被推送到 WePack 中時,就能展示製品信息。在製品的版本管理上,用戶可以通過靈活的版本管理策略,設置製品版本是否可以被覆蓋。在第三方依賴包的管理功能支持上,WePack 提供了製品代理功能,可以將外網的公共製品代理到系統內,配合製品掃描的功能保證開源組件的安全性和可操作、可追溯。

對於上文提到的多環境、多地域的管理訴求,我們提供了製品同步功能來實現製品的跨環境、跨地域流轉。製品同步功能支持將系統內的製品推送到遠程倉庫,也可以將遠程倉庫的製品拉取到本地倉庫中。詳細的實踐案例將會在後文說明,也可以加深對該功能的認識。

WePack 支持靈活對接各種對象儲存產品,也支持用戶對老舊制品進行清理,釋放儲存空間。值得一提的是我們已經支持了 Docker 版本的不停服物理刪除。

最後一個基本功能是製品掃描。我們在掃描能力上選擇了和騰訊安全的專業團隊進行合作,由他們提供不同的安全底層能力的支持,這使得我們的安全能力具備很強的準確性與專業性,滿足對安全有較強訴求企業的製品管理需求。

這是 WePack 的基本功能,接下來我將介紹 WePack 在 DevOps 工作流上的一些應用。WePack 除了元數據外,還提供了製品屬性的功能,任何信息,例如代碼、Commit、構建環境信息、測試是否通過信息、質量檢查信息等都可以被記錄到製品中。同時 CODING 的製品推送插件,除了可以幫助用戶通過 CODING CI 將製品推送至 WePack 製品倉庫中,還會自動將構建環境中的信息寫入製品管理系統中,同時我們也提供了 Jenkins 插件來支持該功能。

那麼提到質量管控的流程,無論是 CODING 中的製品管理還是 WePack 系統中,我們都開通了製品掃描模塊,用於當前環境開源組件的漏洞掃描。我們在製品掃描功能中,加上了流程管控的能力,可以在掃描結果出來的當時就禁止有問題製品的下載,這樣便只有安全的、通過檢查的製品纔可以流入下一個環節。此時如果開發發現依賴的組件拉取失敗,就可以追溯到失敗原因,去解決有問題的製品。得益於我們打通了漏洞的發現與製品流動的流程管控,可以實現有效地管控安全問題的右移。

在製品的質量、安全職責的問題上,我們避免了將製品掃描這個功能獨立於 DevOps 流程之外,而是隸屬於整個 WePack 團隊/項目的管理層級。我們可以給一個命名空間的項目組,或者一個製品倉庫配置一個掃描方案,也可以基於一些篩選規則配置一個掃描方案,製品的負責人便可以只關注他權限範圍內的製品漏洞結果,做到誰的問題誰來解決。

那麼我們在功能設計上,如何幫助研發團隊更好更方便地去修復安全漏洞?首先在漏洞信息中,用戶可以定位到漏洞所屬的依賴組件,通過我們提供的依賴分析功能,用戶可以找到有問題的組件被哪些生產製品所依賴,以此去定位修復漏洞入口。同時爲了避免開源漏洞不準確、商業用戶缺乏中文支持、信息不夠透明等問題,我們與騰訊安全以及聯合實驗室進行了合作,騰訊安全的專業運營團隊基於通用的安全漏洞庫進行了安全研究,也會將他們的研究成果貢獻至例如 NVD 之類的開源漏洞庫中。根據他們的研究成果,騰訊安全建立了一個自研的軟件開源漏洞特徵庫,大幅降低了漏洞的誤報率,同時提供了中文的漏洞信息、漏洞組件修復版本信息等等。

我們的製品掃描引擎在解析出製品依賴後,會訪問漏洞庫的服務,輸出製品掃描報告,然後再寫入 WePack 系統中。在優化漏洞信息後,我們希望避免用戶一次性關注到太多不重要的漏洞,因此定義了漏洞的修復優先級。除了像 CVSS 提供的安全等級,騰訊安全還結合了漏洞的動態安全等級,也就是說現在是否有公開的漏洞利用 POC 披露,來定義該漏洞現在是否優先推薦用戶修復。這樣用戶可以去優先關注真正對研發環境有威脅的漏洞並進行修復。以上便是 WePack 的基本功能。

接下來我將用兩個案例來演示 WePack 的落地實踐。首先是在金融行業的落地實踐案例。該客戶有很強的管控規定,希望他的研發環境不能訪問外網,但是又希望能代理外網的一些開源組件,所以我們幫助用戶建立了一個網絡隔離區,在其中部署 WePack。開源組件可以從這裏代理到網絡隔離區的 WePack 系統中,並在此處被掃描,通過掃描的製品才能進入研發測試環境。同時客戶在其生產環境也部署了一個 WePack,與其他環境相隔離,通過我們提供的製品同步功能,使其在研發測試環境產生的可以被髮布的製品,能夠被推送至生產環境進行發佈。

第二個案例是在遊戲行業,該客戶的遊戲軟件包需要分發到多個地域,因此我們幫助他們在海外的多個節點部署了 WePack,通過製品同步的分發功能,他們生產的製品包可以被分發到多個 VPC 裏的 WePack,通過不同 VPC 的生產集羣去拉取製品進行跨地域部署。

以上便是兩個具體客戶的落地案例。關於 WePack 的未來規劃,主要分爲兩個方面:首先在安全管控能力上,我們希望能提供給用戶更細粒度的權限管控能力,能夠幫助用戶實現資源粒度的權限控制。同時我們也會繼續深化安全能力合作,不斷提升製品安全檢測與管控能力。第二點是我們希望能夠將信息收集和打通功能做得更加完善,讓 WePack 與企業的研發管理訴求相結合,中轉研發 - 構建 - 質檢 - 發佈信息流。同時我們也會提升上下游工具和部署平臺兼容能力,滿足企業的多樣化工具鏈與多種部署需求。

點擊即可觀看 CIF 峯會回放

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章