写点什么

WePack —— 助力企业渐进式 DevOps 转型

作者:CODING DevOps
  • 2021 年 12 月 08 日
  • 本文字数:5085 字

    阅读完需:约 17 分钟

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 峰会回放



用户头像

CODING DevOps

关注

还未添加个人签名 2018.04.23 加入

涵盖了软件开发从构想到交付的一切所需,助力企业实践敏捷开发与 DevOps,提升软件交付质量与速度。

评论

发布
暂无评论
WePack —— 助力企业渐进式 DevOps 转型