OSSF Scorecard项目从Container Registry迁移到Artifact Registry的技术实践

Google Cloud宣布将于2025年逐步淘汰Container Registry服务，全面转向Artifact Registry。作为依赖Google Cloud容器服务的开源项目，OSSF Scorecard团队面临着从Container Registry(gcr.io)迁移到Artifact Registry的重要任务。本文将详细介绍这一迁移过程的技术细节、挑战和解决方案。

迁移背景与时间节点

Google Cloud Container Registry的淘汰计划分为三个阶段：

1. 2025年3月18日起，禁止向Container Registry写入新镜像
2. 2025年5月20日起，禁止从Container Registry读取镜像
3. 2025年7月17日起，所有gcr.io端点将完全由Artifact Registry提供服务

对于OSSF Scorecard项目而言，这意味着需要在此之前完成所有容器镜像的迁移工作，确保CI/CD流程和用户使用不受影响。

项目容器镜像现状分析

OSSF Scorecard项目在Container Registry中维护了多个关键镜像，主要分为两类：

面向用户的公共镜像

• scorecard：核心评分工具镜像
• scorecard-action：GitHub Action使用的镜像
• scorecard-attestor：认证相关镜像(可能)

内部基础设施镜像

• scorecard-batch-controller
• scorecard-batch-worker
• scorecard-bq-transfer
• scorecard-cii-worker
• scorecard-github-server
• scorecard-webhook-releasetest

经过分析，项目积累了约18,000个镜像，总存储量约350GB。按照Artifact Registry的定价模型，这将产生每月约35美元的费用。

迁移策略与技术实现

团队制定了以下迁移策略：

1. 镜像筛选与保留

考虑到历史镜像数量庞大，团队决定：

• 保留所有带有语义版本标签的公共镜像(如v1.0.0、v2.1.3等)
• 保留latest和stable等关键标签
• 使用Google提供的迁移工具配合--recent-images参数，仅迁移最近30-180天内被拉取过的镜像

2. 镜像拉取与标记

为确保关键镜像被识别为"最近使用"，团队编写了自动化脚本批量拉取所有带标签的镜像。例如对于scorecard镜像：

versions=(
    latest
    stable
    v5.1.1
    v5.1.0
    # 其他版本...
)

for i in "${versions[@]}"; do
    docker pull gcr.io/openssf/scorecard:$i
done

3. 镜像存储优化

为减少未来存储开销，团队实施了以下优化措施：

• 将Scorecard主镜像发布到GitHub Container Registry(GHCR)
• 为Scorecard Action添加定期清理未标记镜像的工作流
• 评估将cron基础设施迁移到GHCR的可行性

迁移过程中的技术挑战

在迁移过程中，团队遇到了几个技术问题：

1. 镜像写入异常

尽管官方文档称Container Registry已停止写入，但实际上仍能间歇性工作。这导致团队需要同时处理迁移和日常构建任务。

2. 稳定版本更新中断

团队发现最新的stable镜像已三周未更新。经排查，这是由于间接依赖的GCS存储库更新导致的错误处理变化。具体来说：

• Google Cloud Go库更新开始包装某些错误
• 直接依赖的gocloud.dev因需要Go 1.24而被Dependabot忽略更新
• 错误处理逻辑变化导致shard处理失败

解决方案有两种：

1. 提前升级到Go 1.24以兼容最新gocloud.dev
2. 修改错误检查逻辑，显式处理storage.ErrObjectNotExist错误

团队选择了第二种方案作为临时修复：

ret, err := bucket.Exists(ctx, key)
if err != nil && !errors.Is(err, storage.ErrObjectNotExist) {
    return ret, fmt.Errorf("error during bucket.Exists: %w", err)
}

迁移后的验证与监控

完成迁移后，团队进行了全面验证：

1. 确认所有带标签的镜像已成功迁移
2. 验证CI/CD流程在新registry下的工作状态
3. 监控stable标签的自动更新机制
4. 确保用户-facing的镜像(latest/stable)保持可用性

经验总结与最佳实践

通过这次迁移，OSSF Scorecard团队总结了以下经验：

1. 尽早规划迁移：在服务淘汰前留出充足时间处理意外问题
2. 镜像分类管理：区分用户-facing和内部镜像，制定不同的保留策略
3. 自动化验证：编写脚本验证关键镜像的可用性
4. 依赖管理：密切监控间接依赖的变更可能带来的影响
5. 多registry策略：考虑使用GHCR等替代方案分散风险

这次迁移不仅解决了服务淘汰带来的挑战，也为项目未来的容器镜像管理奠定了更可持续的基础。通过优化存储策略和引入多registry支持，OSSF Scorecard项目在保证服务连续性的同时，也提升了基础设施的健壮性。