В компании несколько сотен Terraform-репозиториев/workspace использует один и тот же провайдер облака, и назрело обновление с мажорной версии провайдера, где часть аргументов ресурсов переименована и изменено поведение дефолтных значений. Массовое одновременное обновление версии во всех репозиториях рискованно и неконтролируемо. Как спроектировать процесс обновления версии провайдера/Terraform в масштабе всей организации, минимизируя риск масштабного инцидента?

Короткий ответ

Нужен поэтапный, измеримый rollout: сначала обновление и тестирование в небольшом наборе низкорисковых/некритичных репозиториев (canary), с обязательным прогоном terraform plan (а в идеале и apply в тестовом окружении) для выявления breaking changes из changelog провайдера; затем публикация внутреннего руководства по миграции (какие аргументы переименованы, как обновить код) и постепенное расширение на следующие волны репозиториев по владению командами, с мониторингом результатов каждой волны перед переходом к следующей, а не одновременное обновление версии во всех .tf файлах через глобальный find-and-replace.

Как это работает подробнее

мажорное обновление провайдера часто меняет не только имена аргументов, но и то, какие значения Terraform считает дефолтными, что может привести к незаметному для автора кода плану на изменение/пересоздание ресурса даже без изменений в самом .tf-файле; поэтому "план без видимых diff в коде" не гарантирует безопасность — обязательно нужен реальный terraform plan против обновлённого провайдера для каждого репозитория перед принятием изменения.

Сравнение

• Компромисс. Быстрое синхронное обновление версии во всех репозиториях сокращает время нахождения организации на устаревшей, потенциально небезопасной версии провайдера, но резко увеличивает площадь одновременного риска, если changelog содержит неочевидный breaking change. Поэтапный canary-rollout безопаснее, но означает, что часть организации дольше остаётся на старой версии, что может быть неприемлемо при наличии security-фикса именно в новой версии. Выбор темпа миграции должен явно учитывать, обновление вызвано security-патчем (быстрее) или плановым апгрейдом фич (медленнее, тщательнее).

Пример кода

main.tfКопировать

# шаг миграции: временно разрешить обе версии через constraint,
# чтобы команды мигрировали не одновременно
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0, < 6.0"   # временное широкое ограничение на время миграции
    }
  }
}
# централизованная проверка, кто ещё не обновился
$ grep -rl 'version = "~> 4' */required_providers.tf

Что использовать на практике

• Практика. для организации с сотнями repo полезно централизованно отследить, кто уже обновился (например, через сканирование required_providers во всех репозиториях), установить дедлайн для перехода на новую мажорную версию (так как провайдеры тоже имеют EOL старых версий), и иметь canary-группу, которая получает обновления провайдера раньше остальных и сигнализирует о проблемах, прежде чем остальная организация обновится.

Подводные камни

• Ошибка. Не выполняйте изменение без проверки плана, резервной копии состояния и понятного способа отката; для production согласуйте окно работ и исключите параллельные операции.