我目前正在为通往客户新的Kubernetes群集的CI / CD管道进行设置，这些群集使用Helm和Azure DevOps Server在Harbour上托管，并且我对如何处理应用程序变量（设置问题）有些困惑在.NET Core中）。当前，这些变量作为发布变量存储在DevOps中，而某些Prod变量则由另一个组织管理。
我的想法一直是，我想要单独的Build和Deploy管道，由Build负责还原，构建，触发单元测试，最后将Docker映像推送到本地注册表。然后，使用多个Deploy管道来表示可能要使用Docker映像的各种环境（Dev，Test，Stage，Prod）和应用程序，并利用它们自己的配置。
但是，我一直无法找到一种方法，允许我在发布步骤中将发布管道中的变量注入到dockerized应用程序中，因为那时我所拥有的不是原始应用程序，而是Docker它的形象。我以前曾使用ConfigMaps来解决此问题，但是由于我无法在本地使用文件表示Prod环境，因此我需要某种方法从Azure Devops的发行版变量覆盖变量或生成ConfigMap。
某种程度上，我觉得这一定是一个常见的情况，但是我发现的大多数解决方案要么与在应用程序的存储库中维护面向环境的configmap或values文件有关，要么与使用看似Azure云的功能有关。
一种解决方案是将docker build / push步骤移入发布管道，并在对它们进行docker化之前将变量注入应用程序。但是，这感觉就像是一种骇客，只会导致同一应用程序产生大量Docker映像，但带有经过调整的appsettings文件，因此必须在多个环境中进行版本控制。
答案 0 :(得分：2)
您可以尝试通过Kubernetes manifest task处理此问题的方法。
在构建或发布管道中使用Kubernetes清单任务进行烘焙 并将清单部署到Kubernetes集群。
如果所有构建和部署都在Azure Pipelines中运行，那么您确实具有上一层，我们可以在将清单应用于群集之前进行这些替换。
可以在几个作用域级别定义变量，其中较直接的级别将覆盖最远的范围。
它还能够将相同的清单应用于两个环境（分段和生产），但设置不同
您也可以在以下博客中查看：