在研发领域,制品库扮演着管理制品的关键角色。这里的制品是指由源代码经过编译与打包后生成的二进制文件,这些二进制文件因开发语言的不同而呈现出不同的格式。这些二进制文件通常用于运行在服务器上或者作为编译过程中的必要依赖项。通过制品库的高效管理,研发团队能够确保二进制制品的有序存储与便捷使用。
制品库根据其管理制品的类型,主要可以从两个维度进行分类:一是按照制品的开发语言、二是按照制品的使用场景。在图1中,展示了涵盖主流开发语言的大部分制品仓库,其中包括但不限于 Docker、Maven、npm、pypi、helm、composer、nuget、Conan等。
图 1 制品类型(网络图片,侵权删除)
图2深入展示了制品库在不同应用场景下的多样化运用。根据实际应用需求,行业内通常将制品库分为以下几类:
归档制品仓库(存放产品交付的安装包、流水线构建的通用文件等)
镜像仓库(归档云应用制品,docker 镜像、helm charts 等)
在实际运用三方依赖或官方镜像的过程中,开发者们往往会遭遇一系列棘手问题,这些问题不仅影响了研发效率,还带来了安全隐患。具体来说:
|
|
|
跨网段的依赖交付效率低下(有些地方通过手工方式拷贝);
|
|
依赖安全风险失控,没有准入原则,提升了后期漏洞修复的成本。
|
然而,这些问题在代理仓库的“魔法”都能得到妥善解决。让我们先通过图 3 看看代理仓库是什么。
代理仓库,在制品库中是一种特殊的仓库,其核心价值在于能够灵活配置代理多个源。当私有仓库内找不到所需包时,它会按照预设的配置顺序,自动从代理源中拉取并返回给用户。这一过程中,通过采用凭证管理,既保证了操作的便利性,又确保了数据的安全性。
引入仓库代理后,制品的拉取逻辑变得清晰而高效:
优先获取私有仓库内的包,系统会优先从私有仓库中查找并获取所需的包。
仓库无法找到时,再从配置的代理的源按照配置的顺序查找获取。
在代理仓库尚未融入研发流程之时,每个代码仓库或项目工程所需的三方组件,都要求研发团队逐一进行依赖仓库源的配置。这些配置的关系,在图4中得到了直观的呈现。
图 4 展示的是一种相对比较简单的依赖关系。有些复杂的项目工程,可能依赖的仓库源会是多个,那么就需要在项目中配置多个依赖源和不同的拉取策略。使用代理后,研发对项目的依赖配置会进一步精简,只需要在项目工程中配置代理仓库的信息即可。
使用了代理仓库之后,代理仓库凭借其高效的拉取策略,轻松解决了依赖拉取缓慢这一困扰研发团队的问题。同时,通过代理跨网段的仓库源,可以做到通过网络策略的方式保障网络可控的隔离且不影响依赖拉取的效率;最后,因为所有的依赖使用,都要通过代理仓库,这样可以在代理仓库中规划安全策略,来实现依赖安全风险的可控。所以,代理仓库处理了依赖管理的业务场景下一系列的经典问题。下面,我们通过一些典型场景,来体会下代理仓库的实际应用效果。
对于大多数的企业,不管 IT 团队的大小,都会有访问远程公共资源的的场景,例如:Maven Centra、Docker Hub、npmjs.org 等公共资源。然而,在利用这些宝贵资源的过程中,企业往往会遇到一系列挑战,包括:
针对上述的业务场景,我们可以基于代理仓库的能力,建设企业私服依赖库:DMZ 隔离区 + 多级代理的方案解决该场景下问题。
如图 5 中所示,业务区域,通过 DMZ 区实现与公共互联网环境的隔离。DMZ 环境与组织内部网络之间,通过网络策略连接。在 DMZ 区域,对拉取同步过来的依赖执行安全扫描,并实施安全策略,对于不满足安全要求的组件依赖,不允许其被拉取到业务生产区域使用。
基于这样的设计,中央仓库、DMZ 私服库、业务区域依赖库三者间,形成多级的代理。业务区域构建使用依赖,会优先从依赖库中拉取;在依赖库中不存在的情况下从私服库获取,私服库中可用的组件一定是满足安全要求的制品;DMZ 区私服库中不存在,则私服库会从中央仓库获取,获取后执行安全扫描的动作,不安全的依赖将会禁止内部网络使用。
在上述的网络结构和部署策略中,DMZ 区上的实例制品主要包括:
另外,业务区域(内部环境)依赖库中的实例制品,主要包括:
远程仓库代理了 DMZ 区域的仓库,以及其他类型的仓库。
在当前行业发展趋势中,各大企业愈发重视安全与效率的提升,代理仓库的能力以及仓库代理结合网络拓扑模型的应用已经越来越普遍,也越来越体现出其价值。仓库代理的能力已经无需过多论证,也有类似嘉为科技、腾讯、华为等各大厂商提出了各种企业级解决方案。亟需行业从业者们继续推广,放大其价值。
|