制品仓库与制品晋级

• 本地仓库（local）与远程代理仓库（remote/proxy）
• 虚拟仓库（virtual）聚合
• 缓存与制品管理

制品仓库的本地与远程代理仓库分工明确。本地仓库（local）存储组织自建/上传的制品（私有镜像、内部包），是私有制品的唯一来源；远程代理仓库（remote/proxy）代理外部仓库（如 Maven Central、npmjs、Docker Hub），拉取时把外部制品缓存到本地，从而加速、隔离外部依赖并减少对公网的依赖。虚拟仓库（virtual）聚合多个本地+远程仓库为一个统一入口，客户端只需访问一个 URL，随即按优先级解析到具体仓库。分工上：本地管私有制品，远程管外部依赖缓存，虚拟统一入口，共同支撑"构建快、依赖可控、制品集中管理"。核心是"本地存私有、远程代理缓存、虚拟聚合入口"。

仓库分工是制品管理的基石。答题要点是"本地/远程/虚拟三类仓库的职责与配合"，体现对制品仓库拓扑的理解。

• 多格式支持范围
• 各自的仓库形态与生态
• 选型考虑

Nexus 与 Artifactory 都支持 Docker、NPM、Maven、NuGet、PyPI 等多格式制品，但各有侧重。Nexus（Sonatype 出品）以 Maven 等 Java 生态见长，格式支持全面、社区普及，提供支持 Docker 的 repository manager；Artifactory（JFrog 出品）在 Docker、NPM、多格式与高级功能上更丰富，天然支持 Docker 的多级仓库、复制、垃圾回收，并与 Xray 集成做制品漏洞扫描。差异上：Artifactory 的虚拟仓库、复制、高可用与 Xray 安全集成更成熟，适合大规模多格式、重安全的场景；Nexus 更轻量、成本低、Maven 生态成熟。选型取决于团队生态、规模与安全需求。核心是"都支持多格式，但 Artifactory 高级功能与安全集成更丰富，Nexus 更轻量"。

选型对比要抓"格式覆盖 + 高级功能 + 生态成本"。答题要点是"多格式支持、Artifactory 在构建/安全集成更强、Nexus 更轻量"，体现对两款工具差异的理解。

• 晋级流程与阶段门禁
• 制品不可变传递
• 晋级审计与留痕

制品 promotion（晋级）流程把同一制品从 dev 逐步晋升到 prod，核心是"构建一次、处处晋级、逐步验证"。流程：开发的制品推送后先在 dev 环境验证，通过测试与门禁后晋升到 staging（预发），再验证后晋升到 prod（生产）。每个阶段是门禁：dev→staging 需单元/集成测试通过，staging→prod 需验收、安全扫描、审批通过。晋级遵循"制品不可变"原则：同一镜像/版本不在各环境重新构建，只传递同一 digest，保证各环境验证的是同一制品。每次晋级记录晋级者、时间、门禁结果，形成审计链。回到失败时回滚到上一已验证版本。核心是"阶段门禁 + 不可变传递 + 全程审计"。

promotion 是"制品传递 + 门禁验证"的过程。答题要点是"分阶段门禁、制品不可变、晋级审计"，体现对制品晋级一致性的理解。

• 元数据种类（provenance、SBOM、test result）
• 与制品的关联方式
• 元数据在晋级/审计中的作用

制品元数据（build provenance 构建来源、SBOM 软件物料清单、test result 测试结果）需与制品强关联存储，形成可追溯的制品档案。存储方式：把元数据作为制品元信息（manifest 的 annotations、metadata）或作为独立不可变对象用制品 ID/digest 关联，如 OCI 镜像用 OCI 索引/附加对象、SBOM 用 cosign attestation 或 OCI artifact 附加。provenance 记录构建来源（构建工具、源码 commit、构建参数），SBOM 记录组成（依赖清单、license），test result 记录测试通过情况。它们支撑晋级门禁（扫描、签校验）、审计溯源与合规。关联机制保证"拿到制品即拿到其完整元数据"，且元数据不可变。核心是"元数据与制品绑定、多类型、支撑门禁与审计"。

元数据关联是"制品可信与可溯源"的基础。答题要点是"元数据种类、与制品用 digest/attestation 关联、支撑门禁审计"，体现对供应链可追溯的理解。

• 审计日志内容与字段
• 晋级事件记录与留痕
• 合规与追溯

