企业官网建设流程全解析

1. 项目概述：为什么你需要一个企业级的容器镜像仓库？

如果你正在使用Docker，那么你肯定知道镜像仓库的重要性。无论是从Docker Hub拉取基础镜像，还是将自己构建的应用镜像推送到某个地方，镜像仓库都是整个容器化流程的枢纽。对于个人开发者或小团队，使用公共仓库或许还能应付。但一旦项目规模扩大，涉及到团队协作、CI/CD流水线、安全扫描和版本管理，一个私有、可控、与企业开发流程深度集成的镜像仓库就变得不可或缺。

这就是GitLab Container Registry（容器镜像仓库）的价值所在。它不是一个独立的产品，而是GitLab这个一体化DevOps平台的内置功能。这意味着你的代码仓库、CI/CD流水线、包管理，现在再加上容器镜像仓库，全部都在同一个平台、同一个项目下管理。想象一下，你提交代码触发CI，CI构建出Docker镜像并自动推送到与代码同项目的Registry中，后续的CD阶段直接从同一个项目里拉取镜像部署——整个流程无缝衔接，权限统一，审计日志清晰。这远比维护一个独立的Harbor或Nexus仓库，再费力地与GitLab CI做集成要优雅和高效得多。

很多人知道GitLab能存Docker镜像，但往往只停留在基础的docker push/pull操作。实际上，它的高级功能才是真正提升企业研发效能与安全性的关键。比如，如何清理过期镜像释放存储空间？如何设置镜像保留策略，防止测试镜像撑爆磁盘？如何利用漏洞扫描，在推送镜像时就发现安全风险？以及如何与CI/CD深度集成，实现从代码到镜像的自动化？接下来，我将结合多年的实战经验，为你深度拆解这些高级功能，让你手中的GitLab Registry不再是简单的存储柜，而是一个智能的、自动化的镜像供应链核心。

2. 核心功能深度解析与设计思路

GitLab Container Registry的设计哲学是“内聚”，它并非追求功能的大而全，而是强调与GitLab自身生态的无缝融合。理解这一点，是用好它的前提。

2.1 项目集成与命名空间

这是最基础也最重要的特性。在GitLab中，每个项目（Project）或群组（Group）都自动拥有一个与之关联的镜像仓库地址。镜像的命名遵循特定格式：

• 项目级仓库：registry.example.com/namespace/project/image:tag
• 群组级仓库：registry.example.com/group/subgroup/image:tag

这里的registry.example.com是你的GitLab域名（如果启用HTTPS）或IP端口。namespace/project直接映射到你的代码仓库路径。这种设计带来了几个天然优势：

1. 权限继承：镜像仓库的访问权限（读、写、删除）完全继承自GitLab项目或群组的成员权限。开发者能访问代码，就能访问对应的镜像，无需额外配置。
2. 资产关联：在项目的“Packages & Registries”菜单下，可以清晰看到所有关联的容器镜像，代码和制品的关系一目了然，便于追溯。
3. 地址简化：在CI/CD作业中，你可以直接使用预定义的变量如$CI_REGISTRY_IMAGE来指代当前项目的仓库地址，无需硬编码。

注意：默认情况下，项目镜像仓库对项目成员是可读的。如果你希望镜像完全私有，需要对项目本身设置私有权限。同时，GitLab的“容器注册表”功能在SaaS版和所有自托管版中均可用，但某些高级功能（如清理策略）可能需要特定许可证（如Premium或Ultimate）。

2.2 镜像清理策略：告别存储空间焦虑

这是最容易被忽视，却又最能体现运维价值的“高级”功能。CI/CD流水线如果配置不当，很容易产生大量带latest、分支名或合并请求ID的临时镜像，日积月累会迅速耗尽服务器磁盘空间。手动清理不仅繁琐，而且危险。

GitLab的清理策略（Cleanup Policy）允许你基于规则自动删除旧镜像。其核心逻辑是“保留什么”，而不是“删除什么”。你可以通过UI或API配置以下规则：

