📚 课程目录第1章制品库与软件包管理导论

1. 制品库与软件包管理导论

在进入 GitLab 制品库的具体操作之前，先把几个高频概念厘清，否则后续在流水线里配置仓库、上传包、拉取依赖时，很容易把“制品”“包”“依赖”“仓库”“注册表”混为一谈。它们描述的是软件交付链上不同层次的对象，理解它们的边界，是搭建可靠制品管理流程的前提。

一、制品、包、依赖：三个容易混淆的对象

制品（Artifact）是构建过程产出的、可被部署或分发的文件实体。它可以是编译后的二进制、打包好的 JAR、前端构建出的静态资源压缩包、容器镜像的层文件，甚至是一份生成的配置文件。制品的核心特征是“由某次构建产生、内容确定、可被追溯”。例如一次 Maven 构建产出 order-service-1.4.2.jar，这个 JAR 就是一个制品。

包（Package）是制品的一种规范化封装形式，它带有元数据（名称、版本、依赖声明、校验和等），并遵循某种包管理规范，如 Maven、npm、NuGet、PyPI、RubyGems、Debian 等。包的价值在于“可被包管理器识别、解析和安装”。同一个 JAR 文件，如果配上 pom.xml 元数据并发布到 Maven 仓库，它就成了一个 Maven 包；如果只是放在服务器目录里，它只是制品。

依赖（Dependency）是当前构件在构建或运行时需要引用的其他包。依赖关系通常记录在项目描述文件中，例如 pom.xml 的 <dependencies>、package.json 的 dependencies。依赖可以传递：A 依赖 B，B 依赖 C，则 A 在解析时会间接引入 C。依赖管理要解决的核心问题是版本选择、冲突消解和可重复构建。

一句话区分：制品是“产物文件”，包是“带元数据、可被包管理器识别的制品”，依赖是“包与包之间的引用关系”。

二、仓库与注册表：存放和寻址的机制

仓库（Repository）是存放包的存储空间，通常按包格式划分，例如 Maven 仓库、npm 仓库、PyPI 仓库。仓库分为本地仓库（开发者机器上的缓存目录，如 ~/.m2/repository）、远程仓库（如 Maven Central、npmjs.org）和私有仓库（企业内部自建，用于存放私有包）。

注册表（Registry）更强调“可寻址的服务端点”，它提供包的发布、查询、下载接口，并维护命名空间与版本索引。Docker Registry 是最典型的例子，它按 仓库名:标签 寻址镜像。在 GitLab 语境下，Package Registry 同时承担仓库和注册表的角色：既存储包文件，又提供 API 供 CI/CD 和开发者拉取。

理解这两者的关系，可以这样看：仓库是“库房”，注册表是“库房的门牌与检索系统”。没有注册表，仓库里的包无法被标准化地定位和获取。

三、GitLab 制品库在 DevOps 工具链中的定位

GitLab 制品库并不是孤立存在的，它嵌入在 GitLab 的一体化 DevOps 平台中，与代码托管、CI/CD、安全扫描、发布编排共享同一套权限与项目模型。它的定位可以从三个维度理解：

与 CI/CD 的耦合：流水线在构建阶段产出包，直接通过 CI_JOB_TOKEN 推送到项目级 Package Registry，无需额外配置独立账号；部署阶段再从 Registry 拉取指定版本，形成“构建—存储—部署”闭环。
与权限体系的统一：包的读写权限继承项目成员权限，私有包天然受控，不需要单独维护一套仓库账号体系。
与依赖代理的配合：GitLab 支持 Dependency Proxy，可缓存 Docker Hub 等外部镜像，减少对外部网络的依赖，同时提升拉取速度。

与 Nexus、Artifactory 等独立制品库相比，GitLab 制品库的优势在于“开箱即用、与项目同生命周期”；劣势在于对超大规模、多格式混合、复杂保留策略的场景，独立制品库仍更成熟。选择时应根据团队规模、包格式种类和合规要求判断。

四、课程学习地图与实验环境准备

本课程围绕 GitLab 制品库展开，学习路径可以概括为“概念—配置—发布—消费—治理”五个层次。前几章建立概念与权限模型，中间章节分别深入 Maven、npm、NuGet、PyPI、Container Registry 等具体格式的发布与拉取，后续章节覆盖依赖代理、清理策略、安全扫描与跨项目共享。每一章都会给出可执行的命令和可观察的结果，而不是停留在界面截图。

实验环境建议采用 GitLab 官方提供的 Docker 镜像快速搭建，最低配置为 4 核 CPU、8 GB 内存、50 GB 磁盘。以下命令用于启动一个本地 GitLab 实例，供后续章节练习使用：

docker run -d --name gitlab-lab \
  --hostname gitlab.example.local \
  -p 8080:80 -p 8443:443 -p 2222:22 \
  -v gitlab-config:/etc/gitlab \
  -v gitlab-logs:/var/log/gitlab \
  -v gitlab-data:/var/opt/gitlab \
  --shm-size 512m \
  gitlab/gitlab-ce:16.11.0-ce.0

启动后等待约 3～5 分钟，访问 http://localhost:8080，首次登录需要从容器内读取初始 root 密码：

docker exec -it gitlab-lab grep 'Password:' /etc/gitlab/initial_root_password

登录后建议立即完成三件事：修改 root 密码、创建一个名为 artifact-lab 的私有项目、在项目设置中确认 Package Registry 已启用。判断环境是否就绪的依据是：项目左侧菜单出现 Packages and registries 入口，且 http://localhost:8080/help 页面能正常显示版本号。如果 8080 端口被占用，可改用 -p 8081:80，后续所有命令中的端口号同步替换即可。

实验环境仅用于学习，不要将上述配置直接用于生产。生产环境需要配置 HTTPS、外部数据库、对象存储和备份策略，这些内容会在后续章节涉及。

完成环境准备后，你就拥有了一个可以反复实验的 GitLab 实例。接下来每一章的操作都可以在这个实例中复现，建议为每个包格式单独创建一个测试项目，避免不同格式的配置相互干扰。