聊聊DevOps制品管理-不止是存儲制品這么簡單
什么是制品？
制品是指由源碼編譯打包生成的二進制文件，不同的開發語言對應著不同格式的二進制文件；這些二進制文件通常用于運行在服務器上或者作為編譯依賴,“制品的管理”是配置管理的重要組成部分。
?
通常，這些組件是各種文件的存檔，包括：類文件中的Java字節碼、C對象文件、文本文件、二進制文件。組件的多種格式，例如：Java JAR，WAR，EAR格式；普通ZIP或.tar.gz文件；其他軟件包格式，例如NuGet軟件包，Ruby gems，NPM軟件包；可執行文件格式，例如.exe 或.sh 文件，Android APK文件，各種安裝程序格式。
?
按照使用場景，制品大致分為三類
- 外部引入的第三方組件
- 產品內部依賴包，公共SDK
- 產品交付安裝包
按照開發語言，制品類型包含以下類型：
- Generic File 指的是通用文件類型的制品。
- Docker
- Maven
- npm
- PyPI
- Helm
- Composer
- NuGet
- Conan
為什么要制品管理？
- 外部依賴下載慢
- 影響研發構建速度
- 版本管理混亂 （svn,ftp）
- 交付包使用FTP或者SVN進行管理，管理粒度相對較粗；在這種粗放式的制品管理方式下，不同類型包的存儲與獲取是一件頭疼的事情，版本追蹤極其混亂，團隊協作也是障礙重重。
- 由于受到監管約束，一鍵部署是不可能任務，跨網段的包交付智能依賴于手工拷貝
- 安全漏洞風險
- 依賴組件越多，引入漏洞的風險也越高
- 第三方依賴包下載管理混亂，沒有準入管控
- 漏洞藏的越深，修復漏洞所花費的時間就越長
- 制品存儲風險
- 團隊內部搭建的制品庫是單點的，缺乏集群部署
- 資源浪費
- 因為沒有統一的制品庫，存在重復建設的問題；維護成本高，或者說目前根本就沒有維護
制品和CI/CD流水線
對于CI/CD流水線而言，制品起到一個承上啟下的關鍵作用，它是持續集成CI的終點，同時也是持續交付CD的起點。
?
如果缺乏有效的制品管理策略和工具，根本不可能建立高效的流水線；脫離制品管理，每次只能重新從代碼開始構建，對于任何企業組織是不可接受的，同時也不符合“一次構建，多次使用”的原則。
?
在整個研發過程中，制品對于測試人員和運維人員至關重要，他們關注的是怎么拿到需要的版本進行測試和部署，如果缺乏有效的制品管理，整個DevOps價值流就會出現銜接上的問題。你可能會碰到這種情況，測試同學會通過各種方式去詢問那個版本可以測試，包在哪里等情況。
?
包的元數據
何為包的元數據？別人給你一個包，你怎么知道包里包含了哪些需求缺陷變更，包含了哪些代碼提交，還有包的md5,hash等信息。這些信息對于測試人員追蹤問題的引入，后續改進，版本回歸至關重要，通俗點說，弄清楚制品的前世今生。
?
那么這些信息哪里來？當然是持續構建CI流水線，需求，代碼提交都可以通過CI流水線收集。如果你的組織購買過Jfrog的產品，會發現這個特點在的它的平臺上尤為突出。
?
制品的晉級
?在開發實踐中，大多數團隊會準備DEV, TEST, UAT, RELEASE等不同的環境，相應的建設不同的流水線，將制品部署到不同的環境前都會對制品進行不同的測試，所里這里也衍生出來了制品的晉級，就是給制品設置不同的準入門禁。
綜上所屬，制品和CI/CD流水線有著緊密的聯系，不可分割，在設計流水線時候要考慮好制品的使用場景。
制品管理工具
?
如上所述，由于制品管理的重要性，所以衍生出來對應的制品解決方案用來統一管理不同格式的軟件制品。 除了基本的存儲功能，還提供了版本控制、訪問控制、安全掃描、依賴分析等重要功能，最終建立“單一可信源”，是一種企業處理軟件開發過程中產生的所有包類型的標準化方式。
目前主市場上主流的制品管理工具主要有以下幾種：
Nexus
Nexus是一套“開箱即用”的系統不需要數據庫，它使用文件系統加Lucene來組織數據。Nexus 使用ExtJS來開發界面，利用Restlet來提供完整的REST APIs，通過m2eclipse與Eclipse集成使用。Nexus支持WebDAV與LDAP安全身份認證。
?
Nexus是少有的支持幾乎所有主流制品格式，并且提供免費版的制品管理產品，這也是大多數中小公司的選擇，可以滿足大部分業務場景，但是，免費版不提供高可用方案。
價格參考： https://www.sonatype.com/products/pricing?topnav=true
由于Nexus在國內沒有代理商，所以大家對它的認知還有限，其實Nexus僅僅是sonatype產品解決方案的一種，提供對軟件研發周期的制品管理方案。
Jfrog Artifactory
Jfrog是一家以色列公司，專注于制品管理環境，提供商用的解決方案，所以它的產品是要花錢的。
下圖列出了Jfrog Artifactory和Nexus的產品特點對比，僅供參考。既然是掏錢買的，肯定比免費的Nexus提供的支持和服務更多，包括高可用，組件的漏洞風險分析，多地分發等等。不是說Nexus不行，而是我們大家用的大部分都是Nexus的免費版，其實它的收費版也提供類似的方案。
Harbor
Harbor是VMware公司開源的企業級Docker Registry項目，其目標是幫助用戶迅速搭建一個企業級的Docker registry服務。
?
基于官方 Registry V2 實現，提供了管理UI，基于角色的訪問控制(Role Based AccessControl)，AD/LDAP集成、以及審計日志(Auditlogging) 等企業用戶需求的功能，通過添加一些企業必需的功能特性，例如安全、標識和管理等，擴展了開源 Docker Distribution。
?
Harbor目前已經成為私有Docker/Helm管理的主要工具，相比于Nexus, Harbor在docker鏡像的管理方面更有優勢，提供鏡像同步服務，支持團隊項目隔離。在實踐過程中，筆者發現Nexus在docker鏡像的團隊隔離方面上，存在一些問題。
WePack
?
WePack是騰訊Coding基于之前的DevOps拆分出來的單獨的制品管理服務，支持私有化部署。也許也是看到單獨的制品管理工具，比大而全的DevOps平臺更好的切入用戶場景吧。
如何管理制品？
為了統一管理不同語言格式的包，以上制品管理工具幾乎都按照如下方式管理組織制品。
?
制品庫的層級關系為：倉庫 > 包 > 版本，每個層級描述如下：
- 倉庫：用于管理不同類型的倉庫和倉庫下的包資源，可以設置倉庫對外的訪問權限。
- 包：構建產物對外提供訪問的基礎單元，用于介紹當前構建產物的用途和使用指引。
- 版本：列出某個包下的所有構建產物，詳細記錄了每次構建產物的版本迭代更新變化。
規范制品庫命名
如果團隊比較大一，對制品管理的要求不高，按照以上方式基本可以滿足需求。但是，如果建設公司級別的需要規范一些命名，如下所示
制品版本號規范化
制品的版本號用于標記特定制品，通過規范化命名有助于自動化腳本的編寫和流水線的復用。
制品庫權限規范化
不管是基于開源工具，還是自研工具，基于制品倉庫的權限設計也是必要的，做到團隊產品的隔離。
開源制品的安全風險
對于制品的管理，大多人數都停留在僅僅是存儲，拉取使用的想法，筆者今年前也是這種思維。2021年末的Log4j2的安全事件，引起了整個IT圈的軒然大波，這個開源組件幾乎涉及所有的java應用，每個公司不得不緊急排查自己產品是否引入該風險。
?
通過該事件，讓我們開始關注開源組件可能存在的風險，這也是目前比較熱門的研發過程中的“供應鏈安全”，也是DevSecOps其中重要的一個環節。
作為研發過程中的制品管理，引入階段的審核機制，使用中的安全，越來越成為大家關注的熱點。如果所示，組織需要引入組件審核制度，杜絕開發人員隨意的拉取互聯網的開源制品，并且建立實時的漏洞掃描機制，形成組織級的白名單倉庫。
SBOM-軟件物料清單
現代軟件主要是使用第三方和開源組件組裝而成的，它們以復雜而獨特的方式融合在一起，并與原始代碼集成以實現所需的功能。除了通過在開源組件引入階段加入安全審核機制，IT企業往往也需要關注自己開發或使用的軟件產品的組成，像我們在超市購買食品時在食品包裝上看到的食品配料清單，標注了所用的所有材料。
為了準確摸清軟件所含組件的情況，SBOM（即：Software Bill Of Materials）應運而生，其包括多種關鍵信息，如：組件名稱、版本號、供應商等，這些關鍵信息在分析軟件安全時發揮著關鍵作用。通過這些信息，可以追溯軟件的原始供應鏈，極大提高開發者對其所用軟件安全風險的理解，幫助企業在網絡安全風險分析、漏洞管理和應急響應過程中提高效率。
?
對軟件開發企業而言，SBOM可有效控制開源組件風險，幫助企業更早識別并消除開源組件安全缺陷和許可風險；對軟件采購企業而言，SBOM可幫助采購決策者輕松了解開發方軟件是否存在開源組件風險；對軟件開發人員而言，SBOM可幫助開發人員全面準確掌握其所研發軟件的開源組件情況。
總結
- 制品管理是DevOps實踐過程中的重要環節，起著承上啟下，收集過程信息的重要角色；
- 于此同時，制品的引入使用會存在安全風險，組織需要關注這一點，避免類似Log4j2安全事件帶來的一系列風險；
- 作為實踐者，在制品的管理上需要結合組織和流水線需要，指定相應的規范，避免混亂；
- 好的制品管理流程，可減少開發自測和測試人員進行接收測試銜接過程中的低效溝通；
這里僅僅是對制品管理做了全局的梳理，后續會對其中具體的知識點進行詳細介紹。
浙公網安備 33010602011771號