我目前正在使用Helm和Azure DevOps Server为我的客户的新Kubernetes集群设置一个CI/CD管道，这些集群托管在Harbor上，我有点拘泥于如何以简化的方式处理应用程序变量(.NET Core中的appsettings(。目前，这些变量作为发布变量存储在DevOps中，一些Prod变量由另一个组织管理。
我的想法是，我想要单独的Build和Deploy管道，Build负责恢复、构建、触发单元测试，并最终将Docker映像推送到预注册中心。然后，使用多个Deploy管道来表示各种环境(开发、测试、阶段、生产(和可能希望使用Docker映像的应用程序，利用它们自己的配置。
然而，我还没能找到一种方法，让我在发布步骤中将发布管道中的变量注入到码头化的应用程序中，因为到那时我所拥有的不是我的原始应用程序，而是它的Docker映像。我以前曾使用ConfigMaps来解决这个问题，但由于我无法在本地拥有代表Prod环境的文件，我需要一些方法来覆盖变量，或者从Azure Devops的发布变量生成ConfigMap。
不知何故，我觉得这一定是一种常见的场景，但我发现的大多数解决方案要么与在应用程序的repo中维护面向环境的配置映射或值文件有关，要么与使用Azure Cloud特有的功能有关。
一种解决方案是将docker build/push步骤移动到发布管道中，并在将变量固定化之前将变量注入到应用程序中。然而，这感觉像是一次黑客攻击，只会导致同一应用程序的无数Docker映像，但会有一个经过调整的appsettings文件，因此必须在多个环境中进行版本控制。
您可以尝试通过Kubernetes清单任务来处理此问题。
在构建或发布管道中使用Kubernetes清单任务来烘焙并将清单部署到Kubernetes集群。
如果您的构建和部署都在Azure Pipelines中运行，那么在将清单应用到集群之前，您确实有一个上一层，我们可以在其中进行这些替换。
变量可以在几个范围级别上定义，其中更直接的级别将覆盖最远的级别。
它还能够将相同的清单应用于两个环境(暂存和生产(，但具有不同的设置
你也可以看看下面的博客：
- 如何使用Azure在Kubernetes清单中注入变量管道
- 使用Azure DevOps部署到Kubernetes：第一步
根据12因素，将环境相关配置放入集群的最佳方法是使用环境变量。有更好的安全性和各种工具可以将配置文件导入环境变量，如果你的应用程序可以从那里而不是文件中获取配置文件，那么这会更好。
然而，如果你的应用程序不能，那么我就是这样做的，使用Azure DevOps:将可定制的配置和清单注入到发布中
在生成管道中，将标记化的配置和清单发布到文件夹中。
在发行版中，使用文件夹上的"替换令牌"任务将令牌交换为变量。
使用kubectl任务从文件创建一个configmap，该文件将保存替换的配置文件，并使其成为部署清单中的一个卷。
您的应用程序应该期望文件在此位置，或者将这些文件复制到期望的位置。我在dockerfile中这样做，并为我的入口点提供了一个脚本。
我使用kube部署步骤在部署清单中的映像末尾添加一个标记，然后部署到集群。
当pod启动时，configmap被创建为一个卷，应用程序以该环境的最新配置启动。