环境变量配置

目录:

• 摘要
  • 问题
  • 决策
  • 状态
• 详情
  • 假设
  • 约束
  • 立场
  • 论证
  • 影响
• 相关内容
  • 相关决策
  • 相关需求
  • 相关制品
  • 相关原则
• 备注

摘要

问题

我们希望应用的可配置性超出制品/二进制文件/源代码的范围,使同一个构建能够根据其部署环境表现出不同的行为。

• 为此,我们希望使用环境变量配置。

• 我们希望通过可以进行版本控制的文件来管理配置。

• 我们希望提供一些开发者体验上的便利,例如了解哪些内容可以配置以及相关的默认值。

决策

决定采用 .env 文件,并配有相关的默认值文件和模式文件。

状态

已决定。对出现的新功能持开放态度。

详情

假设

我们倾向于将应用代码与环境代码分离。我们假设应用需要在不同的环境中以不同的方式工作,例如开发环境、测试环境、演示环境、生产环境等。

我们推崇业界的“12 要素应用”(12 factor app)实践,更推崇与之相关的“15 要素应用”(15 factor app)实践。

我们以往的许多项目都沿用了 .env 文件或类似 .env 目录的约定。通常的做法是不将这些文件纳入版本控制,而是通过其他方式来部署、版本管理和管理它们。

约束

我们希望将密钥排除在源代码管理(SCM)版本控制系统(VCS)之外。

我们希望兼容流行的软件框架和库。例如,Node 有一个用于读取环境变量配置的模块“dotenv”。

立场

我们考虑了几种方法:

• 将配置存储在应用中,例如存储在 config.js 文件中。

• 将配置存储在环境中,例如存储在 .env 文件中。

• 从已知位置获取配置,例如从许可证服务器获取。

论证

我们选择了 .env 文件的方法,因为:

• 它很流行,包括在专家中也是如此。

• 它遵循 .env 文件的模式,我们的团队在许多项目中已多次成功使用过。

• 它很简单。需要特别说明的是,对于我们看到的重大权衡(例如与许可证服务器的方法相比缺少审计能力),我们目前可以接受。

影响

我们需要想出一种方法,将公开的环境变量配置与任何密钥管理分离开来。

相关内容

相关决策

我们期望所有应用都采用这种方法。

我们计划升级任何使用能力较弱的方法的应用,例如将配置硬编码在二进制文件或源代码中。

对于任何使用能力更强的方法(例如许可证服务器)的应用,我们将保持原样。

相关需求

我们将为这些文件增加 DevOps 能力,包括钩子、测试和持续集成。

我们需要就这一决策对所有开发人员队友进行培训。

相关制品

我们进行部署的每个区域都需要自己的 .env 文件和相关文件。

相关原则

易于撤销。

备注

示例文件 .env:

NAME=Alice Anderson
EMAIL=alice@example.com

示例文件 .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

仅包含键的示例文件 .env.schema:

NAME
EMAIL