1. 保留最近推送的N个镜像标签：例如，保留最新的10个标签，无论其名称是什么。这适用于主分支的持续构建。
2. 保留与正则表达式匹配的标签：这是最强大的部分。你可以编写正则表达式来保护重要的镜像。
   • 保留版本标签：v\d+\.\d+\.\d+（匹配 v1.0.0, v2.1.5）
   • 保留生产环境镜像：production或prod-\d+
   • 保留按日期命名的镜像：\d{4}-\d{2}-\d{2}（匹配 2023-10-27）
3. 保留在“保留期内”创建的标签：你可以设置一个天数（如7天），在此期限内创建的镜像标签不会被删除，即使它不符合上述任何保留规则。这为临时性的分支构建提供了安全缓冲。
4. 删除未标记的镜像（Manifests）：Docker推送镜像时，如果只推送了镜像层（Layer）而未打标签，或者一个标签被删除后，其对应的Manifest可能变成“悬空”状态。启用此选项可以定期清理这些不关联任何标签的镜像数据，这是深度清理、回收空间的关键。

配置实操心得：

• 从小范围开始：先在非关键项目上测试清理策略，观察日志，确认规则按预期工作后再应用到核心项目。
• 正则表达式要精确：使用在线正则测试工具（如 regex101.com）反复验证你的表达式，避免误删。例如，想保留release-*的标签，用^release-比release更安全，后者可能匹配到feature-release-test。
• 结合CI/CD：最优雅的方式是在.gitlab-ci.yml中规范镜像标签的命名。例如，主分支构建打上latest和${CI_COMMIT_SHORT_SHA}；打版本标签时推v${CI_COMMIT_TAG}；合并请求构建推mr-${CI_MERGE_REQUEST_IID}。然后在清理策略中设置：保留latest，保留匹配^v\d+的标签，保留最近5个mr-\d+标签，其他全部在创建14天后删除。
• 执行周期：清理策略是定时执行的，默认每天一次。对于镜像产生非常频繁的项目，这个频率是足够的。清理是一个后台任务，不会立即生效。

2.3 安全扫描与合规性（需Premium及以上版本）

对于企业而言，镜像安全与代码安全同等重要。GitLab Container Registry集成了GitLab Security Scanning功能，可以在镜像推送到仓库后自动启动安全扫描。

1. 漏洞扫描：使用开源的Trivy或Clair等扫描器，对镜像的每一层进行解析，比对已知的CVE（通用漏洞披露）数据库，识别操作系统包（如apt, yum）、编程语言依赖（如npm, pip, gems）中的安全漏洞。
2. 扫描过程：通常由CI/CD流水线中的一个特定作业（如container_scanning）来执行。该作业会拉取刚构建好的镜像，运行扫描器，生成一份包含漏洞列表、严重等级（Critical, High, Medium, Low）、受影响包和修复建议的SAST（静态应用安全测试）报告。
3. 结果呈现：报告会直接显示在GitLab的以下几个位置，形成闭环：
   • 合并请求（MR）Widget：如果该镜像是某次合并请求构建产生的，扫描结果会以评论或小部件的形式出现在MR界面，方便代码评审者在合并前发现潜在风险。
   • 安全仪表盘：项目级和群组级的统一安全视图，汇总所有漏洞。
   • 依赖清单：列出镜像中包含的所有软件包及其版本。

实操要点：

• 基线管理：不要追求“零漏洞”，这通常不现实。应该根据漏洞的CVSS评分、可利用性和对业务的影响，设定可接受的阈值。例如，只阻断含有Critical或High级别漏洞的镜像被部署到生产环境。
• 与CI/CD门禁结合：在.gitlab-ci.yml中，可以配置allow_failure: false给安全扫描作业。这样，如果发现超过阈值的漏洞，该作业会失败，进而导致整个流水线失败，阻止镜像被推送到生产仓库或部署。
• 定期扫描：除了推送时扫描，还应设置定时任务（如每周）对仓库中已有的、正在使用的生产镜像进行重新扫描，因为新的CVE在不断被发现。

2.4 与CI/CD的深度集成：自动化流水线的核心

这是GitLab Registry的灵魂所在。通过预定义的环境变量和Docker命令行工具，在CI作业中操作镜像变得极其简单。

