Docker Build-Push Action 中多仓库认证的最佳实践

在使用Docker Build-Push Action进行容器镜像构建和推送时，很多开发者会遇到多仓库认证的问题。本文将以一个典型场景为例，介绍如何正确配置工作流以实现同时向Docker官方仓库和Azure容器注册表推送镜像。

常见问题场景

开发者在使用GitHub Actions工作流时，可能会遇到这样的情况：虽然成功登录了Docker官方仓库，但后续的镜像推送操作却失败。这通常是由于多个认证步骤之间的配置冲突导致的。

问题根源分析

在原始的工作流配置中，开发者使用了两个不同的登录Action：

1. docker/login-action用于Docker官方仓库认证
2. Azure/docker-login用于Azure容器注册表认证

问题在于，Azure/docker-login会覆盖Docker的配置文件，从而清除之前docker/login-action设置的Docker官方仓库凭证。这导致了虽然登录成功，但推送时认证信息已丢失的情况。

解决方案

正确的做法是统一使用docker/login-action来处理所有容器注册表的认证。这个Action设计时就考虑到了多仓库认证的场景，能够妥善管理不同注册表的凭证。

更新后的配置示例如下：

- name: Login to Docker官方仓库
  uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

- name: Login to Azure Container Registry
  uses: docker/login-action@v3
  with:
    registry: yourregistry.azurecr.io
    username: ${{ secrets.AZURE_REGISTRY_USERNAME }}
    password: ${{ secrets.AZURE_REGISTRY_PASSWORD }}

最佳实践建议

1. 保持Action版本更新：始终使用最新稳定版的Action，避免使用已停止维护的版本。

2. 统一认证管理：对于多仓库场景，建议使用同一个登录Action来处理所有认证，避免凭证被意外覆盖。

3. 合理组织工作流步骤：确保认证步骤在构建推送步骤之前完成，并且中间没有会干扰认证信息的操作。

4. 安全存储凭证：使用GitHub Secrets存储敏感信息，不要直接在配置文件中硬编码。

通过遵循这些最佳实践，开发者可以避免常见的认证问题，确保容器镜像能够顺利推送到多个目标仓库。