提升你的基础设施：精通 Terraform 的生命周期元参数

Source: Dev.to

引言

今天是 AWS 挑战的第 9 天，今天的重点在于昨天的主题：Terraform 生命周期元参数。此深度解析涵盖了基础设施即代码（Infrastructure as Code）中最关键的方面之一——资源生命周期的控制。虽然 Terraform 的默认行为在许多情况下已经足够，但生产系统通常需要精确的控制，以实现零停机时间的更新、保护关键数据以及处理复杂的混合管理场景。

create_before_destroy – 零停机时间的英雄

Terraform 通常会先销毁旧资源再创建新资源，这可能导致服务中断。将 create_before_destroy = true 设置为 true 会颠倒这一顺序：

• 工作原理： Terraform 先创建新资源，更新依赖（例如负载均衡器的目标组），随后再销毁旧资源。
• 使用场景： 对于位于负载均衡器后面的资源（如 EC2 实例或带有只读副本的 RDS 实例）的零停机部署至关重要。它支持一种简单、自动化的蓝绿部署策略。

resource "aws_instance" "blog_server" {
  # ... resource arguments ...

  lifecycle {
    create_before_destroy = true
  }
}

prevent_destroy – 生产环境的安全护栏

此安全特性可防止关键资源（例如生产数据库或敏感的 S3 桶）被意外删除。

• 工作原理： 将 prevent_destroy = true 设置后，任何针对该资源的 terraform destroy 都会因错误而失败。
• 使用场景： 保护有状态资源，如 RDS、关键的 S3 桶以及 ECR/EC2 密钥对。删除操作需要人为的手动步骤（例如临时注释掉该参数）。

resource "aws_s3_bucket" "critical_data" {
  # ... arguments ...

  lifecycle {
    prevent_destroy = true
  }
}

ignore_changes – 接受外部管理

当外部系统或人员修改资源属性时，Terraform 可能会不断尝试恢复原状，导致漂移。

• 工作原理： 指定 Terraform 在检测变化时应忽略的属性。
• 使用场景： 忽略对 Auto Scaling 组的 desired_capacity（由伸缩策略管理）的更改，或忽略监控代理添加的 EC2 实例标签。

resource "aws_autoscaling_group" "example_asg" {
  # ... arguments ...

  lifecycle {
    ignore_changes = [
      desired_capacity,
      tags,
    ]
  }
}

replace_triggered_by – 强制替换

有时即使自身配置未变，也需要在另一个资源变化时替换该资源。

• 工作原理： 当指定的依赖资源被替换时，包含 replace_triggered_by 的资源也会被替换。
• 使用场景： 强制在其引用的安全组更改时重新创建 EC2 实例，以支持不可变基础设施模式。

resource "aws_security_group" "app_sg" {
  # ... arguments ...
}

resource "aws_instance" "app_with_sg" {
  # ... arguments ...
  vpc_security_group_ids = [aws_security_group.app_sg.id]

  lifecycle {
    replace_triggered_by = [
      aws_security_group.app_sg.id,
    ]
  }
}

使用 precondition 与 postcondition 进行验证

这些参数允许你在资源创建前后强制执行组织标准。

precondition – 部署前的健康检查

• 工作原理： 定义一个必须在 Terraform 开始构建前求值为 true 的条件。如果为 false，部署将以自定义错误信息失败。
• 使用场景： 确保 AWS 区域在批准列表中，或验证必需的环境变量是否已设置。

postcondition – 部署后的验证

• 工作原理： 在资源创建或更新后运行，检查最终属性（self.attribute）。
• 使用场景： 验证关键标签（例如 Compliance 或 Environment）是否已应用，或确认模块输出符合预期格式。

resource "aws_dynamodb_table" "example" {
  # ... arguments ...

  precondition {
    condition     = contains(keys(var.resource_tags), "Environment")
    error_message = "Critical table must have Environment tag for compliance!"
  }

  postcondition {
    condition     = self.billing_mode == "PAY_PER_REQUEST" || self.billing_mode == "PROVISIONED"
    error_message = "Billing mode must be either PAY_PER_REQUEST or PROVISIONED!"
  }
}

关键要点

lifecycle 块并非每个资源都需要使用，但在大规模管理基础设施时是不可或缺的。正确使用它可以将不稳定、风险高的更新与稳健、协作、合规且零停机时间的部署流水线区分开来。