应用被部署到不相同的运行环境中时, 是会用到属于自己环境的配置的, 比方说有叫做 Dev 的环境、叫做 QA 的环境、叫做 Stg 的环境以及叫做 Prod 的环境, 它们各自拥有属于自己的数据库等类型的资源。Boot 框架是可以采用对应的不同方式的, 让不同环境的程序在运行时去选择属于自己的配置文件, 其命名规则一般是遵循名称加上特定的环境标识符这样的方式来确定的。不过说话的人我个人还是比较偏爱把配置信息统一放在同一个文件里面, 并且通过分组的方式来组织这些配置信息的, 因为这样做的话在后面查找错误以及进行修改编辑的过程中会相对容易一点点的, 就像是会在某个特定的文件名后面再加上扩展名的文件中按照下面介绍的那样一种方式进行设置和配置一样。1db.hostaaa2%dev.db.hostbbb3%prod.db.hostccc那么在 的项目中应该如何针对不同环境下进行具体的配置呢? 从总体上来分析, 大概可以存在以下几种方式。存在适用于不同运行环境的配置文件, 这些配置文件的格式可以是类似于YAML风格的数据交换格式此处原文为“类YAML”, 或者是TOML文件、JSON文件、INI文件, 抑或是以.env结尾的环境变量文件。第一种方式是我本人所推荐的, 至于其余的那些方式, 无非是依托于不同格式的配置文件的, 按环境的分类来组织有所不一样的配置参数值的, 其余那些方式里边的不同的配置内容加载进入内存里面之后基本就是被体现成了字典那样的变量形式的存在的, 所以在相关的配置体系里边应当去支持类似于${host}这样的占位符的形式的像这样子的需求的还得靠使用者自己去完成具体的实现过程的。在不同的环境条件下, 相关的类会被放置在同一个文件中进行配置处理, 这样的安排便于通过点号来进行引用操作。1import os23class Config:4 DB_HOST 5 DB_USER sa67class DevConfig(Config):8 DB_HOST 910class QAConfig(Config):11 pass1213class ProdConfig(Config):14 DB_HOST 1516mapping {17 dev: DevConfig,18 qa: QAConfig,19 prod: ProdConfig20}2122APP_ENV os.environ.get(APP_ENV, dev).lower()23config mapping[APP_ENV]()使用1from config import config23print(config.DB_HOST)为了得到不同的值, 需要配置环境变量, 这些环境的名称是 dev、qa 或者是 prod。YAML 文件需安装依赖pip .yml 文件配置1default:2 db_host:34dev:5 db_host:67qa:89prod:10 db_host:使用1import yaml2from yaml import Loader34with open(config.yml) as ymlfile:5 cfg yaml.load(ymlfile, Loader)67print(type(cfg))8print(cfg)cfg 它是属于字典这一类型, 所以针对刚才那一种输出情况来讲呢, 就是下面的这一个。这个数据结构看起来长得很奇怪, 左边是大括号的空对儿, 里面套着空字典, 右边是dev、qa、prod这几块。现在要试着把环境变量的东西掺和进来。得从那个叫cfg的地方去拿配置的值。这么一结合, 思路大概是说要通过环境变量, 再从配置里取出对应的内容。1import os23APP_ENV os.environ.get(APP_ENV, dev).lower()4print(cfg.get(APP_ENV, default)[db_host])每一次去获取具体的数值都显得会有点麻烦, 其实有一种更为高级一点的操作方式, 就是让 YAML 格式的数据被序列化成一种你自己设定的对象类型, 接着在你自己写好的那个类里面进行各种处理, 比如说在新增的 YML 配置文件里需要明确地告诉程序要使用哪一个类的名称。1--- !Config23default:4 db_host:56dev:7 db_host:89qa:1011prod:12 db_host:然后对类进行定义, 并且在相关的配置项上使用相应的配置。1import yaml2from yaml import Loader3import os45APP_ENV os.environ.get(APP_ENV, dev).lower()67class Config(yaml.YAMLObject):8 yaml_tag u!Config910 def __int__(self, default, dev, qa, prod):11 self.default default12 self.dev dev13 self.qa qa14 self.prod prod1516 def __getitem__(self, item):17 env_conf getattr(self, APP_ENV) if hasattr(self, APP_ENV) else self.default18 env_conf env_conf if env_conf else {}19 return env_conf[item] if item in env_conf else self.default[item]202122with open(config.yml) as ymlfile:23 cfg yaml.load(ymlfile, Loader)2425print(type(cfg))2627print(cfg[db_host])上面的代码输出另外, 当把环境变量变成qa以及变得成prod的时候, 要去调整那些和它们相对应的cfg。这几个数值分别对应为。那个 TOML的文件, 也就是 TOML, 英文全称是 Toms , 乍一看它的格式好像是 ini那种文件的样子, 但实际上它比ini格式的厉害得多, 因为它支持各种各样很丰富的数据类型, 比如说布尔型的数据、整数数据的类型、浮点数这种类型、时间类型、还有日期类型、列表以及字典之类的, 下面是官方那边给出来的一个关于配置的具体样例。1# This is a TOML document23title TOML Example45[owner]6name Tom Preston-Werner7dob 1979-05-27T07:32:00-08:0089[database]10enabled true11ports [ 8000, 8001, 8002 ]12data [ [delta, phi], [3.14] ]13temp_targets { cpu 79.5, case 72.0 }1415[servers]1617[servers.alpha]18ip 10.0.0.119role frontend2021[servers.beta]22ip 10.0.0.223role backend那个项目的管理工具呢, 它其实就使用的是.toml这个文件类型, 专门用来对依赖配置进行相关管理的。在使用 toml 的时候, 通常都是采用普遍使用的安装方式。pip toml把前面的 .yml 文件转换为 .toml 文件内容如下1[default]34[dev]5db_host67[qa]89[prod]把那个 toml 文件给加载进来。1import toml23with open(config.toml) as tomlfile:4 cfg toml.load(tomlfile)56print(type(cfg))7print(cfg)输出为{: {: }, dev: {: }, qa: {}, prod: {: }}要取随 环境而变的 的话代码可实现为1import toml2import os34APP_ENV os.environ.get(APP_ENV, dev).lower()56class Config:7 def __init__(self, default, dev, qa, prod):8 self.default default9 self.dev dev10 self.qa qa11 self.prod prod1213 def __getitem__(self, item):14 env_conf getattr(self, APP_ENV) if hasattr(self, APP_ENV) else self.default15 env_conf env_conf if env_conf else {}16 return env_conf[item] if item in env_conf else self.default[item]171819with open(config.toml) as tomlfile:20 cfg Config(**toml.load(tomlfile))2122print(cfg[db_host])当我们将环境变量变更为qa以及prod以后, 系统将会输出对应的相应值。那个类里面的东西还有那个方法, 它们的实现方式都跟先前的一样。TOML这个配置文件的表现能力是很丰富的, 更强大的功能还有待于在以后的日子里去发掘。在JSON文件上面相应的配置文件, 变成扩展名为.json的格式, 这就是了。1{2 default: {3 db_host:4 },5 dev: {6 db_host:7 },8 qa: {},9 prod: {10 db_host:11 }12}使用代码1import json2import os34with open(config.json) as jsonfile:5 cfg json.load(jsonfile)67print(type(cfg))8print(cfg)910APP_ENV os.environ.get(APP_ENV, dev).lower()11env_conf cfg.get(APP_ENV)12env_conf env_conf if env_conf else cfg[default]13print(env_conf[db_host])输出{: {: }, dev: {: }, qa: {}, prod: {: }}进行切换环境变量测试, 以验证在不同环境下该值的正确性。利用 json.load() 这个函数, 也是可以把属于 JSON 样式的资料内容给反转过来, 弄成一个大家自己定义好的对象类型的东西的, 可要是直接就去拿那个叫作什么的参数去用, 想要把那些里头还有套着里头的 JSON 格式的数据, 给一下变成那种自定义的对象类型的话, 就不是那么容易做到的了, 可是只要是自己再另外搞一个什么方法来处理它的话, 那么操作起来就会和刚才前面提到过的那个什么是 YAML 的那个小例子差别不太大了。1import json23class Config:4 # 实现代码与前方 TOML 中的 Config 完全相同故省略56with open(config.json) as jsonfile:7 cfg Config(**json.load(jsonfile))8910print(cfg[db_host])或者, 整体来说的话, 那个Json对象是可以被转变成另外一个形式的。1from types import SimpleNamespacebr/br/2with open(config.json) as jsonfile:3 namespace json.load(jsonfile, object_hooklambda d: SimpleNamespace(**d))4 # 再把 namespace 转换为 Config 对象INI 文件ini 文件以前广泛应用在 中作为配置文件的格式 也内置了对它的支持格式上有点像 TOML 但它不支持嵌套类型。这里只提下 INI 文件的简单读取.ini1[default]34[dev]67[qa]89[prod]使用1import configparser23cfg configparser.ConfigParser()4cfg.read(config.ini)5print(type(cfg))6host cfg[dev][db_host]7print(host)输出为因为它仅仅存在一个层级的系列结构, 所以对于后续进行扩展操作来说是比较困难的, 在实际生活当中的使用场景也就变得相对狭窄了一些, 因此这里就不对其进行详细研究了。(.env) 文件的基本思路是这样的, 也就是把 (.env) 文件里面的配置给转换为环境变量, 然后呢就可以通过 os.(key) 这个方式去获取它了, 在效果上它相当于就是在 Linux 系统下面的那个环境配置文件 env.sh。1export DOMAINexample.org2export ADMIN_EMAILadmin${DOMAIN}然后env.sh相应的 和 就出现在了 env 列出的环境变量中在这上面, 拥有两个可以实现功能的相关软件库。首先需要进行第一步, 这个步骤就是安装。关于 pip , 我们是在当前的那个目录里面创建了一个 .env 配置文件, 并且这个文件里面的内容是。1# Development settings2DOMAINexample.org3ADMIN_EMAILadmin${DOMAIN}4ROOT_URL${DOMAIN}/app使用方式1from dotenv import load_dotenv2import os34load_dotenv()56print(os.environ.get(DOMAIN))7print(os.environ.get(ADMIN_EMAIL))输出这 () 是可以用来指定不同的文件的, 比如说呢, 我们就可以采用那种基于环境去区分开来的文件命名方式来进行操作。把文件给加载起来。1from dotenv import load_dotenv2import os34load_dotenv(.env) # 先加载默认的 .env 文件56APP_ENV os.environ.get(APP_ENV, dev).lower()7load_dotenv(f.env_{APP_ENV}, overrideTrue) # 再加载环境相关的89print(os.environ)首先, 系统会先把那个默认的 .env 文件给加载进去, 接着再去把那个和环境有关的对应文件也加载进来, 这样一来, 如果这个环境和默认文件里面有相同名字的属性, 环境和默认文件里面那个版本的配置就会被覆盖掉。还有一个 的实现 -, 但其中夹带了太多的私货, 如 .Env() 中有一些特定的配置项(, 等), 严格来说, 它算不上通用 实现。它加载 .env 文件时的行为与 - 类似。1import environ2import os34env environ.Env()56env.read_env() # 加载 .env 文件7APP_ENV os.environ.get(APP_ENV, dev).lower()89env.read_env(f.env_{APP_ENV}, overwriteTrue) # 加载环境相关的如 .env_qa1011print(os.environ)12print(os.environ[ADMIN_EMAIL])13print(env.str(ADMIN_EMAIL))在 .env 文件的配置里面, 具体的数值可以是不同的类型, 比如说 str, bool, int, 这样的。它也和某些东西类似, 都是把 .env 文件里面的配置信息加载到 os 这个模块里面去, 所以这样的话, 大家既可以依靠 os 这个模块来得到 .env 文件里面配置值, 也能够用它自己专门提供的那个 .Env() 的这个方法, 把对应的值给取出来。再来说说它比较薄弱的地方, 就是它对特定符号的解析并没有提供支持。这意味着在 .env 配置文件里写的 ${} 会原封不动地作为文字给输出出来。这个信息的永久链接是隔叶黄莺 s Blog , 我们来自这个链接。