一个典型的构建并推送镜像的CI作业配置如下：

build_and_push: stage: build image: docker:20.10.16 # 使用Docker in Docker (dind) 环境 services: - docker:20.10.16-dind variables: DOCKER_TLS_CERTDIR: "/certs" script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA # 如果是默认分支（如main），额外打上latest标签 - | if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA $CI_REGISTRY_IMAGE:latest docker push $CI_REGISTRY_IMAGE:latest fi rules: - if: $CI_COMMIT_BRANCH # 在分支推送时触发

关键变量解析：

• $CI_REGISTRY： GitLab容器仓库的地址，如registry.gitlab.com（SaaS版）或你自托管的地址。
• $CI_REGISTRY_IMAGE： 当前项目对应的完整镜像仓库地址，如registry.gitlab.com/my-group/my-project。
• $CI_REGISTRY_USER/$CI_REGISTRY_PASSWORD： 自动生成的、对当前项目有推送权限的临时凭证。这些凭证在作业结束后失效，非常安全。

高级集成模式：

1. 多阶段构建与缓存：在Dockerfile中使用--from进行多阶段构建，并在CI中利用Docker的--cache-from参数，可以显著加速构建过程。你可以将上一流水线构建的某个阶段镜像作为缓存源。
2. 部署作业：在后续的deploy阶段，作业可以直接使用$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA来拉取确切的镜像进行部署，实现了构建物与代码提交的严格对应。
3. 环境特定镜像：你可以根据不同的GitLab环境（如staging, production）推送带不同标签的镜像，例如$CI_REGISTRY_IMAGE:staging或$CI_REGISTRY_IMAGE:prod-$CI_COMMIT_TAG。

3. 实战部署与配置指南

理解了核心功能后，我们来看看如何在实际环境中配置和使用它，特别是自托管（Self-managed）的GitLab实例。

3.1 启用与配置容器镜像仓库

对于GitLab SaaS (gitlab.com)，此功能默认启用，无需额外配置。

对于自托管GitLab，需要在安装时或后期配置。这里以Omnibus安装包为例，主要配置位于/etc/gitlab/gitlab.rb：

# 启用Registry服务 registry['enable'] = true # 配置Registry的外部访问地址，必须与GitLab外部URL使用相同协议(HTTP/HTTPS) external_url 'https://gitlab.example.com' registry_external_url 'https://registry.gitlab.example.com' # 可以使用相同或不同域名 # 配置存储路径（默认在/var/opt/gitlab/gitlab-rails/shared/registry） gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry" # 配置存储后端（可选，默认是本地文件系统） # 例如使用AWS S3（强烈推荐生产环境使用，便于扩展和备份） gitlab_rails['registry_object_store'] = { 'enabled' => true, 'remote_directory' => 'my-gitlab-registry', # S3 Bucket名称 'bucket' => 'my-gitlab-registry', 'connection' => { 'provider' => 'AWS', 'region' => 'us-east-1', 'aws_access_key_id' => 'YOUR_ACCESS_KEY', 'aws_secret_access_key' => 'YOUR_SECRET_KEY' # 对于MinIO等S3兼容服务，可添加 'endpoint', 'path_style' 等参数 } } # 配置Registry的认证（与GitLab集成） registry['auth_autoredirect'] = false registry['token_realm'] = 'https://gitlab.example.com' # 必须与external_url一致

配置完成后，运行sudo gitlab-ctl reconfigure使配置生效。然后访问https://registry.gitlab.example.com，你应该能看到Registry的欢迎页面，并通过GitLab账户登录。

重要提示：生产环境务必使用HTTPS。如果使用自签名证书，需要在所有Docker客户端（包括GitLab Runner服务器）信任该证书，否则docker login和push/pull会失败。对于Linux客户端，可以将CA证书放入/etc/docker/certs.d/registry.gitlab.example.com/ca.crt。

3.2 客户端认证与操作

用户通过docker login命令向GitLab Registry认证。GitLab支持两种主要方式：

1. 个人访问令牌（Personal Access Token）：最推荐的方式。在GitLab用户设置中创建一个Token，需至少授予read_registry和write_registry权限。登录命令：

   docker login registry.gitlab.example.com -u <你的用户名> -p <你的个人访问令牌>

