CloudNativePG 项目中镜像推送失败问题的分析与解决

在 CloudNativePG 项目的持续集成过程中，开发团队发现了一个关于 Docker 镜像构建和推送的问题。该问题表现为在 CI 流程中，即使明确设置了不推送镜像的参数，系统仍然尝试将构建的镜像推送到远程仓库，最终导致构建失败。

问题背景

CloudNativePG 是一个开源的 PostgreSQL 操作符，用于在 Kubernetes 环境中管理 PostgreSQL 集群。在项目的持续集成流程中，使用 Docker Buildx Bake 工具来构建和测试容器镜像。正常情况下，CI 流程应该能够根据配置决定是否将构建的镜像推送到远程仓库。

问题现象

在 CI 执行过程中，尽管明确设置了 push: false 参数，构建系统仍然尝试将 ghcr.io/cloudnative-pg/cloudnative-pg-testing:startup-probe 镜像推送到 GitHub 容器注册表。由于缺乏必要的权限，这一操作失败并返回 403 Forbidden 错误。

技术分析

深入分析问题后发现，关键在于 Docker Bake 配置中输出类型的设置。默认情况下，当输出类型设置为 registry 时，Buildx 会强制尝试推送镜像，而忽略外部的推送参数设置。这种行为与预期不符，特别是在测试环境中，我们通常只需要构建镜像而不需要推送。

解决方案

经过技术团队的讨论和测试，确定了以下解决方案：

1. 修改 Docker Bake 配置文件，将输出类型从 registry 改为 docker，这样构建的镜像会保存在本地 Docker 守护进程中
2. 保留 push: false 参数以确保不会意外推送镜像
3. 在需要推送镜像的场景下，显式地设置 push: true 并确保有正确的认证凭据

这种修改既解决了当前的问题，又保持了构建流程的灵活性，可以根据不同环境的需要选择是否推送镜像。

实施效果

实施上述修改后，CI 流程能够正确识别推送设置：

• 在测试和本地开发环境中，成功构建镜像而不尝试推送
• 在正式发布环境中，可以正常推送镜像到指定仓库
• 构建过程更加稳定可靠，减少了因权限问题导致的失败

经验总结

这个案例提醒我们，在使用容器构建工具时需要特别注意：

1. 不同输出类型可能有不同的默认行为
2. 参数设置的优先级和覆盖关系需要明确
3. CI/CD 流程中的权限控制要谨慎处理
4. 测试环境的配置应该尽可能与生产环境隔离

通过这次问题的解决，CloudNativePG 项目的构建流程变得更加健壮，为后续的开发工作奠定了更稳定的基础。