软件持续交付速度提升40%！揭秘 DevOps 的制品管理秘籍

近年来，混合云、多云正逐步成为企业用云的主流模式。据 IBM 的调查报告显示，仅截至2021年，采用混合云、多云战略的企业就已经接近80%。混合云、多云战略的确能够增加企业资源配置的灵活性，但也给持续交付带来了更大的挑战。在软件发布频率持续增长趋势下，如何将版本快速分发到多个环境中去，成为令不少开发者头疼的问题。 近日，**亚马逊云科技联合 JFrog 举行了《DevOps 实践：混合云模式下软件单一可信源的建设方法》**为主题的 Tech Talk，**JFrog （中国）技术总监王青**与大家分享了解决该问题的独特思路。 # 01 现有的制品库正在阻碍你的快速发布 IDC 研究报告显示，到2024年全球 APP 数量将达到 520M；2025年后，超过60%的企业每天都将进行版本发布，甚至更快。在如此之快的版本构建需求下，现有的统一代码库、统一持续集成再进行不同环境分发的制品管理方式往往存在一定的局限性。 这些局限性主要体现在研发团队面临着 Nexus 开源版私服宕机无人维护、开源组件漏洞被引入等问题；测试团队无法清晰地了解版本质量信息，同时测试报告也无法准确进行关联；运维团队在面临宕机问题时候缺乏商业技术支持，缺乏高可用和容灾；在此管理模式下，一旦发生问题，安全团队很难快速发现漏洞、对问题进行定位，因此也很难做到及时响应。  面对诸多问题，王青提出，建立软件单一可信源对于企业来说是至关重要的。单一可信源是指企业内部单一的，合规地存放所有软件的仓库，包括 war 包、Docker 镜像、zip 包等，以及第三方开源组件或者商业软件的授权版本和软件物料清单（SBOM）。 ## 02 为什么要建立软件单一可信源 建立唯一可信源的制品管理流程后，只需要不断将版本从开发流水线的 CI 服务器里建立晋级，一路晋级到生产环境的制品库，再由生产环境的制品库推送到多云环境中去。对于大型企业来说，通常会有多种云的技术栈，多种语言包都需要构建。通过制品库统一构建，把版本统一上传到 DEV 本地仓库做本地的集成测试，当开发者测试没有问题后，版本会晋级到 Test 仓库供测试来测，此后版本会进入性能和稳定性检测的环境，最终进入到生产环境的仓库中。  按照这种制品的晋级流程去建设会大大提高软件交付的效率。JFrog Artifactory 遵循的正是这样一套流程。它是支持29种语言包的制品仓库，Maven 包、NPM 包、Docker 镜像、ZIP 文件等多种通用文件都可以进行存储。 据王青介绍，JFrog 曾有一个国内大型手机制造商客户，每天单集群数据增长 20TB 左右，共有10多个集群。JFrog 和他们一起在研发测试区搭建了本地 Artifactory 集群，支持高并发的上传和下载，通过5-6个 Artifactory 节点来作为高可用集群提供服务。 这种方案相比传统的需要搭建一个 Nexus 开源版作为 Docker 镜像，再搭建一个 Nexus 开源版作为 Maven 仓库，Maven 仓库可能还要管 NPM 的技术方案，这种方案投入人力成本更低且能够提供更高的可用性。对于有多套环境的大型企业来说，软件单一可信源建设的优势就更加明显了，因为多套环境维护成本会线性增长。 # 03 混合云模式下单一可信源的建设方法 软件单一可信源的建设有助于企业降本增效，提升软件制品的构建速度，那么该如何构建软件单一可信源呢？王青谈到了一种区别于传统开源方案的独特方式。 在公司建设软件仓库的单一可信源时，最基本的是要保证它的高可用性。高可用有两层含义：一是零宕机，二是能够支持高并发的负载。Artifactory 对于生产环境的部署，天然的支持私有云和公有云的一键部署，并且提供实时推送功能。相比较来说，Nexus 开源版是没有推送功能的，因此也就没办法实现将本地构建的版本推送到多个私有云或者多个公有云上去。 假设公司的制品数量级已经达到百万级甚至是千万级，该如何应对这种大规模的读取和写入呢？JFrog 引入了两个概念，一个是读缓存层，一个是写缓存层。这是区别于开源方案的一个很重要的产品功能设计点。Nexus 开源版是没有缓存这个概念的，拉取的时候会去本地查询文件存在与否，这样的问题是，当服务读取操作系统文件的时候，操作系统文件是要耗时的，如果文件块在物理上存储的力度比较分散，实际查询效率会很低。 JFrog 在 Artifactory 服务器上添加了一个叫 SSD 的缓存层，通过这个缓存层能够快速读取一些热数据返回给用户。这个设计遵循的是 LRU 的算法，会保持 500G 左右的热数据。除了读缓存，JFrog 还引入了写缓存。因为在将文件上传到服务器上的时候，是先上传到服务器的某一个目录，再通过一个进程写到存储里，有了这个设计，只要把文件成功上传到目录即可创建成功，大大减少了客户端返回的请求时间, 而后端只需建立一个异步任务，把文件存储进去，再把存储目录删掉即可。为了减少存储的压力，JFrog 还设计了冗余同步，能够让用户去配置冗余数量，如上传一个文件时用户要冗余两份，Artifactory 就会把文件从 a 冗余到 b 去，通过轮询拿到热数据返回，从而提高效率。  综上所述，高可用性是建立软件单一可信源的基石。尤其是当客户的数据量超过几千万时，如果都保存在存储中，查找的效率就会非常低。在存储方面，JFrog 也进行了优化。GIT 文件存储是按照 checksum 的前两位，以目录的方式去存储每一个文件，所以 GIT 能高效地存储代码仓库里面上百万、上千万的文件，这依托的是文件索引的设计。当用户寻找某一个文件的时候，它会先以索引的方式定位到文件在哪个目录，在目录里面再去辨别。相当于建立了树状的结构，因此查询效率会更高。当数据量增大后要提升效率肯定还是需要依赖数据结构，通过每种场景应用不同的数据结构提升效率。 完整的高可用服务能够保证制品库建设单一可信源，但可信性又该如何保证呢？让制品库变得可信就涉及到安全相关的问题。尤其在面对海外用户时候，面临的最大挑战不是软件发布效率瓶颈，而是安全问题，特别是部署到公有云上的时候。在整个程序的冰山上，代码就是冰山一角，底层有很大的 API 接口、依赖包，还有底层的基础镜像，下面会存在很多开源组件，其中客户提到最多的就是漏洞爆发之后哪些应用将受到什么样的影响，应该修复到哪个版本？ 对于上述问题王青认为，现在开源软件比较多，但真正用起来会存在很多问题。如恶意依赖注入、注入恶意二进制或者代码实现勒索等。为此，JFrog 的产品中特别增加了漏洞扫描的功能。当发现漏洞时，JFrog 是如何快速定位，然后下线这些服务的升级版本的呢？这需要精准定位的能力。 传统的扫描会扫出很多漏洞，缺乏跨语言的依赖，比如无法定位到哪一个 Docker 镜像被 Log4j 污染。JFrog 通过 SCA（software component analysis）来进行漏洞扫描，此外还对某些语言包如 Docker 镜像进行密钥探测，包括上下文分析。扫描出漏洞之后，传统的厂商只会告诉用户有哪几个漏洞，而 JFrog 则会告诉你每个漏洞的评分分别是什么以及该漏洞的影响范围。 单一可信源建设要做的不仅仅是扫描，还有治理，对于扫描出的漏洞进行跟踪并精细化管理；安全部门要做的是定义规则，定义策略。公司内部一般有两个概念，一个是漏洞，一个是违规，漏洞是事实，而违规是公司策略。安全部门要定义哪些级别的版本属于违规，而开发者只需要去修复违规就可以了，不用管所有的漏洞。 因此，Artifactory 设计了两个维度的管理，一个是根据团队或者软件版本进行扫描，定位到某一个团队。另一个是按照部门去修复，不同部门的安全策略可能是不一样的，所以可以根据不同部门创建 Project 进行扫描和漏洞修复，从而实现有效的漏洞治理。 以上介绍的是在单一私有云或者公有云环境下的处理方式，如果要把私有云的制品同步到公有云上，JFrog 是如何做的呢？ 这就涉及到 JFrog 另一个功能——制品的双向同步。通过双向同步能力，借助于亚马逊云科技的 PrivateLink 开设私有网络。只要开了 Link 之后，私有云的制品仓库就能直接推到云上的 VPC 上去，自动复制到不同的 Region，实现制品液体般的流动。  除制品的双向同步之外，JFrog 还提供统一认证的功能，使云上云下保持一致。通常来说，云上的用户和云下的用户的账号是不能复用的，比如云上用账号 a 登录，云下就要用账号 b，这样用户就需要维护两套账号，导致用的人越多，账号维护的成本就越高。但是，Artifactory 实现了联合身份认证。只要在集群 a 创建用户，它会自动把用户信息同步到集群的每一个节点，用户在云下怎么登录，在云上按照同样的方式登录即可。这个功能特别适合多云环境进行软件制品的传输，能够极大节省公网带宽，提高发布速度，降低成本。 # 04 轻松建立可信发布流程的实践案例 某大型跨国银行，需要进行云迁移，实现应用上云。他们采用的方案是本地的关键数据库加上存储，到云上直接使用云数据库加上 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 云存储，应用直接迁移到 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail)，[Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 的使用极大的降低了运维成本。在整个数据迁移的过程中，JFrog 有专门的工具把本地的 Artifactory 制品通过一个脚本直接传到云上的 Artifactory，这种持续的传输实现了业务的零中断，并能将构建速度提升了30-40%。  软件制品从本地推到云端会用到一个叫 Internal Gateway 的 VPC 。亚马逊云科技在2022年 re:Invent 上最新发布的一款名为 [Amazon CodeCatalyst](https://aws.amazon.com/cn/codecatalyst/?trk=cndc-detail) 的 DevOps 端到端工具，包含需求设计、issue 管理、构建等一系列功能，用户可以通过 [Amazon CodeCatalyst](https://aws.amazon.com/cn/codecatalyst/?trk=cndc-detail) 进行构建，构建完成后把版本上传到某个 [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) , 并且能够和 Artifactory 制品库进行集成。  集成方式如上图所示，用户的代码 Commit 后到 GIT 仓库就能触发 [Amazon CodeCatalyst](https://aws.amazon.com/cn/codecatalyst/?trk=cndc-detail) 构建，构建时通过 JFrog 的 CLI 命令行工具连接到 Artifactory 做远程依赖 PublicRepo 的下载，下载时会触发漏洞扫描，扫描完成后进行晋级，分发到多种云，用 IoT 设备进行更新。整个编排过程由 [Amazon CodeCatalyst](https://aws.amazon.com/cn/codecatalyst/?trk=cndc-detail) 进行负责，并能够和 Artifactory 无缝集成，从而实现轻松地规划、开发、写作、构建和交付应用程序。 **3月29日，亚马逊云科技将联合 Jina AI 举行《开启智能文档问答新纪元：GPT-3模型的应用》** 为主题的 Tech Talk，**Jina AI 联合创始人兼 CEO 王楠**将与大家分享解决该问题的独特思路。   扫描上方二维码，即刻报名参加 也欢迎点击【阅读原文】查看往期活动盛况