2. 部署令牌（Deploy Token）：针对项目或群组创建，适合自动化脚本或CI/CD Runner。在项目设置中创建，同样需要read_registry和write_registry权限。用法与个人令牌类似。
3. CI/CD作业令牌：在GitLab CI作业中，$CI_REGISTRY_PASSWORD就是一个自动生成的、有项目权限的临时令牌，无需手动创建。

登录成功后，就可以进行标准的Docker操作了：

• 推送镜像：

  docker tag local-image:tag registry.gitlab.example.com/group/project/image:tag docker push registry.gitlab.example.com/group/project/image:tag

• 拉取镜像：

  docker pull registry.gitlab.example.com/group/project/image:tag

3.3 通过CI/CD自动化构建与推送

手动操作只是测试，自动化才是正道。以下是一个更完善、包含缓存优化和元数据标签的.gitlab-ci.yml示例：

variables: # 使用Docker层缓存来加速构建 DOCKER_BUILDKIT: 1 # 定义缓存镜像的标签 CACHE_TAG: "$CI_COMMIT_REF_SLUG" # 使用分支名作为缓存标签 # 定义缓存策略，将Docker构建缓存存储在GitLab的缓存中（适用于小型项目） cache: key: docker-$CI_COMMIT_REF_SLUG paths: - .docker/cache/ stages: - build - scan - deploy-staging # 阶段1：构建并推送镜像 build: stage: build image: docker:20.10.16 services: - docker:20.10.16-dind variables: DOCKER_TLS_CERTDIR: "/certs" script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY # 尝试拉取上一次构建的缓存镜像 - docker pull $CI_REGISTRY_IMAGE:cache-$CACHE_TAG 2>/dev/null || true # 构建，使用缓存 - > docker build --cache-from $CI_REGISTRY_IMAGE:cache-$CACHE_TAG --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA --tag $CI_REGISTRY_IMAGE:cache-$CACHE_TAG --file Dockerfile . # 推送本次提交的镜像和缓存镜像 - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA - docker push $CI_REGISTRY_IMAGE:cache-$CACHE_TAG # 如果是标签推送（即发版），打上版本标签 - | if [ -n "$CI_COMMIT_TAG" ]; then docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG fi artifacts: reports: dotenv: build.env # 将镜像标签传递给后续作业 after_script: - echo "IMAGE_TAG=$CI_COMMIT_SHORT_SHA" >> build.env # 阶段2：安全扫描（使用GitLab模板） container_scanning: stage: scan image: registry.gitlab.com/gitlab-org/security-products/container-scanning:latest variables: GIT_STRATEGY: none script: - /container-scanner artifacts: reports: container_scanning: gl-container-scanning-report.json rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_TAG # 仅在主分支或打标签时进行深度扫描 # 阶段3：部署到预发布环境 deploy-to-staging: stage: deploy-staging image: alpine:latest script: - echo "从仓库拉取镜像 $CI_REGISTRY_IMAGE:$IMAGE_TAG 并部署到Staging环境..." # 这里替换成你实际的部署命令，例如： # - kubectl set image deployment/my-app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n staging environment: name: staging url: https://staging.example.com rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 仅当合并到主分支后自动部署到staging

这个流水线实现了：

• 智能缓存：每次构建都会推送一个以分支名命名的缓存镜像，下次构建时复用，极大加速构建过程。
• 多标签管理：为每次提交生成唯一标签（$CI_COMMIT_SHORT_SHA），为发版生成版本标签（$CI_COMMIT_TAG），并维护一个缓存标签。
• 安全门禁：在主分支或发版时进行容器安全扫描，报告会集成到MR和仪表盘。
• 环境部署：自动将主分支构建的镜像部署到staging环境。

4. 运维、监控与故障排查

将Registry投入生产后，日常的运维监控和问题排查同样重要。

4.1 存储管理与垃圾回收

