how/cicd

plan как артефакт: пайплайн с ревью между plan и apply

Сохранить tfplan в файл, показать его человеку, применить ровно его - и не дать «случайно» доехать другому диффу. Канонический CI-pattern для Terraform.

Если в одной команде с тобой больше одного человека, или ты просто хочешь спать спокойно, у тебя есть один и тот же вопрос: как сделать так, чтобы apply применял ровно то, что я ревьюил.

Простая комбинация terraform plan → «выглядит хорошо» → terraform apply не даёт этой гарантии. Когда ты запускаешь apply без аргументов, он строит новый план, прогоняет refresh, и если за эти 30 секунд кто-то что-то изменил в облаке

diff будет другим. То, что ты прочитал на скрин-шоте, и то, что реально применилось - разные вещи.

Жми ▶ - посмотрим, как tfplan-файл закрывает это окно неопределённости.

step 1/6·00 · наивно: plan + apply подряд

§ шаги

Локально, на своей машине:
bash
$ terraform plan
# смотришь output, всё ок
$ terraform apply
# вводишь yes - поехало
Что на самом деле делает второй apply: он снова строит план, делает refresh, и применяет. Между двумя планами могли произойти изменения в облаке, обновление провайдера, гонка с другим инженером. В 99% случаев diff не меняется. В 1% - меняется, и ты об этом узнаёшь после. Это окно неопределённости.

итого

Что важно запомнить:

terraform plan -out=tfplan сохраняет план в бинарный файл. Внутри - diff, state-snapshot и метаинфа. Не читается глазами.
terraform show -json tfplan > plan.json или terraform show -no-color tfplan - превращает бинарь в читаемый вид. Для PR-комментария обычно plain text; для policy engine - JSON (см. tf-policy-gate).
terraform apply tfplan не делает повторный refresh и не пересчитывает план. Просто исполняет ровно то, что записано. Если tfplan стал «устаревшим» - apply упадёт со Saved plan is stale, и нужно сгенерировать новый.
В CI обычно две отдельные job'ы: plan (запускается на каждый PR, артефакт сохраняется) и apply (запускается на merge в главную ветку или вручную, скачивает артефакт). См. tf-plan-apply-ci.
Доступ к state. plan -out нужно делать на том же backend'е, что и apply. Иначе tfplan будет содержать state-снимок одной БД, а apply попытается записать в другую.
tfplan содержит расшифрованные sensitive-значения. Хранить его как artifact только в защищённом сторадже (Actions artifacts с retention, S3 с SSE-KMS). Не пушить в git.

Дальше: tf-oidc-aws про то, как CI получает доступ в AWS без long-lived ключей.

§ копнуть в базу знаний

§ попробовать руками

§ шаги

Локально, на своей машине:

bash

$ terraform plan

# смотришь output, всё ок

$ terraform apply

# вводишь yes - поехало

Что на самом деле делает второй apply: он снова строит план, делает refresh, и применяет. Между двумя планами могли произойти изменения в облаке, обновление провайдера, гонка с другим инженером. В 99% случаев diff не меняется. В 1% - меняется, и ты об этом узнаёшь после. Это окно неопределённости.