AngusRepo：企业级多格式制品仓库 | 统一管理 Maven/Docker/npm 等 10 种格式

研发团队常面临这样的困境：Java 项目的 JAR 包、前端的 npm 依赖、容器镜像、Helm Chart 分散在不同服务中，每一种格式都需要单独配置仓库地址、访问凭据和缓存策略。内部组件靠文件传递，公共依赖重复下载，制品权限和安全信息难以统一管理。

AngusRepo 提供统一的企业级制品仓库平台，在一个系统中管理 Maven、Docker、npm、PyPI、NuGet、Helm、Go、APT、YUM 和 Raw 等 10 种格式，让制品有明确的存放位置，依赖有稳定的获取入口，发布和治理更容易纳入团队流程。

AngusRepo 是什么？

AngusRepo是 AngusKit 套件中的企业级多格式制品仓库管理系统，用于统一托管、代理、分发和管理软件制品。它支持 10 种主流制品格式，并通过标准协议与开发者常用的构建及包管理工具无缝协作。

• 10+ — 支持的制品格式
• 3 类 — 仓库类型：托管/代理/聚合
• 统一 — 平台管理与安全治理

对研发团队而言，AngusRepo 不只是一个上传文件的地方。它连接了内部制品发布、公共依赖获取、版本分发、访问控制与安全治理等环节，帮助开发、构建、部署和管理人员围绕同一套制品来源开展工作。

AngusRepo 与其他方案的定位

作为 AngusKit 生态的一部分，AngusRepo 与 AngusGit（代码仓库）、AngusGM（项目管理）、AngusSecurity（安全扫描）等产品深度集成，为企业提供从源代码到制品交付的完整 DevOps 工具链。相比独立部署 Nexus、Artifactory 或 Harbor，AngusRepo 的优势在于：

• 统一身份与权限体系：与 AngusKit 其他产品共享用户、组织和权限管理
• 原生集成：无需额外配置即可与 AngusGit CI/CD、AngusSecurity 扫描等功能协作
• 简化运维：统一的部署、监控和升级流程，降低多系统维护成本
• 可选的云原生架构：支持容器化部署、水平扩展和高可用配置

功能架构一览

下图从产品功能视角展示 AngusRepo 的完整能力体系，涵盖从使用角色、客户端接入、制品格式、仓库管理、安全治理到 CI/CD 集成的全链路，以及典型的制品流转场景。

架构图说明

架构图按功能分为四个主要区域，展示 AngusRepo 的完整能力体系：

① 客户端与制品格式（左侧 · 绿色区域）

• 展示 10 种支持的制品格式，每种格式都有独立的卡片和说明
• 开发者使用熟悉的包管理器（Maven、Docker CLI、npm 等）和构建流水线接入
• 所有格式通过标准协议与 AngusRepo 通信，无需学习新工具

② AngusRepo 核心仓库（中间 · 橙色区域）

• 仓库类型：HOSTED（内部托管）、PROXY（代理缓存）、GROUP（聚合访问）
• 制品管理：仓库创建、版本浏览、访问控制、分析审计、REST API/Webhook
• 安全与合规：漏洞扫描、许可证分析、SBOM 导出、扫描策略配置

③ CI/CD 与生态协作（右侧 · 紫色区域）

• 与 Jenkins、GitHub Actions、GitLab CI 等主流 CI/CD 工具无缝集成
• 与 AngusKit 生态（AngusGit、AngusAI）深度协作
• 通过 REST API 和 Webhook 连接第三方工具和自定义流程

④ 典型制品流转（底部 · 黄色区域）

• 公共依赖获取：上游仓库 → PROXY 缓存 → GROUP 聚合 → 开发/构建拉取
• 内部制品交付：CI 构建 → HOSTED 托管 → 安全扫描 → 下游消费

💡 提示：架构图支持深色模式，会自动适配您的系统主题偏好。

核心能力：AngusRepo 能做什么？

1. 多格式统一管理

