Какой подход использует terraform при пересоздании ресурсов?

Подход Terraform к пересозданию ресурсов: принцип create-before-destroy

В Terraform стратегия пересоздания ресурсов управляется сочетанием двух ключевых механизмов: жизненного цикла ресурса (lifecycle) и внутренней логики планирования (plan). По умолчанию Terraform использует подход destroy-before-create — сначала удаляет старый ресурс, а затем создает новый. Однако это поведение можно и часто нужно менять на create-before-destroy через блок lifecycle.

Ключевые аспекты подхода

1. Управление через блок lifecycle

Основной инструмент — блок lifecycle внутри определения ресурса. Для явного указания стратегии create-before-destroy используется параметр create_before_destroy = true.

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true # Включаем стратегию "создать перед удалением"
  }
}

2. Когда и зачем это нужно?

Стратегия create-before-destroy критически важна для обеспечения нулевого или минимального времени простоя (downtime) при обновлении ресурсов, которые:

• Имеют уникальные идентификаторы или адреса (например, сетевые интерфейсы, EC2 instance с фиксированным IP).
• Являются частью цепочки зависимостей, где другие ресурсы полагаются на их стабильность (например, Load Balancer target group attachments).
• Без этой настройки удаление ресурса до создания нового может вызвать сбой в работе связанных систем.

3. Как это работает внутри Terraform?

При использовании create_before-destroy = true Terraform изменяет последовательность операций в плане:

1. Планирование: Terraform анализирует, что атрибут ресурса требует замены (например, изменился ami у EC2).
2. Создание нового ресурса: Сначала создаётся новый ресурс со всеми обновлёнными параметрами. Ему присваивается временное имя (например, aws_instance.web[1]).
3. Обновление зависимостей: Все ресурсы, которые ссылаются на этот, перенаправляются на новый объект.
4. Удаление старого ресурса: После успешного создания нового и обновления связей старый ресурс удаляется.

Без этой настройки последовательность была бы обратной: Destroy (старого) -> Create (нового).

4. Ограничения и соображения

• Квотирование и лимиты: Подход может временно требовать вдвое больше ресурсов (старый + новый), что может превысить квоты облачного провайдера.
• Имена ресурсов: Некоторые ресурсы (например, AWS IAM roles) имеют уникальные глобальные имена. Для них create_before_destroy может привести к конфликту имён. Решение — использовать name_prefix или генерируемые имена.
• Явные зависимости (depends_on): Нужно внимательно проверять явные зависимости, чтобы новый ресурс создался в правильном порядке относительно других.
• Состояние (State): Во время операции в state-файле временно существуют оба ресурса (старый и новый). После успешного завершения остаётся только новый.

5. Практический пример с балансировщиком нагрузки

Рассмотрим сценарий обновления EC2-инстанса в Target Group AWS:

resource "aws_instance" "app" {
  ami           = var.new_ami # АМИ изменён, требуется замена
  instance_type = "t3.micro"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_lb_target_group_attachment" "tg_attach" {
  target_group_arn = aws_lb_target_group.app.arn
  target_id        = aws_instance.app.id # Эта ссылка автоматически обновится на новый инстанс
}

Процесс:

1. Создаётся новый EC2 инстанс с новым AMI.
2. aws_lb_target_group_attachment автоматически перенацеливается с ID старого инстанса на новый (благодаря обновлению aws_instance.app.id в state).
3. Старый EC2 инстанс удаляется.
4. Балансировщик нагрузки всегда имеет активный целевой инстанс, downtime отсутствует.

Выводы и рекомендации

• Используйте create_before_destroy = true для ресурсов, критичных к доступности, таких как серверы приложений, базы данных (в связке с механизмами репликации), сетевые endpoint.
• Проверяйте квоты и уникальные идентификаторы перед применением.
• Тестируйте в немодификациях, используя terraform plan и terraform apply в тестовой среде, чтобы увидеть точную последовательность действий.
• Комбинируйте с другими параметрами lifecycle, такими как ignore_changes или prevent_destroy, для тонкого контроля над жизненным циклом инфраструктуры.

Таким образом, подход Terraform к пересозданию ресурсов не является фиксированным — это гибкий механизм, управляемый через декларативную конфигурацию. Стратегия create-before-destroy — мощный инструмент в арсенале DevOps-инженера для построения отказоустойчивой и высокодоступной инфраструктуры с минимальным временем простоя.