我为 Azure DevOps 创建了一个多阶段构建管道，将构建的映像推送到 Docker Hub。我现在正在尝试建立一个发布管道，该管道将使用该图像作为其构建工件。我已经使用我配置的服务连接设置了所有这些，并且 Azure 构建管道成功运行到完成，但是我不知道如何在使用时参考工件，例如kubectl 将该镜像推送到我的 Kubernetes 集群中。
【问题讨论】：
标签： docker azure-devops azure-devops-pipelines
我们所做的大部分工作就像我们在 多阶段 构建的最后一个推送步骤一样。 （我们也有相同的步骤来标记图像以消除混淆）
- id: 'push the docker image to registry'
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA']
我们目前正在使用 GCR。
所以当构建被推送到注册表时，它将创建一个基于URI的自动变量设置到CI/CD .
在 release CI/CD 触发器中，我们有步骤将映像连同环境变量一起推送到 Kubernetes 集群。
- id: 'set docker image URI in YAML file'
name: 'ubuntu'
args: ['bash','-c','sed -i "s,DOCKER_IMAGE_NAME,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," deployment.yaml']
它将 YAML 文件值替换为 docker 映像 的 URI，其中所有内容都来自 env 变量，并创建了泊坞窗图像路径。最后将整个 deployment.yaml 文件应用到 Kubernetes 集群。
如果您想使用特殊的提交哈希进行修补或部署，在这种情况下，您可以通过将值设置为 CI/CD 触发器并运行它来覆盖 SHORT_SHA 值。
因此，您的构建触发器将不断构建并将图像推送到注册表，并且只要您想部署，您就可以运行发布trigger 默认情况下，它将从 Git 中获取 latest commit hash 并将其设置为 环境变量。
【讨论】：
问题主要在于我在 Docker 步骤中使用了build 命令，而不是buildAndPush，因此在创建和标记图像时，它没有被推送到存储库。一旦我解决了这个问题，发布管道就会正确地检查刚刚运行的构建管道创建的图像作为人工制品；我只是确保发布管道使用版本号作为版本号，然后用相同的标签检索图像是小菜一碟。
正如经常发生的那样，键盘和椅子之间存在问题。用新的眼光和清晰的思路再看一遍，并试图向同事解释问题，让问题跳出屏幕。
【讨论】：