在一个平台中管理 10 种制品格式，团队可以按格式和用途规划仓库，而不必为每一种包或镜像都引入独立的管理流程。所有制品使用统一的权限体系、审计日志和存储管理。

2. 托管内部制品

通过 HOSTED（托管）仓库，团队可以存放自己构建和发布的软件包、镜像及其他制品，并按权限向开发者、CI/CD 流水线或下游环境提供访问。内部制品因此有统一、可追踪的发布位置，而不必依赖临时文件或个人机器传递。

典型使用场景：

• 发布内部 Java 组件库到 Maven 托管仓库
• 推送企业应用的 Docker 镜像供测试和生产环境拉取
• 托管团队开发的 npm 私有包供前端项目使用

3. 代理和缓存公共依赖

通过 PROXY（代理）仓库，AngusRepo 可以代理受支持格式的上游仓库，并缓存已获取的依赖。开发与构建流程由此获得统一的依赖访问入口，也能减少重复下载对外部网络的直接依赖。

主要优势：

• 加速构建：首次下载后本地缓存，后续构建无需重复从公网获取
• 提高稳定性：降低对外部仓库可用性的依赖
• 节省带宽：团队共享缓存，减少重复流量
• 离线支持：缓存的依赖可在网络受限环境使用

4. 聚合多源入口

GROUP（聚合）仓库可以按配置顺序查询多个成员仓库，让客户端通过一个只读入口获取来自不同来源的制品。它尤其适合将内部制品仓库与公共依赖代理组织成统一的拉取入口。

示例： Maven 聚合仓库可以依次查询内部 releases、内部 snapshots 和 Maven Central 代理，开发者只需配置一个仓库地址。

5. 安全与合规治理

AngusRepo 提供完整的制品安全治理能力：

• 访问控制：基于用户、组织和项目的细粒度权限管理
• 访问令牌：支持只读、读写、特定仓库范围的令牌，便于 CI/CD 集成
• 活动审计：记录所有制品的上传、下载、删除操作，满足合规要求
• 安全扫描：集成 AngusSecurity 对制品进行漏洞扫描和许可证分析
• SBOM 生成：自动生成软件物料清单（Software Bill of Materials）
• 生命周期管理：通过清理策略自动删除过期或不再使用的制品，节省存储空间

6. 与 DevOps 流程集成

• 标准协议支持：开发者继续使用 Maven、Docker CLI、npm、pip 等熟悉的工具，无需学习新命令
• REST API：完整的 API 支持自动化操作，如制品查询、版本管理、仓库配置
• Webhook 通知：制品发布、删除等事件可触发外部系统，如通知测试环境自动部署
• CI/CD 集成：与 Jenkins、GitLab CI、GitHub Actions、AngusGit CI 等无缝协作

支持的制品格式与仓库类型

AngusRepo 支持的 10 种格式覆盖了常见的开发语言生态、容器交付、系统软件包和通用文件。下表列出每种格式支持的仓库类型：

说明：

• ✓ 表示该格式支持该类型仓库
• ✗ 表示该格式不支持该类型仓库
• HOSTED（托管）：存储团队自己的制品
• PROXY（代理）：缓存上游公共仓库的依赖
• GROUP（聚合）：提供统一的多源查询入口（仅部分格式支持）

这 10 种格式各自保留对应生态的使用方式。研发人员仍可使用熟悉的命令行工具和构建系统接入，仓库地址、认证方式和格式专属配置则以相应的格式指南为准。查看完整格式使用指南。

三类仓库如何配合？

AngusRepo 以三类仓库组织不同的制品流转方式。它们各自承担不同职责，并非所有制品格式都同时支持三种类型。

以常见的 Maven 项目为例，团队可以把内部正式版本放在 maven-releases（HOSTED），把 Maven Central 配置为 maven-central（PROXY），再创建 maven-public（GROUP）供开发者解析依赖。开发者通过统一入口拉取依赖，CI/CD 则将新版本发布到对应的 HOSTED 仓库。

