多文件集中配置管理

多文件集中配置管理 | AI生成和翻译

Home 2025.12

问题：在一个Python脚本仓库中，该仓库从DB2转储数据并生成文件，其中环境（本地开发、UAT、生产）和三个国家代码（CN、TW、HK）具有不同的配置，将3 × 3 = 9个单独的.ini文件维护在中央仓库中是一个好主意吗？

回答：

不，你不应该在中央仓库中维护9个单独的.ini文件。这种方法容易出错、难以维护，并且违反了DRY原则。以下是更好的替代方案（从最推荐到可接受排序）：

推荐方法

一个单独的配置文件 + 环境变量（2025年最佳实践）

# config.ini (已提交)
[db2]
host_template = db2-{country}-{env}.example.com
port = 50000
database_template = PROJ{country.upper()}
    
[paths]
output_dir = /data/output/{country}/{env}

然后在运行时：

country = os.getenv("COUNTRY_CODE")      # cn, tw, hk
env     = os.getenv("ENV", "dev")        # dev, uat, prod

→ 仓库中没有敏感凭据，只有一个配置文件。

一个基础配置 + 国家特定覆盖（非常清晰） 仓库结构：
```
config/
  base.ini
  cn.ini
  tw.ini
  hk.ini
  env/
    dev.ini     → 通常为空或 logging=DEBUG
    uat.ini
    prod.ini
```
加载顺序：base.ini → {country}.ini → env/{env}.ini 每个国家只有几行不同（例如，SSL设置、模式前缀、日期格式、CN的加密密钥）。
单一配置文件，每个国家和环境都有单独的部分
```
[db2:cn:prod]
host = prod-db-cn.company.com
ssl = true
    
[db2:tw:uat]
host = uat-db-tw.company.com
ssl = false
```
最终只有一个文件，但仍有9个部分——比9个文件好，但更难阅读。
可接受但不理想：3个国家文件 × 3个环境文件 = 9个文件 仅当差异巨大且你永远不希望有任何共享值时才考虑。即使如此，也要使用脚本从模板生成它们，或者将它们放在版本控制之外（见下文）。

大多数团队在实际项目中是如何做的

只提交 config/base.ini + 国家覆盖文件 (cn.ini, tw.ini, hk.ini)
从不提交生产凭据
使用 .ini.example 文件作为模板
将真实的环境特定值放入环境变量或秘密管理器中（AWS Secrets Manager, Hashicorp Vault, Azure Key Vault等）
在本地开发中：local.env文件（添加到.gitignore）或direnv

多文件集中配置管理 | AI生成和翻译

推荐方法

大多数团队在实际项目中是如何做的

推荐的最终结构