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

Question

我主要将应用程序构建为 12 因素应用程序，现在正在研究配置部分。

目前，我有单独的用于开发和生产的配置文件，通过构建过程，我们可以构建开发或生产映像。代码100%相同；唯一改变的是配置。

现在我 100% 明白，在 12 因素应用程序中，配置应该来自外部源，例如：环境变量，或者可能是保险库等安全存储。

因此，各种文章和博客都没有提到配置是如何存储/处理配置的。如果代码单独存放在自己的 Git 存储库中，并且没有存储任何配置，那么我们如何处理配置呢？

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

Answer 1

没有标准，但我一直在观察一些常见的行为，例如：

1. 敏感信息永远不会进入版本控制系统，尤其是作为DVCS的 Git （您可以将存储库克隆到其他位置）。如果您不遵循，请记住，我们现有的“安全系统”是基于在特定时间内无法读取密码信息，但在某个时刻您可能能够读取该信息。通常在 Kubernetes 上，我看到操作员跨多个命名空间管理服务帐户，然后其他人仅引用服务帐户，欢迎使用 KMS、证书管理器、Vault 等工具

2. 像环境变量、端点这样的配置是用它们自己的“生命周期”来存储和版本控制的。

12factor并不意味着将应用程序的配置与存储库分开。相反，建议不要将其放入您的应用程序中（例如容器甚至二进制发行版中）。

事实上，如果您只想使用单独的存储库进行配置，您可以这样做，但是如果您想将项目源代码放在一边进行配置，您也可以这样做。这更多的是根据项目的规模、复杂性、职责划​​分和团队背景做出的决定。（恕我直言）

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