所以我一直将我的应用程序主要构建为12因子应用程序，现在着眼于配置部分。
目前，我已经为开发和生产使用了单独的配置文件，在构建过程中，我们可以构建开发或生产映像。代码是100％相同的，唯一更改的是配置。
现在，我100％理解，在12因子应用程序中，配置应来自外部来源，例如：环境变量，或诸如Vault之类的安全存储库...
因此，各种文章和博客都没有提及该配置是如何存储/处理该配置的。如果代码是在自己的git repo中分开的，并且没有存储配置，那么我们该如何处理配置？
我们是否将实际的配置值存储在单独的git上，然后通过一些构建过程来在目标环境（Kubernet配置图，马拉松JSON配置，Vault等）上合并/推送/执行配置值触发什么？
答案 0 :(得分：2)
没有标准，但是我一直观察到的是一些常见的行为，例如：
敏感信息永远不会进入版本控制系统，尤其是git，它是DCVS（您可以在其他位置克隆存储库）。如果您不遵循，请记住我们现有的“安全系统”是基于一定时间内无法读取加密信息的，但是在某些时候您可能能够读取该信息。通常在kubernetes上，我看到运营商在多个命名空间中管理服务帐户，然后仅引用服务帐户，欢迎使用KMS，证书管理器，保险柜等工具
配置（如环境变量，端点）使用其自己的“生命周期”进行存储和版本控制。
12factor并不意味着将应用程序的配置与存储库分开，而是建议不要将其放入 app 中（例如在容器中或甚至二进制分布）。
实际上，如果您只想为配置使用单独的存储库，则可以执行此操作，但是，如果要将项目源代码的配置放在一边，则也可以这样做。它更取决于项目的规模，复杂性，职责划分和团队环境。 （恕我直言）
例如，在我的研究案例中，在生产环境中有50多个集群是很有意义的，因为在生产环境中有50多个集群，其中一个集群拥有自己的隔离堆栈，也有不同的团队来管理自己的服务并使用共同的支持服务（db，api，流...）。我认为，只要事情变得更加复杂和交叉共享，就可以在独立存储库上分离配置，因为在多个集群上有多个团队和资源。