即使有清理策略，Registry底层的存储机制也可能产生“垃圾”。Docker Registry V2使用基于内容寻址的存储，当镜像被删除（标签删除）后，其对应的数据层（Blobs）不会立即物理删除，因为它们可能被其他镜像共享。这需要手动运行垃圾回收（Garbage Collection）。

垃圾回收步骤（在GitLab服务器上执行）：

1. 必须停止Registry服务：垃圾回收需要在独占模式下运行。

   sudo gitlab-ctl stop registry

2. 进入Registry控制台并执行GC：

   sudo gitlab-ctl registry-garbage-collect [选项]

   常用选项：
   • -m： 启用“删除未标记的Manifest”，这是清理空间的关键。
   • -d： 启用“删除未引用的Blobs”，删除不被任何Manifest引用的数据层。
   • --dry-run： 先试运行，查看会删除什么，但不实际执行。
3. 重启Registry服务：

   sudo gitlab-ctl start registry

实操心得与警告：

• 安排维护窗口：GC期间Registry不可用，务必在业务低峰期进行。
• 先做Dry-run：强烈建议先运行sudo gitlab-ctl registry-garbage-collect -m -d --dry-run，仔细检查输出，确认没有误删关键数据。
• 监控磁盘空间：GC能回收的空间取决于标签删除的“彻底程度”。如果清理策略已经运行良好，GC回收的空间可能有限。主要依赖清理策略进行日常管理，GC作为定期的深度清理（如每月一次）。
• 备份！：在执行GC前，确保你有完整的Registry数据备份。对于使用对象存储（如S3）的后端，GC操作同样重要，因为它会清理数据库中的引用关系并通知对象存储删除真正的文件。

4.2 监控与日志

健康的Registry需要被监控。

1. 日志位置：Registry日志通常与GitLab其他服务日志在一起。

   # Omnibus安装方式 sudo tail -f /var/log/gitlab/registry/current

   日志中会记录所有的push、pull、delete操作，以及错误信息。

2. 性能与健康指标：GitLab Registry暴露了Prometheus格式的指标端点（默认在/metrics）。你可以配置Prometheus来抓取，监控以下关键指标：

   • registry_storage_cache_*： 缓存相关指标。
   • registry_http_request_duration_seconds： 请求延迟。
   • registry_http_inflight_requests： 正在处理的请求数。
   • go_goroutines,go_memstats_*： Go运行时内存和协程数。

3. 集成GitLab监控：如果你使用了GitLab的Prometheus集成，这些指标可以自动收集并在GitLab的监控仪表板中查看。

4.3 常见问题排查实录

以下是我在运维中遇到的一些典型问题及解决方法：

问题1：docker push失败，报错“received unexpected HTTP status: 500 Internal Server Error”

• 可能原因： Registry后端存储（如本地磁盘或S3）权限不足、空间已满或网络问题。
• 排查步骤：
  1. 检查Registry日志 (/var/log/gitlab/registry/current)，通常会有更详细的错误信息。
  2. 检查磁盘空间：df -h。
  3. 如果使用S3，检查AWS凭证是否过期，S3 Bucket策略是否正确（需要PutObject,GetObject,DeleteObject等权限）。
  4. 检查网络连通性（如果使用外部存储）。

问题2：docker pull慢，尤其是首次拉取

• 可能原因： 网络延迟；镜像层太大；未配置缓存。
• 解决方案：
  1. 配置Registry前端缓存：可以在gitlab.rb中为Registry配置一个Redis作为缓存，缓存镜像Manifest和Blob的元数据。

  registry['cache'] = { 'blobdescriptor' => 'redis', 'redis' => { 'addr' => 'localhost:6379', 'password' => 'your-redis-password', 'db' => 0 } }

  2. 使用地理上更近的Runner：对于跨国团队，可以考虑在不同区域部署GitLab Runner，并配置其使用当地的Registry缓存代理（如registry-mirror）。
  3. 优化Dockerfile：减少镜像层数，使用.dockerignore文件排除不必要的上下文文件，使用多阶段构建减小最终镜像体积。

问题3：清理策略配置了但似乎没有执行

