Jenkins 什么'；存储12因素应用程序配置的过程是什么？

因此，我一直在构建我的应用程序，主要是作为12因素应用程序，现在查看配置部分

目前，我有单独的开发和生产配置文件，在构建过程中，我们要么构建开发映像，要么构建生产映像。代码是100%相同的，唯一改变的是配置

现在我100%地理解，在一个12因素的应用程序中，配置应该来自外部源，例如：环境变量，或者像vault这样的安全存储等等

因此，各种文章和博客都没有提到配置是如何存储/处理的。如果代码在它自己的git repo中分离，并且没有存储配置，那么我们如何处理配置

---

我们是否将实际配置值存储在单独的git上，然后通过使用某种触发器的构建过程在目标环境（Kubernet config map、marathon JSON config、Vault等）上合并/推送/执行这些值？

没有标准，但我观察到的是一些常见行为，如：

敏感信息永远不会进入版本控制系统，特别是git，它是一个DCV（您可以为其他位置克隆repo）。如果您不遵守，请记住，我们现有的“安全系统”是基于在特定时间内无法读取加密信息，但在特定时间点，您可能能够读取信息。通常在kubernetes上，我会看到运营商跨多个名称空间管理服务帐户，然后其他人只引用服务帐户，欢迎使用KMS、Cert manager、Vault等工具

配置与环境变量、端点一样，使用它们自己的“生命周期”进行存储和版本控制

这并不意味着要将应用程序的配置与存储库分开，而是建议不要将其放入应用程序中（例如容器上或二进制发行版上）

事实上，如果您只想对配置使用单独的repo，您可以这样做，但是如果您想将项目源代码放在配置之外，您也可以这样做。这更多的是基于项目规模、复杂性、职责分离和团队环境的决定。（IMHO）

---

例如，在我的研究案例中，在专用存储库上分离配置是有意义的，因为生产环境有50多个集群，其中一个集群有自己的隔离堆栈，还有不同的团队管理自己的服务并使用公共支持服务（db、api、streams…）。在我看来，只要事情变得更加复杂和交叉共享，在独立的存储库上分离配置就更有意义，因为在多个集群上有多个团队和资源。

目前，我们有buildImageDev和buildImageProd任务，它们使用conf-dev.json和conf-prod.json，并且与代码一起存在。代码100%相同，只是配置文件名发生更改。但也有一些情况，人们在将dev值复制到prod值时犯了剪切粘贴错误。另一种选择是与我们对待第三方应用程序的做法相同，并使用单独的回购来持有这些应用程序中每一个的配置。示例：卡夫卡、Elasticsearch等。。。因此，每个配置都有自己的回购协议。因此，我们也可以这样对待我们的应用程序。在这种情况下，我建议您在映像规范（dockerfile）中描述一个用于放置配置文件的卷，使应用程序（进程）读取该卷，否则将采用默认值，并在编排过程中，按podSpec上的键装载configmap，并使每个环境的configmap不同。或者，如果你的应用程序支持envvar，请尝试在配置文件上使用envvar参数化，因为这可能会给你一点额外的灵活性。是的，现在我将配置文件复制到图像中。但是，您将在哪里存储所有configmap值，相同的repo还是单独的repo？