制品晋级流水线的审计日志要记录整个晋级过程的完整证据。内容字段：制品 ID/digest、来源 commit/构建号、晋级前/后仓库与阶段、执行者（触发者）、门禁结果（测试/扫描/审批）、时间戳、授权信息。设计要点：每条晋级事件都不可变记录（append-only），写入审计日志或区块链式记录；关联到制品元数据，支持从制品反查完整晋级链；门禁通过/拒绝、异常绕过都要记录；对生产晋级尤其要记录审批人、审批意见与执行结果。审计日志支撑合规审计与故障溯源，核心是"晋级全程留痕、字段完整、不可篡改、可反查"。

审计日志是"制品可信"的合规支撑。答题要点是"审计字段、append-only、关联制品、门禁与审批留痕"，体现对制品治理的理解。

• 扫描时机与位置
• 晋级门禁的卡点
• 扫描结果与例外处理

制品漏洞扫描嵌入晋级门禁的最佳位置是"制品可晋级的最早节点、且覆盖所有后续环境"。通常放在：构建后推送制品仓库时扫描（尽早发现，防止坏制品进入流程），以及每个晋级门禁（dev→staging→prod）处扫描并校验，确保进入生产的是经过安全确认的制品。实践中常用"构建后扫描 + 晋级门禁卡点"：构建后扫描发现漏洞并标记，晋级到 staging/prod 前校验漏洞状态（如高危漏洞数超阈值则阻断晋级）。扫描结果与制品元数据关联，作为晋级门禁的输入。对不可修复漏洞走例外审批。核心是"扫描尽量早 + 晋级门禁卡点 + 结果关联制品"。

扫描位置要"早发现 + 门禁卡住"。答题要点是"构建后扫描 + 晋级门禁校验 + 例外审批"，体现对安全门禁位置设计的理解。

• 虚拟仓库聚合本地+远程
• 解析优先级与统一入口
• 对客户端与权限的影响

Artifactory 虚拟仓库（virtual repository）把多个本地与远程仓库聚合为一个统一逻辑入口，客户端只需配置一个虚拟仓库 URL 即可访问多类制品。设计时：虚拟仓库按格式（如 docker-virtual、maven-virtual）组织，聚合对应本地+远程仓库，并设置解析优先级（resolution order）——先查本地私有制品，再查远程代理缓存，从而保证私有制品优先、外部依赖兜底。统一入口简化客户端配置（不用配多个 URL），并便于集中做权限控制（对虚拟仓库授权即可覆盖其下仓库）。设计需注意透明性（虚拟仓库对客户端透明）、避免命名冲突与优先级混乱。核心是"聚合多 repo、统一入口、优先级解析、集中权限"。

虚拟仓库是"多库统一入口"的设计。答题要点是"聚合、解析优先级、统一入口、集中权限"，体现对制品仓库拓扑设计的理解。

• 复制（replication）跨实例/跨地域
• 垃圾回收（GC）清理已删除镜像
• 复制一致性保障

Harbor 的复制（replication）用于跨实例/跨地域同步镜像：配置复制规则（源、目标、按项目/标签过滤），把镜像从主 Harbor 复制到备份/异地 Harbor；支持推（push）与拉（pull）模式、定时/事件触发，用于容灾与分发。复制一致性上，需保证同步状态与失败重试，避免部分复制。垃圾回收（GC）清理已被删除的镜像层与标签对应数据：Harbor 的 GC 会扫描并删除不再被任何仓库引用的 blob，释放存储；GC 需在复制间隙执行，避免误删正在复制或使用的层，且删除不可逆（实际删除底层 blob）。实践中按保留策略删除 tag 后定期 GC 回收磁盘。核心是"复制保分发/容灾、GC 释放已删镜像的存储、两者配合存储管理"。

复制与 GC 是镜像库的"分发与回收"能力。答题要点是"复制规则与模式、GC 清理原理、复制与 GC 的协调"，体现对镜像库运维的理解。

• 依赖缓存的作用（加速构建）
• 清理策略（保留规则、过期）
• 缓存命中与磁盘空间的平衡

依赖缓存（远程代理缓存、本地缓存）通过复用已下载依赖加速构建，但会占用磁盘，需与清理策略平衡。缓存策略：保留常用、近期的依赖，对旧版本、未使用依赖定期清理；清理策略常用"最近使用/最近下载时间"（LRU）、"保留数量上限"、"保留期限"等规则，只清理可安全重建的缓存（依赖可从源头重新拉取）。平衡点：缓存命中率越高构建越快，但缓存过多磁盘成本高；需设置缓存上限、过期时间，并识别"可重建"与"不可重建"（私有制品不可删，公有依赖可删）。常用"按使用时间清理 + 保留私有制品 + 限额"的组合。核心是"缓存命中换速度、按使用与可重建性清理换空间"。

