Ответ
Основные проблемы, с которыми я работал:
-
Дрейф состояния (State Drift). Это самая частая проблема. Ресурсы в AWS изменяются в обход Terraform (через консоль, CLI, другие скрипты). В результате
terraform stateрасходится с реальностью. Для борьбы с этим мы:- Используем удаленный state-бэкенд (S3 + DynamoDB) с блокировками.
- Запрещаем ручные изменения в прод-окружении через политики IAM.
- Регулярно запускаем
terraform planдля обнаружения дрейфа, а для синхронизации —terraform applyили, в крайнем случае,terraform import.
-
Задержка в поддержке провайдера. Новые сервисы или фичи AWS (например, новые типы инстансов или параметры) иногда появляются в провайдере HashiCorp с задержкой. Временным решением может быть использование
awscliчерезlocal-execили терпение. -
Ограничения скорости AWS API (Rate Limiting). Массовые операции
terraform applyмогут упираться в лимиты AWS, вызывая ошибки типаThrottlingException. Мы решаем это:- Параметром
-parallelism=10(уменьшаем параллелизм). - Точечным применением изменений через
-target. - Стратегическим разделением конфигураций на несколько state-файлов.
- Параметром
-
Неявные зависимости. 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
]
}
- Временные ресурсы и eventual consistency AWS. Некоторые ресурсы (например, VPC endpoints, IAM роли) после создания не сразу становятся полностью доступными, что ломает последующие шаги в
apply. Помогает добавлениеsleepвprovisionerили разбивка деплоя на несколько этапов.