如何让Terraform同步DynamoDB PITR恢复的新表？最佳实践是什么？

我之前也碰到过类似的场景——手动用CLI恢复DynamoDB表后，得让Terraform接管新资源并同步相关配置，下面是具体的操作步骤和踩坑后总结的最佳实践：

1. 将PITR恢复的新表导入Terraform状态 #

因为A-Backup是通过AWS CLI创建的，不在Terraform的状态文件里，第一步得把它纳入Terraform的管理范围：

• 第一步：在Terraform配置中匹配新表属性
  你需要在.tf文件里添加aws_dynamodb_table资源块，确保配置的所有属性和实际恢复后的A-Backup表完全一致（包括PITR设置、读写模式、索引、标签等）。举个例子：

  resource "aws_dynamodb_table" "a_backup" {
    name           = "A-Backup"
    billing_mode   = "PAY_PER_REQUEST" # 和源表保持一致
    hash_key       = "user_id" # 源表的主键，必须匹配
    range_key      = "order_time" # 源表有排序键的话也要加上
  
    point_in_time_recovery {
      enabled = true # 保持PITR启用状态
    }
  
    # 如果源表有二级索引，完全照搬实际配置
    global_secondary_index {
      name               = "status-index"
      hash_key           = "order_status"
      projection_type    = "ALL"
    }
  }
  

• 第二步：执行导入命令关联资源
  在终端运行terraform import，把实际的DynamoDB表和上面定义的Terraform资源绑定：

  terraform import aws_dynamodb_table.a_backup A-Backup
  

• 第三步：验证配置一致性
  运行terraform plan，如果输出显示No changes. Your infrastructure matches the configuration.，就说明Terraform配置和实际资源完全对齐了。

2. 同步Lambda的环境变量配置 #

你之前手动改了Lambda的环境变量，现在要把这个变更写到Terraform配置里，确保后续由Terraform统一管理：

• 找到Lambda的Terraform资源定义，修改environment块中的表名字段：

  resource "aws_lambda_function" "order_processor" {
    # 其他基础配置（比如代码包、角色）...
  
    environment {
      variables = {
        TABLE_NAME = "A-Backup" # 替换为新表名
        # 其他环境变量保持不变
      }
    }
  }
  

• 运行terraform apply，让Terraform同步这个变更，以后Lambda的表名配置就不会再出现手动修改和代码不一致的问题了。

3. 相关最佳实践 #

• 优先用Terraform管理恢复流程
  以后再需要PITR恢复表，尽量直接在Terraform里配置，避免手动CLI操作。可以利用aws_dynamodb_table的restore_point_in_time参数直接创建恢复表，这样表从诞生起就在Terraform的管理之下，不需要事后导入。示例配置：

  resource "aws_dynamodb_table" "a_backup" {
    name           = "A-Backup"
    billing_mode   = "PAY_PER_REQUEST"
  
    restore_point_in_time {
      source_table_name = "A"
      restore_timestamp = "2024-05-20T14:30:00Z" # 指定要恢复的时间点
    }
  }
  

• 用远程状态存储避免分歧
  确保团队统一使用远程状态存储（比如AWS S3配合DynamoDB状态锁），这样导入表的状态变更能同步给所有成员，不会出现本地状态不一致的问题。
• 禁止手动修改Terraform管理的资源
  尽量不要手动改动Terraform已经接管的资源（比如Lambda的环境变量、DynamoDB的配置），所有变更都通过修改Terraform配置来完成，保证基础设施即代码的一致性。
• 文档化恢复同步流程
  把PITR恢复后同步Terraform的步骤写入团队运维文档，确保所有成员都清楚正确的操作路径，减少人为失误。
• 同步后做功能验证
  完成配置同步后，除了用terraform plan验证配置，一定要测试Lambda是否能正常读写新的DynamoDB表，确保业务功能不受影响。

内容的提问来源于stack exchange，提问作者codigube