Terraform部署AWS Lambda Layer的即时一致性问题

问题描述 #

需求是通过Terraform实现：用Lambda Layer管理Python依赖（来自requirements.txt），仅当requirements.txt变更时才构建并上传Layer。

当前配置存在两次tf apply的问题：

• 稳定状态下修改requirements.txt
• 首次tf plan显示需替换null_resource.layer_code，data.archive_file.layer_code_archive将在apply阶段读取
• 首次tf apply仅本地构建Layer，AWS无实际变更
• 再次tf plan显示需替换aws_lambda_layer_version.dependencies_layer并更新aws_lambda_function.service_lambda
• 再次tf apply才完成AWS上的Layer和Lambda更新

曾尝试将dependencies_layer.source_code_hash设为requirements.txt的MD5值，虽实现单次生效，但部署后Terraform状态中保存的是实际Layer代码的哈希，导致后续tf plan始终显示不一致。

解决方案 #

1. 显式触发Layer更新的配置方案 #

核心思路是让Layer资源直接关联requirements.txt的变更，同时确保构建步骤与Layer资源的依赖链完整，实现单次apply完成所有变更：

# 1. 安装Python依赖到Lambda Layer指定目录，仅当requirements.txt变更时触发
resource "null_resource" "install_python_deps" {
  triggers = {
    # 用requirements.txt的哈希作为触发条件
    requirements_hash = filemd5("${path.module}/requirements.txt")
  }

  provisioner "local-exec" {
    command = <<EOT
      # 创建符合Lambda Layer结构的目录
      mkdir -p ./layer/python/lib/python3.9/site-packages
      # 安装依赖到目标目录（注意替换为你的Python版本）
      pip install -r ${path.module}/requirements.txt -t ./layer/python/lib/python3.9/site-packages --upgrade
      # 清理不必要的文件缩小包体积
      rm -rf ./layer/python/lib/python3.9/site-packages/*.dist-info ./layer/python/lib/python3.9/site-packages/__pycache__
    EOT
  }
}

# 2. 打包Layer目录为ZIP文件
data "archive_file" "lambda_layer_zip" {
  type        = "zip"
  source_dir  = "${path.module}/layer/python"
  output_path = "${path.module}/layer.zip"

  # 明确依赖安装步骤，确保打包在安装完成后执行
  depends_on = [null_resource.install_python_deps]
}

# 3. 创建AWS Lambda Layer版本
resource "aws_lambda_layer_version" "python_deps" {
  filename   = data.archive_file.lambda_layer_zip.output_path
  layer_name = "python-deps-layer"
  compatible_runtimes = ["python3.9"] # 匹配你的Lambda运行时

  # 用ZIP包的哈希作为版本标识，确保只有包内容变化时才创建新版本
  source_code_hash = data.archive_file.lambda_layer_zip.output_base64sha256
}

# 4. 关联Layer到Lambda函数
resource "aws_lambda_function" "my_lambda" {
  function_name = "my-service-lambda"
  runtime       = "python3.9"
  handler       = "lambda_function.lambda_handler"
  filename      = "${path.module}/lambda_function.zip"

  # 关联Layer，当Layer版本更新时自动触发Lambda更新
  layers = [aws_lambda_layer_version.python_deps.arn]
}

2. 关键逻辑说明 #

• null_resource.install_python_deps通过triggers绑定requirements.txt的哈希，只有当依赖清单变更时才重新安装依赖
• data.archive_file.lambda_layer_zip通过depends_on确保在依赖安装完成后再打包，避免Plan阶段读取到旧文件
• aws_lambda_layer_version.python_deps使用ZIP包的实际哈希作为source_code_hash，既保证了变更触发的准确性，又不会出现Terraform状态不一致的问题
• 整个依赖链是线性的：requirements.txt变更 → 安装依赖 → 打包ZIP → 更新Layer → 更新Lambda，单次apply即可完成所有操作

最佳实践 #

• 目录结构规范：严格遵循Lambda Layer的目录结构（python/lib/pythonX.X/site-packages），确保Lambda能正确加载依赖
• 清理冗余文件：安装依赖后清理.dist-info、__pycache__等目录，缩小Layer包体积，提升部署速度
• 版本匹配：确保pip install的目标Python版本与Lambda运行时一致，避免依赖兼容性问题
• 忽略构建目录：将layer/和layer.zip加入.gitignore，避免将本地构建产物提交到代码仓库
• 使用缓存：如果依赖安装耗时较长，可考虑使用本地缓存目录（如pip install --cache-dir）加快重复构建速度

关于多次Plan/Apply的问题 #

多次执行tf plan+tf apply属于不良实践，原因包括：

• 增加部署流程的复杂度，容易出现人为失误
• 导致Terraform状态在中间阶段不一致，可能引发后续变更冲突
• 降低部署效率，不符合基础设施即代码的自动化、一致性要求

内容的提问来源于stack exchange，提问作者A. Kali