关于「在环境中存储配置」,是 The Twelve-Factor App 倡导的方法论之一。通常,应用的配置在不同环境(预发布、生产环境、开发环境等等)间会有很大差异,比如说数据库的用户名密码等等配置,通过把配置和代码分离,我们可以保证部署在不同环境的代码完全一致,如何把配置和代码分离呢?最佳实战是把配置存储到环境变量中,它可以非常方便地在不同的部署间做修改,却不动一行代码;与配置文件不同,不小心把它们签入代码库的概率微乎其微;此外环境变量与语言和系统无关。
在实际应用中,现在比较流行的解决方案是 dotenv(Ruby dotenv、PHP dotenv):首先创建一个 .env 文件,然后把配置信息都保存在里面,接着把这些信息加载的环境变量里,最后直接使用环境变量。
通过使用此方案,我们可以给不同的环境设置不同的 .env 文件,在一定程度上实现了配置和代码分离,可惜还有一些明显的缺点,比如:
- 如果有很多台服务器需要同步配置,那么是一件很痛苦的事情。
- 如果忘了把 .env 加入到 .gitignore,那么很有可能泄露敏感信息。
- 如果部署不当,那么很可能泄露敏感信息,比如这里。
通过引入服务发现机制可以解决多台服务器同步配置的问题,主流方案如下:
它们的实现机制类似,都是把配置保存在服务发现的存储里,一旦发生变化,可以自动通过模板技术静态化保存成本地文件,从而解决多台服务器同步配置的问题。
不过这些方案归根到底还是要需要静态化保存成本地文件的,有没有直接使用环境变量保存配置的解决方案呢?答案就是 envconsul,其工作原理如下:在 consul 中保存配置,然后 envconsul 启动后会加载配置,并通过环境变量的方式传递给子进程,此外 envconsul 还会通过 consul 的 http 接口以 long polling 的方式监听,一旦发现配置出现了变动,就会发送信号给子进程,从而完成配置的更新。
如果你已经安装好了 consul 和 envconsul,那么让我们来试一试(未考虑权限控制):
shell> consul kv put app/db/username root shell> consul kv put app/db/password 123456 shell> envconsul \ -pristine \ -sanitize \ -upcase \ -prefix app \ env DB_USERNAME=root DB_PASSWORD=123456
如上,我使用 env 命令作为 envconsul 的子进程来显示环境变量,实际使用中,你可以把 ruby,php 之类的应用作为 envconsul 的子进程,下面我用一个 shell 脚本来展示配置发生变化的时候 envconsul 是如何应对的,shell 脚本名为 test.sh,内容如下:
#! /bin/bash signals=(HUP INT QUIT TERM USR1 USR2) for signal in "${signals[@]}" do trap "echo $signal; exit" "$signal" done for i in {1..1000} do echo $i: PASSWORD: $DB_PASSWORD sleep 1 done
其作用就是监听信号,并且显示 DB_PASSWORD 环境变量,这次我们开启两个命令行窗口,一个运行 envconsul,另一个运行 consul kv put app/db/password … 来修改配置:
shell> envconsul \ -pristine \ -sanitize \ -upcase \ -prefix app \ /path/to/test.sh 1: PASSWORD: <OLD VALUE> 2: PASSWORD: <OLD VALUE> INT 1: PASSWORD: <NEW VALUE> 2: PASSWORD: <NEW VALUE>
我们能看到,当 envconsul 发现配置改变了之后,缺省情况下会发送 INT 信号(可配置)给子进程,使子进程完成重启,从而加载到新的配置。
此外还有一些细节问题需要考虑,比如:假设有一百台应用服务器,都是通过 envconsul 运行的,那么当配置发生变化的时候,如果这一百台应用服务器同时重启进程的话,无疑是一场灾难,实际上 envconsul 已经考虑到了此类情况,你可以通过配置 splay 选项把重启的时间随机化,避免「Thundering herd problem」;再假设配置发生变化的时候,如果子进程一直没有完成重启怎么办,envconsul 有一个 kill_timeout 选项,重启超时的话被直接强杀子进程。其它更多配置参见文档说明,篇幅所限,恕不赘述。
结尾再推荐一篇不同的声音:Why you shouldn’t use ENV variables for secret data,其以安全性为由,不建议使用环境变量,而是推荐使用 docker swarm 的密钥机制来管理敏感信息(相关教程),这很酷,如果你使用 docker,不妨一试。
回到 envconsul,环境变量仅针对子进程有效,虽然在一定程度上降低了风险,但是确实有可能泄露敏感信息,比如在 PHP 里,如果能运行 phpinfo 函数的话,那么可以打印出所有的环境变量,但我觉得不能因噎废食,以 PHP 为例,在生产环境中,类似 phpinfo,eval 之类的危险函数,原本就应该通过 disable_functions 禁用,而且数据库密码之类的信息,一般有 ip 访问限制,即便泄露了也影响有限,但这并不意味着可以不假思索的把任何信息都往环境变量里塞,比如银行卡密码,比特币密钥之类高度敏感的信息,如果泄露了就全完了,此时还是用 Vault 比较好,当然,envconsul 也支持 Vault。
评论前必须登录!
注册