研发团队常面临这样的困境：Java 项目的 JAR 包、前端的 npm 依赖、容器镜像、Helm Chart 分散在不同服务中，每一种格式都需要单独配置仓库地址、访问凭据和缓存策略。内部组件靠文件传递，公共依赖重复下载，制品权限和安全信息难以统一管理。
AngusRepo 提供统一的企业级制品仓库平台，在一个系统中管理 Maven、Docker、npm、PyPI、NuGet、Helm、Go、APT、YUM、Raw，以及 Alpine、Cargo、Composer、Conda、RubyGems、Swift、Terraform 等 28 种格式，让制品有明确的存放位置，依赖有稳定的获取入口，发布和治理更容易纳入团队流程。
AngusRepo 是什么？
AngusRepo是 AngusKit 套件中的企业级多格式制品仓库管理系统，用于统一托管、代理、分发和管理软件制品。它支持 28 种主流制品格式，并通过标准协议与开发者常用的构建及包管理工具无缝协作。
- 28— 支持的制品格式
- 3 类— 仓库类型：托管/代理/聚合
- 统一— 平台管理与安全治理
对研发团队而言，AngusRepo 不只是一个上传文件的地方。它连接了内部制品发布、公共依赖获取、版本分发、访问控制与安全治理等环节，帮助开发、构建、部署和管理人员围绕同一套制品来源开展工作。
AngusRepo 与其他方案的定位
作为 AngusKit 生态的一部分，AngusRepo 与 AngusGit（代码仓库）、AngusGM（项目管理）、AngusSecurity（安全扫描）等产品深度集成，为企业提供从源代码到制品交付的完整 DevOps 工具链。相比独立部署 Nexus、Artifactory 或 Harbor，AngusRepo 的优势在于：
- 统一身份与权限体系：与 AngusKit 其他产品共享用户、组织和权限管理
- 原生集成：无需额外配置即可与 AngusGit CI/CD、AngusSecurity 扫描等功能协作
- 简化运维：统一的部署、监控和升级流程，降低多系统维护成本
- 可选的云原生架构：支持容器化部署、水平扩展和高可用配置
功能架构一览
下图从产品功能视角展示 AngusRepo 的完整能力体系，涵盖从使用角色、客户端接入、制品格式、仓库管理、安全治理到 CI/CD 集成的全链路，以及典型的制品流转场景。
架构图说明
架构图按功能分为四个主要区域，展示 AngusRepo 的完整能力体系：
① 客户端与制品格式（左侧 · 绿色区域）
- 图示意角色、三类仓库和制品流转。格式以正文表格的 28 种为准
- 开发者使用熟悉的包管理器（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. 多格式统一管理
在一个平台中管理 28 种制品格式，团队可以按格式和用途规划仓库，而不必为每一种包或镜像都引入独立的管理流程。所有制品使用统一的权限体系、审计日志和存储管理。
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 支持的 28 种格式覆盖了常见的开发语言生态、容器交付、系统软件包和通用文件。下表列出每种格式支持的仓库类型：
| 制品格式 | HOSTED | PROXY | GROUP | 典型用途 |
|---|---|---|---|---|
| Maven | ✓ | ✓ | ✓ | Java / JVM 项目的依赖管理、内部组件发布 |
| Docker / OCI | ✓ | ✓ | ✗ | 应用镜像托管、公共镜像代理及部署交付 |
| npm | ✓ | ✓ | ✓ | 前端依赖管理、内部 npm 包发布 |
| PyPI | ✓ | ✓ | ✓ | Python 项目的依赖获取与内部包分发 |
| NuGet | ✓ | ✓ | ✓ | .NET 应用的依赖管理与组件发布 |
| Helm | ✓ | ✓ | ✗ | Kubernetes 应用的 Chart 托管和分发 |
| Go | ✗ | ✓ | ✗ | 通过模块代理获取和缓存 Go 依赖 |
| APT | ✓ | ✗ | ✗ | Debian / Ubuntu.deb包托管与分发 |
| YUM | ✓ | ✓ | ✗ | RPM 系 Linux 环境的软件包分发 |
| Raw | ✓ | ✓ | ✗ | 安装包、二进制文件、压缩包及其他文件 |
| Alpine | ✓ | ✓ | ✓ | Alpine.apk |
| Ansible | ✓ | ✓ | ✓ | Ansible collection |
| Arch | ✓ | ✓ | ✓ | Arch Linux 软件包 |
| Cargo | ✓ | ✓ | ✓ | Rust crate |
| Chef | ✓ | ✓ | ✓ | Chef cookbook |
| CocoaPods | ✓ | ✓ | ✗ | iOS / macOS pod，不能建 GROUP |
| Composer | ✓ | ✓ | ✓ | PHP 包 |
| Conan | ✓ | ✓ | ✓ | C / C++ 包 |
| Conda | ✓ | ✓ | ✓ | Conda 包 |
| CRAN | ✓ | ✓ | ✓ | R 包 |
| Hugging Face | ✗ | ✓ | ✗ | 模型与数据集，只能建 PROXY |
| OCI | ✓ | ✓ | ✓ | OCI 镜像，与 Docker 共用/v2 |
| p2 | ✗ | ✓ | ✗ | Eclipse p2，只能建 PROXY |
| Pub | ✓ | ✓ | ✓ | Dart / Flutter 包 |
| RubyGems | ✓ | ✓ | ✓ | Ruby gem |
| Swift | ✓ | ✓ | ✓ | Swift package |
| Terraform | ✓ | ✓ | ✓ | Terraform module / provider |
| Vagrant | ✓ | ✓ | ✓ | Vagrant box |
说明：
- ✓ 表示该格式支持该类型仓库
- ✗ 表示该格式不支持该类型仓库
- HOSTED（托管）：存储团队自己的制品
- PROXY（代理）：缓存上游公共仓库的依赖
- GROUP（聚合）：提供统一的多源查询入口（仅部分格式支持）
这 28 种格式各自保留对应生态的使用方式。研发人员仍可使用熟悉的命令行工具和构建系统接入，仓库地址、认证方式和格式专属配置则以相应的格式指南为准。查看完整格式使用指南。
三类仓库如何配合？
AngusRepo 以三类仓库组织不同的制品流转方式。它们各自承担不同职责，并非所有制品格式都同时支持三种类型。
| 仓库类型 | 主要职责 | 典型用途 |
|---|---|---|
| HOSTED（托管） | 保存团队自己的制品，并提供授权访问 | 发布内部软件包、组件和镜像 |
| PROXY（代理） | 连接上游仓库并缓存获取到的依赖 | 集中访问公共依赖，减少重复下载 |
| GROUP（聚合） | 按配置顺序查询多个成员仓库，提供统一的只读入口 | 在格式支持时，将内部制品与公共依赖组织成一个拉取地址 |
以常见的 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 文档，满足合规审计需求。配置清理策略自动删除过期版本，降低存储成本。
各类团队的适用性
| 团队类型 | 主要收益 |
|---|---|
| 中小型研发团队（10-50人） | 快速搭建私有仓库，简化依赖管理，减少运维负担 |
| 多语言技术栈团队 | 统一管理多种格式，降低学习和配置成本 |
| 微服务与容器化团队 | 集中管理容器镜像和 Helm Chart，加速部署流程 |
| 企业级研发团队（50人以上） | 细粒度权限控制、审计、安全扫描，满足合规要求 |
| 网络受限或离线环境 | 缓存公共依赖，保证构建稳定性和速度 |
快速开始：配置接入示例
Maven：发布和拉取 Java 制品
下面展示如何配置 Maven 项目使用 AngusRepo：开发者从统一仓库入口获取依赖，CI/CD 将构建产物发布到托管仓库。
1. 在 AngusRepo 中创建仓库
| 仓库名 | 类型 | 用途 |
|---|---|---|
maven-releases | HOSTED | 存放内部正式版本 |
maven-central | PROXY | 代理 Maven Central |
maven-public | GROUP | 为客户端提供统一的依赖拉取入口 |
将maven-releases与maven-central加入maven-public。
2. 配置 Maven 凭据
在~/.m2/settings.xml中配置发布凭据。建议通过环境变量注入令牌，不要把实际令牌提交到代码仓库：
<settingsxmlns="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 中创建仓库
| 仓库名 | 类型 | 用途 |
|---|---|---|
docker-hosted | HOSTED | 存放内部应用镜像 |
docker-hub | PROXY | 代理 Docker Hub |
2. 登录到 AngusRepo Docker 仓库
dockerlogin repo.anguskit.com输入用户名和访问令牌（在 AngusRepo 用户设置中生成）。
3. 推送镜像到托管仓库
# 构建镜像dockerbuild-trepo.anguskit.com/docker-hosted/myapp:1.0.0.# 推送镜像dockerpush repo.anguskit.com/docker-hosted/myapp:1.0.04. 从代理仓库拉取公共镜像
# 拉取 Docker Hub 的镜像（通过 AngusRepo 代理）dockerpull repo.anguskit.com/docker-hub/nginx:latest5. 在 CI/CD 中使用
# GitLab CI 示例stages:-build-pushbuild-image:stage:buildscript:-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 registrynpmconfigsetregistry https://repo.anguskit.com/npm/npm-public/# 配置认证令牌npmconfigset//repo.anguskit.com/npm/:_authToken YOUR_ACCESS_TOKEN2. 安装依赖
npminstall3. 发布内部包
npmpublish--registryhttps://repo.anguskit.com/npm/npm-releases/更多格式的配置示例请参阅[完整格式使用指南]。
常见问题
Q: 如何生成访问令牌？
登录 AngusRepo → 用户设置 → 访问令牌 → 生成新令牌。可以指定令牌的权限范围（只读/读写）和有效期。
Q: PROXY 仓库如何处理认证？
如果上游仓库需要认证（如私有 Docker Registry），在创建 PROXY 仓库时配置上游凭据。AngusRepo 会在请求上游时自动使用这些凭据。
Q: 如何清理旧版本制品？
在仓库设置中配置清理策略，可以按以下规则自动删除制品：
- 保留最近 N 个版本
- 删除超过 X 天未使用的制品
- 删除特定版本模式（如 SNAPSHOT）的旧版本
Q: 支持匿名访问吗？
支持。可以在仓库设置中启用匿名读取，允许未认证用户拉取制品。但发布制品始终需要认证和授权。
与研发工作流协同
AngusRepo 可以作为构建和交付流程中的制品入口：
- 开发阶段：开发者在本地解析依赖，从 PROXY 仓库获取公共依赖，从 HOSTED 仓库获取内部组件
- 构建阶段：CI/CD 在构建完成后将制品发布到 HOSTED 仓库，触发 Webhook 通知测试环境
- 测试阶段：测试环境从受控的仓库地址拉取对应版本的制品进行部署
- 发布阶段：生产环境从审核通过的制品版本中拉取部署，所有操作有完整审计记录
配合权限管理、清理策略、审计与安全治理，团队更容易统一制品的流转方式，并持续维护可理解、可复用的交付流程。
实施建议：对于已使用自动化流水线的团队，可以从 Maven、npm 或 Docker 等最常用的格式开始，验证基本流程后再根据项目与团队需求逐步扩展到其他格式。
原文地址：anguskit.com
