С какими проблемами несоответствия между состоянием Terraform и реальной инфраструктурой в AWS вы сталкивались?

«С какими проблемами несоответствия между состоянием Terraform и реальной инфраструктурой в AWS вы сталкивались?» — вопрос из категории Terraform, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Основные проблемы, с которыми я работал:

  1. Дрейф состояния (State Drift). Это самая частая проблема. Ресурсы в AWS изменяются в обход Terraform (через консоль, CLI, другие скрипты). В результате terraform state расходится с реальностью. Для борьбы с этим мы:

    • Используем удаленный state-бэкенд (S3 + DynamoDB) с блокировками.
    • Запрещаем ручные изменения в прод-окружении через политики IAM.
    • Регулярно запускаем terraform plan для обнаружения дрейфа, а для синхронизации — terraform apply или, в крайнем случае, terraform import.
  2. Задержка в поддержке провайдера. Новые сервисы или фичи AWS (например, новые типы инстансов или параметры) иногда появляются в провайдере HashiCorp с задержкой. Временным решением может быть использование awscli через local-exec или терпение.

  3. Ограничения скорости AWS API (Rate Limiting). Массовые операции terraform apply могут упираться в лимиты AWS, вызывая ошибки типа ThrottlingException. Мы решаем это:

    • Параметром -parallelism=10 (уменьшаем параллелизм).
    • Точечным применением изменений через -target.
    • Стратегическим разделением конфигураций на несколько state-файлов.
  4. Неявные зависимости. Terraform не всегда корректно определяет порядок создания ресурсов. Например, политика IAM должна существовать до создания EC2-инстанса, который ее использует. Требуется явное указание depends_on.

resource "aws_iam_role_policy" "example" {
  # Создание политики...
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  iam_instance_profile = aws_iam_instance_profile.example.name

  # Явное указание зависимости, так как instance_profile использует роль с политикой
  depends_on = [
    aws_iam_role_policy.example
  ]
}
  1. Временные ресурсы и eventual consistency AWS. Некоторые ресурсы (например, VPC endpoints, IAM роли) после создания не сразу становятся полностью доступными, что ломает последующие шаги в apply. Помогает добавление sleep в provisioner или разбивка деплоя на несколько этапов.