我一直在构建我的应用程序，主要是作为一个12因素的应用程序，现在正在寻找配置部分。
现在，我有单独的开发和生产配置文件，在构建过程中，我们要么构建开发镜像，要么构建生产镜像。代码是100%相同的;唯一改变的是配置。
现在我100%理解了在一个12因素的应用程序中，配置应该来自外部资源，比如：环境变量，或者像保险库这样的安全存储，等等。
因此，各种文章和博客都没有提到配置是如何存储/处理的。如果代码在自己的Git存储库中分离，并且没有存储任何配置，那么我们如何处理配置？
我们是否将实际的配置值存储在一个单独的Git存储库中，然后在构建过程中使用某种触发器在目标环境（Kubernetes配置Map，马拉松JSON配置，Vault等）上以某种方式合并/推送/执行这些配置值？
1条答案
按热度按时间4nkexdtk1#
没有一个标准，但我一直在观察一些常见的行为，如：
1.敏感信息永远不会进入版本控制系统，特别是Git，它是一个DVCS（你可以克隆仓库到其他位置）。如果你不遵循，请记住我们现有的“安全系统”是基于在特定时间内无法阅读加密信息，但在某个时候你可能可以读取信息。通常在Kubernetes上我看到运算符，跨多个命名空间管理服务帐户，然后其他仅引用服务帐户，如KMS，Cert Manager，Vault等工具是受欢迎的
1.配置，如环境变量、端点，都是按照自己的“生命周期”存储和版本化的。
12factor并不意味着将应用程序的配置与仓库分离，而是建议不要将其放入应用程序中（例如容器或二进制分发）。
事实上，如果你只想使用一个单独的存储库进行配置，你可以这样做，但是如果你想把你的项目源代码放在一边进行配置，你也可以这样做。这更多的是一个基于项目的大小，复杂性，职责分离和团队背景的决定。
例如，在我的研究案例中，将配置分离到专用存储库中是有意义的，因为生产环境有50多个集群，每个集群都有自己的隔离堆栈。（数据库，API，流等）。在我看来，只要事情变得更加复杂和交叉共享，将配置分离到独立的存储库中就更有意义，因为在多个集群上存在多个团队和资源。