缓存与清理是"速度与成本"的权衡。答题要点是"缓存加速、按使用/限额清理、区分可重建与私有制品"，体现对依赖治理的理解。

• 制品不可变（immutable）原则
• 版本追溯机制
• 与供应链安全的关系

制品不可变性指同一制品（如镜像 digest）一经发布不可修改，保障"测试过的制品与生产一致"。保障方式：用不可变 tag（digest 或版本号）标识制品，禁止覆盖已发布 tag（设置仓库不可变策略，禁止重打 tag）；镜像用 digest 而非 mutable tag 引用；制品内容一经发布不可变，变更需生成新版本。版本追溯：通过制品元数据（provenance、commit、构建号）与 digest 关联，支持从任意版本回溯到源码、构建参数与依赖，形成完整溯源链。不可变性与追溯结合，保证制品可信、可审计、可回滚，是供应链安全的基础。核心是"不可变防篡改、digest 溯源保可信"。

不可变性与追溯是"制品可信"的两面。答题要点是"不可变 tag/digest、禁止覆盖、provenance 溯源"，体现对供应链安全的理解。

• 各类清理策略含义
• 取舍与适用场景
• 防止误删

制品清理策略需要在存储空间与制品可用性之间取舍：

• last modified：按最后修改时间清理长期未变的制品，适合内容稳定的制品，但可能误删仍在使用的旧版本。
• last downloaded：按最后下载时间清理未被使用的制品，更贴近"使用度"，但下载记录可能不全。
• count limit：按保留数量上限清理，保留最近 N 个版本，适合控制版本数量，但可能删掉仍被引用的旧版本。 取舍上：生产制品（私有、可能被引用）应谨慎清理，低风险缓存（公有依赖）可激进清理；常组合"count limit 保留最近版本 + last downloaded 清理未使用 + 保留期兜底"。需防误删：清理前 dry-run、对生产制品设豁免、清理后验证。核心是"按使用度与重要性分层清理，避免误删仍被引用的制品"。

清理策略取舍是"空间与可用性"的平衡。答题要点是"三类策略含义、按重要性分层、防误删"，体现对制品生命周期管理的理解。

• 不可变版本号与 digest
• 签名校验（cosign）
• provenance 关联溯源

制品来源管理把"版本号、签名、provenance"三者关联成可信链条。不可变版本号：用版本号或 digest 唯一标识制品，构建一次后不可变，使版本可精确引用。签名校验：用 cosign/notary 对制品签名，在获取/晋级时校验签名，防止伪造或篡改；签名与制品绑定（signature 与 digest 关联）。provenance（构建元数据）：记录构建来源（源码 commit、构建工具、构建参数、依赖），用 attestation 关联到制品。三者关联：拿到制品→校验 digest 与签名→读取 provenance→回溯源码与构建，形成"版本→签名→来源"的完整溯源链，支撑供应链安全与审计。核心是"不可变版本 + 签名校验 + provenance 溯源"。

溯源管理是供应链安全的核心。答题要点是"不可变版本、cosign 签名校验、provenance 关联"，体现对制品可信链的理解。

• 签名时机与校验节点
• 晋级链各节点校验
• 签名与门禁结合

制品签名在晋级链中的校验节点设计：签名在构建完成后、制品入库时执行（CI 用 cosign 私钥签名），之后每个晋级节点（dev→staging→prod）校验签名与制品完整性。校验节点包括：拉取制品时校验（下载仓库拉取前验证签名）、晋级门禁时校验（晋升前验证签名有效且来自可信签名者）、部署前校验（生产部署前再次验证）。签名与门禁结合：签名校验失败则阻断晋级，保证只有可信、未被篡改的制品能进入生产。关键节点设计：签名在源头、校验在每个入口，私钥安全托管（KMS/HSM），公钥可信分发。核心是"源头签名、各晋级节点校验、私有库与门禁结合"。

签名校验节点是"源头签名 + 节点校验"的链条。答题要点是"签名时机、各晋级节点校验、与门禁结合、私钥托管"，体现对制品信任链的理解。

• 保留规则（按版本/时间/数量）
• GC 窗口与执行时机
• 依赖锁定对清理的约束

