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

[secproxy7089]

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

[nullcore2015]

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

[appdev1427]

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

[sonya8141]

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

[ruslan_web57]

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

[semyon_core]

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

[matvey5884]

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

[coredata6336]

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

[nikita_sql]

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