这类分工让“从哪里获取依赖”和“向哪里发布制品”变得清楚，也方便团队分别管理发布权限、依赖来源和版本策略。

典型应用场景：AngusRepo 解决什么问题？

1. 多语言团队的统一制品管理

场景： 某互联网公司使用 Java（后端）、React（前端）、Python（数据分析）和 Go（微服务），每种语言都有自己的依赖管理方式。

问题：

• 开发者需要分别配置 Maven、npm、PyPI、Go proxy 的仓库地址和凭据
• 不同仓库的权限管理各自独立，账号和令牌难以统一
• 缺少统一的审计和监控，无法全面了解制品使用情况

方案： 使用 AngusRepo 创建对应格式的仓库，统一管理所有制品。团队成员使用相同的身份体系访问不同格式的仓库，管理员通过一个平台管理权限、审计日志和存储配额。

2. 加速构建与提高稳定性

场景： 某企业团队位于网络受限环境，访问 Maven Central、npm Registry 等公共仓库速度慢且不稳定。

问题：

• 构建时反复从公网下载依赖，耗时长且容易失败
• 多个开发者和 CI/CD 节点重复下载相同依赖，浪费带宽
• 外部仓库偶尔不可用导致构建中断

方案： 配置 AngusRepo 的 PROXY 仓库代理上游公共仓库。首次下载后依赖被缓存在本地，后续构建直接从缓存获取，构建速度提升 60%，且不再受外部网络影响。

3. 内部组件库的规范发布

场景： 某研发团队维护多个内部公共组件库，供各业务线使用。

问题：

• 组件发布靠手动复制 JAR 文件到共享目录，版本管理混乱
• 没有正式的版本号和变更记录，下游项目不知道使用哪个版本
• 缺少访问控制，任何人都可以修改或删除组件

方案： 使用 AngusRepo 的 HOSTED 仓库托管内部组件。组件库通过 mvn deploy 发布正式版本，下游项目通过标准的依赖声明引用。配合访问令牌，只有授权的 CI/CD 流水线可以发布新版本，所有操作有审计记录。

4. 容器镜像的集中管理

场景： 某团队使用 Kubernetes 部署微服务，需要管理大量应用镜像和基础镜像。

问题：

• 应用镜像推送到 Docker Hub 公开仓库，存在安全风险
• 从 Docker Hub 拉取基础镜像速度慢，且受访问限制影响
• 缺少镜像的漏洞扫描和版本管理

方案： 使用 AngusRepo 创建 Docker HOSTED 仓库托管应用镜像，创建 Docker PROXY 仓库代理 Docker Hub。结合 AngusSecurity 对推送的镜像进行自动漏洞扫描，阻止包含高危漏洞的镜像部署到生产环境。

5. 符合合规要求的制品治理

场景： 某金融企业需要满足监管要求，对软件供应链进行全面审计和管理。

要求：

• 记录所有制品的来源、发布者和使用情况
• 定期扫描依赖的安全漏洞和许可证合规性
• 生成 SBOM（软件物料清单）用于合规报告

方案： AngusRepo 记录所有制品的上传、下载、删除操作，并与 AngusSecurity 集成进行漏洞扫描和许可证分析。自动生成 SBOM 文档，满足合规审计需求。配置清理策略自动删除过期版本，降低存储成本。

各类团队的适用性

快速开始：配置接入示例

Maven：发布和拉取 Java 制品

下面展示如何配置 Maven 项目使用 AngusRepo：开发者从统一仓库入口获取依赖，CI/CD 将构建产物发布到托管仓库。

1. 在 AngusRepo 中创建仓库

将 maven-releases 与 maven-central 加入 maven-public。

2. 配置 Maven 凭据

在 ~/.m2/settings.xml 中配置发布凭据。建议通过环境变量注入令牌，不要把实际令牌提交到代码仓库：

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <servers>
    <server>
      <id>angusrepo-releases</id>
      <username>${env.ANGUS_REPO_USERNAME}</username>
      <password>${env.ANGUS_REPO_TOKEN}</password>
    </server>
  </servers>
