Terraform и IaC

Terraform — декларативный Infrastructure-as-Code инструмент: вы описываете желаемое состояние в HCL, а он приводит реальную инфраструктуру к нему. plan показывает разницу конфига и state, ничего не меняя; apply применяет эту разницу — создать, изменить или удалить — и пишет результат в state.

State сопоставляет каждый ресурс конфига с реальным объектом, который создал Terraform, и его атрибуты. Это источник истины, с которым сравнивает plan — поэтому его нельзя терять или править руками. Значения хранятся в открытом виде, включая секреты, так что state надо защищать.

Дрейф — это расхождение реальной инфраструктуры с тем, что записано в state, обычно из-за изменения вне Terraform, например правки в консоли. plan обновляет данные, читая живые атрибуты каждого ресурса, сравнивает их с конфигом и показывает разницу, которую свёл бы.

count индексирует ресурсы по позиции, поэтому удаление или вставка в середину сдвигает все последующие индексы — Terraform видит новые адреса и уничтожает и пересоздаёт их. for_each ключует по стабильному ключу set или map, поэтому изменение одной записи трогает только её, а порядок неважен.

import берёт существующий ресурс под управление — записывает реальный объект в state по адресу из конфига, ничего не создавая. Форма CLI меняет state сразу; новый блок import декларативен и проходит code review. В обоих случаях сам ресурсный блок вы всё равно пишете руками.

Модуль — переиспользуемая папка ресурсов с чётким интерфейсом из входных переменных и выходов. Хороший модуль узкий и композируемый: открывает только осмысленные входы, возвращает полезные выходы, ничего не хардкодит под окружение и версионируется, чтобы вызывающий закреплял известный релиз.

Удалённый state хранит файл в общем зашифрованном бэкенде вместо локального диска, чтобы у команды был один источник истины. Во время apply Terraform берёт блокировку; без неё два одновременных apply смешают записи и повредят state, начав неверно отслеживать ресурсы.

Workspace — именованный отдельный state с общими конфигом и бэкендом, так dev и prod держат разный state. Но изоляция слабая — общий бэкенд и креды, поэтому apply не в том workspace достаёт до prod. Для сильной изоляции берут отдельные конфиги на окружение.

Terraform обнаружил дрейф — консоль выставила t3.large, а конфиг всё ещё говорит t3.small, поэтому plan возвращает реальность к коду. Чтобы сохранить значение из консоли, обновите конфиг до t3.large или добавьте ignore_changes для него. Чтобы отбросить — просто apply. State руками не правьте.

Вынесите общую инфру в версионируемые модули, закреплённые на каждое окружение. Дайте каждому окружению свой корневой конфиг и удалённый бэкенд с блокировкой и least-privilege кредами — радиус поражения одно окружение. Дробите state по сервисам против конкуренции за блокировку, продвигая подъёмом закреплённых версий от dev к prod.

Блокировка бэкенда защищает state от одновременных записей. Отменённый запуск умер, не сняв блокировку, поэтому она застряла — на деле никто не применяет. Убедитесь по полям Who/Created, что apply не идёт, затем — terraform force-unlock с показанным ID. Не снимайте силой вслепую.

Добавьте блок moved, сопоставляющий старый адрес aws_instance.web с новым aws_instance.app. На следующем plan Terraform перепишет адрес в state, поэтому ничего не уничтожается и не создаётся. Это декларативно и ревьюится, в отличие от разового terraform state mv.

Мажор провайдера меняет, какой атрибут форсит замену — здесь engine_version теперь вызывает replace. Прочтите upgrade guide. Избегите уничтожения — ignore_changes или prevent_destroy, косметику сведите через -refresh-only. Не применяйте replace на живой БД вслепую.