Digger项目中多环境Terraform部署的隔离方案实践

在Terraform多环境部署场景中，如何确保不同环境间的执行隔离是一个常见挑战。本文将以Digger项目为例，介绍一种通过配置文件分离实现环境隔离的解决方案。

问题背景

当使用Terraform管理多个环境（如开发环境和生产环境）时，通常会遇到以下情况：

1. 多个环境共享相同的模块代码
2. 每个环境需要独立的权限控制
3. 变更应仅影响目标环境

在Digger的默认配置中，当多个项目定义在同一个digger.yml文件中，且包含相同的模块路径时，修改模块代码会导致所有匹配的项目都被执行，这显然不符合预期。

解决方案

1. 分离配置文件

核心思路是为每个环境创建独立的Digger配置文件：

├── digger-dev.yml    # 开发环境配置
├── digger-prod.yml   # 生产环境配置
└── .github/workflows/
    └── digger_workflow.yml  # GitHub Actions工作流

每个配置文件只包含对应环境的项目定义，例如开发环境的digger-dev.yml：

projects:
  - name: dev
    dir: terraform/environments/dev
    workflow: dev
    include_patterns:
      - terraform/environments/dev/**
      - terraform/modules/**

2. 工作流配置调整

在GitHub Actions工作流中，通过digger-filename参数指定使用的配置文件：

jobs:
  digger-dev:
    steps:
      - uses: diggerhq/digger@v0.6.100
        with:
          digger-filename: digger-dev.yml
          # 其他参数...

3. 权限隔离机制

结合GitHub Environments功能，为每个环境配置独立的服务账号和权限：

• 开发环境使用开发服务账号
• 生产环境使用生产服务账号
• 通过GitHub Environments的环境保护规则控制部署权限

实现效果

这种方案带来了以下优势：

1. 精确的执行范围控制：修改模块代码时，只有目标环境会被触发
2. 清晰的权限边界：每个环境的执行使用独立的服务账号
3. 更好的可维护性：环境配置分离，减少误操作风险
4. 灵活的扩展性：新增环境只需添加新配置文件，不影响现有流程

最佳实践建议

1. 模块变更管理：当修改共享模块时，建议通过PR流程分别测试各环境
2. 环境命名规范：保持配置文件命名与环境名称一致，便于管理
3. 权限最小化：为每个环境服务账号授予最小必要权限
4. 日志隔离：为不同环境配置独立的日志存储位置

这种配置分离的方案不仅适用于Digger项目，对于其他基础设施即代码工具的多环境管理也有参考价值。通过合理的架构设计，可以在保持代码复用性的同时，确保环境间的严格隔离。