Логика сохранения облачных данных Terraform

Поскольку вы не показываете нам политику роли iam для лямбда-функции, мне приходится догадываться.

Я чувствую, что роль iam и политика для лямбда имеют разрешение logs:CreateLogGroup. Так что лямбда-функция позаботится о creating log group if not exist.

При обновлении эта группа журналов не управляется terraform, она сообщит о проблеме.

Не могли бы вы удалить разрешение logs:CreateLogGroup и группу журнала, а затем повторить попытку?

1. Закомментируйте аргумент name

Пример выше, например:

resource "aws_cloudwatch_log_group" "lambda-deploy" {
  name = "/aws/lambda/${aws_lambda_function.lambda-deploy.function_name}"
  retention_in_days = "30"
}  

Становится:

resource "aws_cloudwatch_log_group" "lambda-deploy" {
  #name = "/aws/lambda/${aws_lambda_function.lambda-deploy.function_name}"
  retention_in_days = "30"
}

2. Импортировать ресурс

   terraform import aws_cloudwatch_log_group.lambda-deploy /aws/lambda/${aws_lambda_function.lambda-deploy.function_name}

Где ${aws_lambda_function.lambda-deploy.function_name} — это то, что у вас есть в AWS.

3. Раскомментируйте свой аргумент «имя» и запустите terraform plan, ваша группа журналов теперь управляется terraform ... уф!

ТЕХНИЧЕСКИ возможно определить, существует ли он, и при желании не создавать его. Гипотетически можно создать блок данных для импорта уже существующей группы журналов, а затем ресурс с динамическим счетчиком, чтобы включить или выключить его создание. Но вы бы не хотели делать это таким образом, этот странный хак навсегда остался бы в вашем инфракоде. Вы хотите, чтобы ваша терраформа была чистой и ориентированной на воссоздание вашей инфраструктуры с нуля.

Предполагая, что у вас уже есть лямбда, эта лямбда с AWSLambdaBasicExecutionRole создала собственную группу журналов вне terraform без настроек хранения, и теперь вы хотите добавить управление настройками хранения в terraform, у вас есть небольшая проблема. Terraform захочет создать эту группу журналов, потому что не знает о ее существовании, но не может, потому что это имя уже используется.

Таким образом, вам нужно импортировать существующую группу журналов, чтобы сопоставить ее с объявлением ресурсов, которое вы сделали в terraform. Затем, когда вы подадите заявку, terraform настроит существующую группу журналов в соответствии с вашей конфигурацией TF.

Этим утром я был именно в такой ситуации: мои лямбды (и другие вещи) создаются в модуле, который загружается примерно в 10 различных стеков (в 3 средах), и я не хотел делать это полностью вручную, поэтому я поделитесь этим небольшим набором команд bash, которые я собрал, чтобы упростить задачу. Это хакерство и зависит от (постоянно меняющегося) вывода консоли terraform, но для меня сегодня на Terraform v0.14.4 вывод приложения будет терпеть неудачу следующим образом:

Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve.

Enter a value: yes

module.api_gateway.aws_cloudwatch_log_group.this: Creating...

Error: Creating CloudWatch Log Group failed: ResourceAlreadyExistsException: The specified log group already exists: The CloudWatch Log Group 'API-Gateway-Execution-Logs_7pnv677kwa/0' already exists.

Следующие команды будут захватывать выходные данные применения, анализировать пространство имен ресурса и имя aws из последних двух строк, а затем выполнять импорт. Это не оптимизированный сценарий, просто то, что я собрал вместе, чтобы выполнить свою работу.

terraform apply 2>&1 | tee out.txt
resource=$(cat out.txt | sed -r "s/\x1B\[([0-9]{1,3}(;[0-9]{1,2})?)?[mGK]//g" | grep Creating | grep cloudwatch | cut -f 1 -d:)
name=$(cat out.txt | sed -r "s/\x1B\[([0-9]{1,3}(;[0-9]{1,2})?)?[mGK]//g" | grep Creating | grep exists | cut -f 2 -d\')
terraform import $resource $name
terraform apply
rm out.txt