制品仓库清理策略需综合考虑保留规则、GC 窗口与依赖锁定。保留规则：按版本数量、保留时长、正则匹配（如保留版本号规则内的最近 N 个）设定，确保常用制品保留、旧版本可清理。GC 窗口：垃圾回收在业务低峰执行，避免与构建/下载高峰冲突，且 GC 前确认无正在使用的制品（复制/拉取/构建中），防止误删。依赖锁定：应用锁定了具体版本（如 lockfile 固定版本），这些版本被稳定引用，清理时应豁免或保留锁定版本，否则会破坏可复现构建与回滚。清理策略需"保留被锁定/引用的版本，清理未锁定且过期的版本，在低峰窗口执行 GC"。核心是"保留规则 + 低峰 GC + 依赖锁定豁免"。

清理策略要"留得住、清得准、不误删"。答题要点是"保留规则、GC 窗口、依赖锁定豁免"，体现对制品生命周期与可复现构建的综合理解。

• 多格式仓库与统一管理
• 按格式划分仓库
• 统一入口与权限

制品多格式管理把镜像、npm/maven 包、通用二进制等异构制品统一治理。组织方式：按格式划分仓库（docker 仓库、npm 仓库、maven 仓库、generic 通用仓库），每个格式用原生托管方式（Harbor 管镜像、Artifactory/Nexus 管多格式），再用虚拟仓库统一入口，让客户端用统一 URL 访问多格式制品。统一管理包括：统一的权限（按项目/团队授权）、统一的安全扫描（跨格式扫描）、统一的生命周期与清理策略。镜像需专门仓库（支持 OCI、复制、GC），包仓库管理各生态的版本与依赖，通用二进制用于非标准制品。核心是"按格式分仓库、虚拟仓库统一入口、统一权限与安全"。

多格式管理要"格式分治 + 统一治理"。答题要点是"按格式分仓库、虚拟仓库聚合、统一权限与扫描"，体现对制品仓库整体设计的理解。

• 环境门禁（各阶段验证）
• 签名重验（晋级时重新校验）
• 晋级记录审计

制品晋级流转控制要保证"只有通过验证的制品才能进入下一环境"。环境门禁：每个晋级阶段（dev→staging→prod）设置门禁，通过测试、扫描、审批等验证才允许晋级，只有门禁通过的制品才能流转。签名重验：晋级时对制品重新校验签名与完整性（而非只信任源头），防止流转中被篡改或替换，保证传到生产的是可信制品。晋级记录审计：每次晋级记录制品、来源环境、目标环境、执行者、门禁结果、时间，形成不可篡改的晋级链，支撑溯源与合规。流转控制核心是"环境门禁拦质量、签名重验保可信、审计记录保可追溯"。核心是"门禁 + 重验 + 审计"三位一体。

流转控制是"质量、安全、审计"的结合。答题要点是"环境门禁、签名重验、晋级审计"，体现对制品晋级完整性的理解。

• 依赖锁定（lockfile、固定版本）
• 构建参数固化（环境、参数）
• 可重复构建验证

可复现构建保证"同一输入得到同一制品"。依赖锁定：用 lockfile（npm-shrinkwrap、poetry.lock、go.sum）固定依赖版本，锁定传递依赖，避免"版本漂移"。构建参数固化：固化构建环境（基础镜像版本、构建工具版本、环境变量、构建参数、编译器），避免环境差异导致产物不同。可重复构建验证：用确定性的构建（固定依赖与参数）验证多次构建产物一致（如比较 digest），并可做"重建验证"（重新构建对比历史产物）。实现上常配合构建缓存与容器化环境隔离。可复现构建支撑制品可信、审计与合规。核心是"依赖锁定 + 参数固化 + 重复验证"。

可复现构建是"制品可信"的前提。答题要点是"lockfile 锁定、参数/环境固化、重复构建验证"，体现对构建确定性的理解。

• 高可用部署（集群、多副本）
• 异地复制（replication）
• 一致性保障（同步、冲突）

私有制品仓库高可用与异地复制保障分两块。高可用部署：用集群化部署（如 Artifactory HA、Nexus 集群、Harbor HA）多副本共享存储或分布式存储，避免单点故障；配合负载均衡、健康检查与故障转移，保证持续可用。异地复制：用复制（replication）把制品同步到异地/灾备实例，支撑容灾与就近分发。一致性保障：复制要保证同步的完整性（全量/增量、校验、失败重试），避免部分复制导致制品缺失；对并发写与冲突（同一制品多源写入）要定义冲突策略；复制一致性需监控同步状态、延迟与失败。高可用+异地复制共同保证"可用性 + 容灾 + 数据一致"。核心是"本地集群化高可用 + 异地复制 + 同步一致性监控"。

高可用与异地复制是"可用与容灾"的组合。答题要点是"集群化高可用、异地复制、同步一致性与冲突处理"，体现对制品库可靠性的理解。