根据部署环境(预发布环境、开发环境、生产环境等)的不同,服务的配置信息一般也会有所不同。由于各种原因,不能将服务的所有内容都放到工件中。
1)不能将密码凭据或者敏感的配置数据(比如数据库密码)以明文形式保存,也不可以将这些信息保存到源代码控制系统中。
2)特定于环境的配置数据(比如数据库URL 、日志等级或者第三方服务端点等)都会不同。
十二要素应用宣言中的第三个原则声称,将部署配置信息严格地从代码中剥离出来,并采用环境变量的方式来提供配置信息。实际上所选择的部署机制决定了存储和提供特定于环境的配置信息的方式。我们建议将配置信息保存到如下两个位置。
1)将非敏感配置数据保存到源代码管理系统中,和服务一起进行版本控制(通常以.env文件保存)。
2)将密码凭据信息保存到一个单独的、受到访问限制的“保险库”中(如HashiCorp中最为出名的vault)。
启动服务工件的进程应该拉取这些配置信息并将其注入应用的环境变量中。
遗憾的是,分别管理配置信息会增加风险,因为人们可以修改不可变工件之外的生产环境,从而影响部署的可预测性。开发者宁可过分约束,也要尝试在工件中包含尽可能多的配置,并依赖于部署流水线的速度和健壮性来快速更改配置。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论