在多个环境之间管理配置文件的方法

Question

问题

我们使用java WAR文件并将配置文件保存在s3存储桶中.我们的环境:DEV,QA,Stage和PROD都有自己的配置文件和s3桶.如果我添加一个新字段,例如"Polling_RATE = 5000",则必须手动将其添加到每个env,因为这些配置文件还存储密码,因此它们不能绑定到应用程序或保存在Github中.并非每个工程师都可以访问每个环境,因此您必须记住在prod部署日期之前通知上级工程师(DEVOPS),以便为应用程序添加新字段.这是一个非常混乱的过程.

题

是否有用于处理此问题的实用程序或架构设计模式？你如何"版本控制"你无法存储在github中的敏感配置字段？

Answer 1

可识别的问题。

通常，包含密码等敏感信息的配置字段的更改频率比非敏感配置字段要少得多。一个可能的解决方案是将配置分为两部分：

1. 特定于环境但不包含敏感信息的配置。我建议您将这些文件与源代码放在一起，如果可能的话，生成文件并在构建时自动上传到您的配置存储（在您的情况下为 S3）。它们必须进行版本控制并与您的应用程序版本相关联。
2. 包含敏感信息的配置。从问题来看，并非所有团队成员都被允许读取/写入此信息。您可以将它们存储在具有特定访问权限的 S3 中，以便只有授权成员才能访问它们。您需要一种机制来在部署时将文件重新连接在一起，或者更改应用程序以从不同的配置文件中读取。
   但是，这只能解决您的部分问题。当敏感的配置键发生变化时，操作人员仍然需要执行更改。这是否可以接受取决于敏感配置键更改的频率。

S3 的替代方案可以是运行私有 Git 存储库（例如AWS 的CodecCommit ）。由于您已经在使用 Git，因此您将拥有更好的版本控制，并且开发人员可以更轻松地执行更改。您仍然需要解决开发和运维之间的访问权限分割问题，或者放弃它（因为 DevOps 是关于信任和合作，这可能是一个好主意）。您可以在此处应用与我上面描述的类似的模式。

另一种解决方案可能是将敏感值的配置从属性文件移至系统配置。当您已经使用 Puppet 或 Chef 等供应系统时，这对于运维人员来说会感觉很自然。或者将密码等所有敏感值设置为环境变量，并让应用程序将其读取为系统属性。

希望这可以帮助！