我的应用程序主要构建为 12 因素应用程序，现在正在查看配置部分。
目前，我有单独的用于开发和生产的配置文件，通过构建过程，我们要么构建开发图像，要么构建生产图像。代码100%相同；唯一改变的是配置。
现在我 100% 明白，在 12 因素应用程序中，配置应该来自外部源，例如：环境变量，或者可能是像保险库这样的安全存储，等等。
因此，各种文章和博客都没有提到配置是如何存储/处理配置的。如果代码单独存放在自己的 Git 存储库中，并且没有存储任何配置，那么我们如何处理配置？
我们是否将实际配置值存储在单独的 Git 存储库中，然后通过构建过程使用某种方式在目标环境（Kubernetes 配置映射、marathon JSON 配置、Vault 等）上以某种方式合并/推送/执行这些配置值触发？
没有标准，但我观察到一些常见的行为，例如：
敏感信息永远不会进入版本控制系统，特别是 git，它是一个 DCVS（您可以将存储库克隆到其他位置）。如果您不遵循，请记住，我们现有的“安全系统”是基于在特定时间内无法读取加密信息，但在某些时候您可能能够读取该信息。通常在 kubernetes 上，我会看到操作员跨多个命名空间管理服务帐户，然后其他人仅引用服务帐户，欢迎使用 KMS、证书管理器、Vault 等工具
配置像环境变量、端点一样，使用自己的“生命周期”进行存储和版本控制。
12factor并不意味着将您的应用程序的配置与您的存储库分开，而是建议不要放入您的app中（例如在您的容器甚至二进制发行版中）。
事实上，如果您只想使用单独的存储库进行配置，您可以这样做，但是如果您想将项目源代码和配置放在一边，您也可以这样做。这更多的是根据项目的规模、复杂性、职责划分和团队背景做出的决定。 （恕我直言）
以我的研究为例，在专用存储库上单独配置是有意义的，因为生产环境有超过 50 个集群，其中一个集群有自己的隔离堆栈，而且还有不同的团队管理自己的服务并使用通用的支持服务（数据库、API、流...）。在我看来，只要事情变得更加复杂和交叉共享，在独立存储库上单独配置就更有意义，因为多个集群上有多个团队和资源。