如何管理程序的配置

我的生活经验使我深信，没有缺点的人往往优点也很少。
- 林肯

错综复杂的配置参数

通常习惯把程序的配置参数独立到一个 setting 的文件。在个人项目及小规模项目中，足矣。

但是接入了正规的研发流程之后，单单一个 setting 文件已经不能够解决问题。

本地开发环境 -> 联调环境 -> 提测环境 -> 预发布环境 -> 生产环境

当每个环境都有独立的数据库，依赖 web 接口时，配置文件就复杂了。

robots

如果继续使用单个 setting 文件

配置文件就变得异常恶心

if env == "dev":
    db = "1.1.1.2"
    ...
elif env == "dev_test":
    db = "1.1.1.3"
    ...
elif env == "test":
    db = "1.1.1.4"
    ...
elif env == "staging":
    db = "1.1.1.5"
    ...
elif env == "production":
    db = "1.1.1.6"
    ...

采用配置文件按环境分离的方式

setting   # 配置文件 - 存储通用的配置
settings  # 配置目录 - 存储环境独立的配置 
  |- dev          # 本地开发环境配置
  |- dev_test     # 开发人员用于联调的环境配置
  |- test         # 测试人员用于专门测试的环境配置
  |- staging      # 预发布环境的配置
  |_ production   # 生产环境配置

使用环境变量存储生产环境的多机集群配置，及互备配置

如果生产环境是多机集群，且多机互备呢? 这是上面方案所不能解决的问题。

例如，生产环境中，A、B、C、D 四台机器中的 A、B 互备，C、D 互备。
那么总不能专门为这四台机器再增加四个独立的配置文件吧，如果以后扩容到 100 台机器呢？

一种简单有效的方式就是把机器独立的配置写到环境变量中。

只对当前 shell 启动的进程生效的话，只需要

export MY_VAR=1

永久保存环境变量, 需要将 export 配置保存到配置文件中

~/.profile 适用于终端及 GUI 进程
~/.bashrc, ~/.bash_profile, ~/.bash_login 适用于终端

使用环境变量可能遇到的坑

如果有其他人的服务，或者自己另一个正在运行的服务，读取了与当前服务相同的环境变量，那么除非他也重启服务以更新环境变量，否则会一直使用旧的环境变量
如果要 sudo -u otheruser 来执行一个服务时，需要加上 -E 参数才能读到已配置的环境变量，参考: How do sudo environment variables work in linux?

成百上千台机器呢?

虽然至今还没接触过这么大的业务规模，但是设想一下手动更新部署一台机器的配置有多么繁琐就知道, 一定是需要一个配置管理中心的服务。

使用数据库管理所有机器的配置信息，配置变更及扩容都可实现自动化。

关于作者 🌱

我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”，查看更多联系方式