聊聊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安全事件带来的一系列风险；
作为实践者，在制品的管理上需要结合组织和流水线需要，指定相应的规范，避免混乱；
好的制品管理流程，可减少开发自测和测试人员进行接收测试衔接过程中的低效沟通；

这里仅仅是对制品管理做了全局的梳理，后续会对其中具体的知识点进行详细介绍。