Вскрыли свой terraform.tfstate на 22 МБ — там призраки уволенных стажёров

[py_wizard]

Вскрыли наш terraform.tfstate — 22 МБ. Внутри инстансы удалённые полгода назад, кластер которого физически нет, и юзернейм стажёра который давно уволился. Один монолитный стейт на всю инфру, без разбивки. Как с этим вообще жить?

[Austkin]

Никак, разбивать. Один монолитный стейт = один кривой apply кладёт всё разом. Режьте по доменам: сеть, базы, приложения — отдельные стейты, между ними terraform_remote_state как data source.

[burnedblueteam]

А как разрезать без даунтайма? terraform state mv по 300 ресурсов вручную звучит как отдельный круг ада.

[seniorsamurai]

terraform state mv с -state-out в новый файл, прогоняешь скриптом по списку адресов из state list. Либо import в новый стейт + rm из старого. Долго и муторно, но без пересоздания живых ресурсов.

[Tcraw62981]

Главное: включите на S3 versioning и lock (DynamoDB или нативный S3 lock) ПЕРЕД операциями. Один прерванный по сети mv на таком объёме — и здравствуй, corrupted state.

[Omoto]

Versioning к счастью был, lock тоже. Без них я бы тут уже некролог проду писал, а не вопрос задавал.

[torch22]

И помните: стейт это плейнтекст. Пароли RDS, приватные ключи, токены — всё лежит открытым текстом прямо в файле. Шифрование бакета и строгий IAM обязательны, особенно с историей версий на 22 МБ.

[Kutz]

Вот да, открыл файл — а там пароль от прод-базы в открытую. Срочно ротируем и закрываем доступ. Тред незаметно превратился в чек-лист моего стыда, спасибо.

[carv]

Сохранил себе весь тред. У нас ровно такой же монолит на 18 МБ потихоньку зреет. Пойду резать пока не рвануло как у вас.

[delphin]

@Austkin, terraform_remote_state это так себе совет, честно. Жёсткая связка между стейтами: поменял один output в сетевом слое и получил каскад по всем потребителям. Лучше data source по тегам, или SSM Parameter Store как контракт между слоями. remote_state удобен ровно до первого рефакторинга, потом начинается боль.