</settings>

3. 配置项目依赖和发布目标

在项目的 pom.xml 中配置：

<repositories>
  <repository>
    <id>angusrepo-public</id>
    <url>https://repo.anguskit.com/maven/maven-public</url>
  </repository>
</repositories>

<distributionManagement>
  <repository>
    <id>angusrepo-releases</id>
    <url>https://repo.anguskit.com/maven/maven-releases</url>
  </repository>
</distributionManagement>

4. 发布制品

mvn deploy

更多配置方式请参阅 [Maven 格式手册]。

Docker：托管和拉取容器镜像

配置 Docker 使用 AngusRepo 托管和拉取容器镜像。

1. 在 AngusRepo 中创建仓库

2. 登录到 AngusRepo Docker 仓库

docker login repo.anguskit.com

输入用户名和访问令牌（在 AngusRepo 用户设置中生成）。

3. 推送镜像到托管仓库

# 构建镜像
docker build -t repo.anguskit.com/docker-hosted/myapp:1.0.0 .

# 推送镜像
docker push repo.anguskit.com/docker-hosted/myapp:1.0.0

4. 从代理仓库拉取公共镜像

# 拉取 Docker Hub 的镜像（通过 AngusRepo 代理）
docker pull repo.anguskit.com/docker-hub/nginx:latest

5. 在 CI/CD 中使用

# GitLab CI 示例
stages:
  - build
  - push

build-image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - echo $ANGUS_REPO_TOKEN | docker login -u $ANGUS_REPO_USERNAME --password-stdin repo.anguskit.com
    - docker push repo.anguskit.com/docker-hosted/myapp:$CI_COMMIT_SHA

更多配置方式请参阅 [Docker 格式手册]。

npm：管理前端依赖

1. 配置 npm 使用 AngusRepo

# 设置 npm registry
npm config set registry https://repo.anguskit.com/npm/npm-public/

# 配置认证令牌
npm config set //repo.anguskit.com/npm/:_authToken YOUR_ACCESS_TOKEN

2. 安装依赖

npm install

3. 发布内部包

npm publish --registry https://repo.anguskit.com/npm/npm-releases/

更多格式的配置示例请参阅[完整格式使用指南]。

常见问题

Q: 如何生成访问令牌？

登录 AngusRepo → 用户设置 → 访问令牌 → 生成新令牌。可以指定令牌的权限范围（只读/读写）和有效期。

Q: PROXY 仓库如何处理认证？

如果上游仓库需要认证（如私有 Docker Registry），在创建 PROXY 仓库时配置上游凭据。AngusRepo 会在请求上游时自动使用这些凭据。

Q: 如何清理旧版本制品？

在仓库设置中配置清理策略，可以按以下规则自动删除制品：

• 保留最近 N 个版本
• 删除超过 X 天未使用的制品
• 删除特定版本模式（如 SNAPSHOT）的旧版本

Q: 支持匿名访问吗？

支持。可以在仓库设置中启用匿名读取，允许未认证用户拉取制品。但发布制品始终需要认证和授权。

与研发工作流协同

AngusRepo 可以作为构建和交付流程中的制品入口：

1. 开发阶段：开发者在本地解析依赖，从 PROXY 仓库获取公共依赖，从 HOSTED 仓库获取内部组件
2. 构建阶段：CI/CD 在构建完成后将制品发布到 HOSTED 仓库，触发 Webhook 通知测试环境
3. 测试阶段：测试环境从受控的仓库地址拉取对应版本的制品进行部署
4. 发布阶段：生产环境从审核通过的制品版本中拉取部署，所有操作有完整审计记录

配合权限管理、清理策略、审计与安全治理，团队更容易统一制品的流转方式，并持续维护可理解、可复用的交付流程。

实施建议： 对于已使用自动化流水线的团队，可以从 Maven、npm 或 Docker 等最常用的格式开始，验证基本流程后再根据项目与团队需求逐步扩展到其他格式。

原文地址：anguskit.com