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

Question

问题

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

问题

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

Answer 1

可识别的问题。

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

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

S3的替代方案可能是运行私有Git存储库（例如，AWS＆＃39; s CodecCommit）。由于您已经在使用Git，因此您可以更好地控制版本并让开发人员更轻松地进行更改。您仍然需要修复dev和ops之间的拆分访问权限，或者让它去（因为DevOps是关于信任和合作，这可能是一个好主意）。您可以在此处应用类似的模式，如上所述。

另一种解决方案可能是将敏感值的配置从属性文件移动到系统配置。当你已经使用像Puppet或Chef这样的配置系统时，对于操作人员来说这是很自然的。或者将所有敏感值（如密码）设置为环境变量，并让应用程序将其读作系统属性。

希望这有帮助！

Answer 2

我们一直在使用dynamodb来保存配置值。这种方法的优点是可以从控制台轻松读取值并进行验证。 另一个优点是我们定期检查来自dynamodb的值，因此如果需要更改任何值，我们只需更改它，应用程序会自动选择新值而不是再次启动它。 使用KMS密钥加密存储敏感值，并且只有运行应用程序的ec2角色才有权使用该密钥进行解密。 我们增强了Netflix archiaus项目以满足我们的需求。也许你可以检查一下。