• 排查步骤：
  1. 进入项目，导航到“设置 > CI/CD > 容器镜像清理策略”，查看策略是否已启用，以及下次运行时间。
  2. 检查GitLab后台任务日志：sudo gitlab-rails tail_logs production。查找与container_expiration_policy相关的日志行。
  3. 确认项目有活跃的镜像推送活动。策略只会在有镜像被推送后的一段时间内触发评估。
  4. 检查Sidekiq队列。清理策略是一个后台作业，通过Sidekiq执行。查看Sidekiq是否正常运行：sudo gitlab-ctl status sidekiq。

问题4：GitLab Runner在CI作业中docker login失败

• 错误信息：Error response from daemon: Get "https://registry...": unauthorized: authentication required
• 可能原因：$CI_REGISTRY_PASSWORD等变量未正确传递或已过期；Runner配置的Docker守护进程未信任私有Registry的自签名证书。
• 解决方案：
  1. 确认Runner是Shell或Docker执行器，并且安装了Docker客户端。Kubernetes执行器需要额外配置。
  2. 对于自签名证书，需要在Runner所在的宿主机上（如果是Shell执行器）或Runner使用的Docker镜像中（如果是Docker执行器）信任证书。将CA证书放置于/etc/docker/certs.d/<your-registry-domain>/ca.crt，然后重启Docker守护进程。
  3. 在.gitlab-ci.yml中，确保docker login命令正确使用了变量。可以临时添加echo $CI_REGISTRY等命令调试变量值。

5. 进阶技巧与最佳实践

掌握了基本操作和故障排查后，一些进阶技巧能让你的镜像仓库管理更上一层楼。

5.1 使用镜像签名（Content Trust）

为了确保镜像的完整性和来源可信，可以启用Docker Content Trust (DCT)。这需要对镜像进行数字签名。GitLab Container Registry支持与Notary v2服务器的集成（在规划中或通过外部配置）。目前，一种实践是在CI流水线中，使用Cosign等工具对构建的镜像进行签名，并将签名存储在Registry中或单独的透明日志（如Rekor）中。这属于更高级的安全实践，在金融、医疗等强监管场景下尤为重要。

5.2 搭建地理级镜像缓存（Proxy）

对于全球分布的团队，从中心Registry拉取镜像可能非常慢。可以部署一个Registry代理缓存（如registry:2配置为proxy模式，或使用Harbor的代理缓存功能），将其配置为上游GitLab Registry的缓存。区域内的GitLab Runner则配置为从这个本地缓存拉取镜像。这能极大提升拉取速度，并减少中心仓库的出口流量。

5.3 细粒度权限控制

虽然项目级权限很方便，但有时需要更细的控制。例如，允许运维人员拉取所有项目的生产镜像，但禁止他们推送。这可以通过以下方式实现：

• 项目访问令牌：为自动化流程创建具有特定权限（仅read_registry）的令牌。
• 部署密钥：虽然主要用于代码拉取，但结合特定配置也可用于镜像拉取。
• 自定义角色（Ultimate版）：GitLab Ultimate版本支持自定义角色，可以创建如“镜像审计员”角色，仅授予读取容器注册表的权限。

5.4 生命周期管理与归档

并非所有旧镜像都需要立即删除。对于重要的发布版本（如v1.0.0,v2.0.0），即使它们不再活跃使用，也可能因合规或回滚需要而长期保留。最佳实践是：

1. 使用清理策略保护重要标签：用正则表达式^v\d+\.\d+\.\d+$保护所有语义化版本标签。
2. 归档古老项目：对于已下线项目的镜像仓库，可以考虑将其整体迁移到成本更低的归档存储（如S3 Glacier），并在GitLab中禁用或删除该项目对应的Registry条目，以保持活跃仓库的整洁。

我个人在管理多个大型项目的镜像仓库后，最大的体会是：“自动化策略优于手动操作，预防问题优于解决问题”。在项目初期就规划好标签命名规范、配置好清理策略和安全扫描，比后期面对数百GB的杂乱镜像和未知的安全漏洞要轻松得多。GitLab Container Registry的价值，正在于它将这些最佳实践工具无缝地编织进了你已经熟悉的开发工作流中，让你在享受容器化便利的同时，自然而然地建立起规范、安全、高效的制品管理体系。