Terraform部署Image类型aws_lambda_function依赖ECR镜像的矛盾问题咨询

方案1：使用ignore_changes生命周期规则解耦（推荐生产使用） #

这是当前生产环境最通用的实现方案，不需要拆分模块，也不需要在Terraform中处理镜像上传逻辑，仅需对Lambda资源配置做少量修改：

resource "aws_ecr_repository" "image_storage" {
  name                 = "${var.project}/${var.environment}/lambda"
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

resource "aws_lambda_function" "executable" {
  function_name = var.function_name
  # 首次apply时使用任意公开的Lambda兼容镜像作为占位，比如AWS官方提供的运行时镜像
  image_uri     = "public.ecr.aws/lambda/go:latest"
  package_type  = "Image"
  role          = aws_iam_role.lambda.arn

  lifecycle {
    # 忽略Terraform对image_uri字段的变更，镜像版本统一由CI/CD流程负责更新
    ignore_changes = [image_uri]
  }
}

首次部署完成后，CI/CD推送自定义镜像到ECR后，直接调用AWS API更新Lambda的镜像地址即可，后续Terraform执行apply时不会覆盖CI/CD修改的镜像配置，完全符合基础设施管理和业务发布流程解耦的要求。

方案2：分阶段Apply无需修改配置 #

如果不想新增生命周期规则，也不需要拆分模块，首次部署时通过Terraform的目标参数分两步执行即可：

• 第一步仅创建ECR仓库：terraform apply -target=aws_ecr_repository.image_storage
• 待CI/CD完成镜像推送后，执行全量terraform apply创建Lambda资源
  该方案无需修改任何资源定义，后续日常迭代直接执行全量apply即可，不需要再指定target参数，适合对配置洁净度要求高的场景。

方案3：使用ECR镜像数据源保证依赖顺序 #

如果CI/CD镜像推送流程嵌入在Terraform执行链路中，可以通过aws_ecr_image数据源校验镜像存在性，避免报错：

resource "aws_ecr_repository" "image_storage" {
  name                 = "${var.project}/${var.environment}/lambda"
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

# 查询已推送的镜像，镜像不存在时该数据源会报错中断执行
data "aws_ecr_image" "lambda_image" {
  repository_name = aws_ecr_repository.image_storage.name
  image_tag       = "latest"
  depends_on      = [aws_ecr_repository.image_storage]
}

resource "aws_lambda_function" "executable" {
  function_name = var.function_name
  image_uri     = "${aws_ecr_repository.image_storage.repository_url}:${data.aws_ecr_image.lambda_image.image_tag}"
  package_type  = "Image"
  role          = aws_iam_role.lambda.arn
}

该方案适合Terraform和CI/CD深度集成的自动化部署流水线，能够自动校验镜像存在性再执行Lambda创建操作。

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