Terraform по дефолту сидел в staging и destroy снёс пол-окружения

[svetlana_js]

Потерял полдня. Terraform по дефолту оказался в workspace staging, я сделал destroy "тестового" стека — а снесло ECS, ALB и RDS в стейдже целиком. S3 versioning спас стейт, но осадочек на весь день.

[lera_cache57]

Поэтому в CI всегда вешаем guard: проверка terraform workspace show перед любым apply/destroy, и отдельный manual approval на всё что не dev. Один стейт на все окружения это мина замедленного действия.

[savva_flow]

Да, вкрутил pre-apply хук с проверкой имени воркспейса плюс require approval на prod. Дёшево и спасает от тупых рук. Моих, в данном случае.

[kira_app10]

Попробовал — работает, но пришлось ещё права на папку поправить.

[tanya_ml]

Классическая ловушка terraform workspace. Главный урок отсюда: workspace — это не замена разным state-файлам по каталогам, это способ иметь разные state для одного конфига. Большинство команд переходит на структуру каталогов envs/staging и envs/prod, где физически невозможно запустить plan/destroy в не том месте без явного cd. Ещё помогает `.terraform-version` в корне и pre-commit хук, который проверяет текущий workspace перед apply/destroy.

[dba_oracle]

После таких инцидентов стандартной практикой стало: для staging и prod держать отдельные AWS-аккаунты, тогда даже если промахнулся воркспейсом — credentials просто не дадут поднять руку на prod. Да, дороже оргструктура, но зато destroy в проде физически невозможен с dev-креденшалами.

[sasha_py52]

Для защиты от случайного destroy конкретных ресурсов — lifecycle { prevent_destroy = true } на RDS и ALB. Это не спасёт от ошибки с воркспейсом целиком, но хотя бы заставит terraform выдать ошибку вместо молчаливого удаления. Комбо из prevent_destroy + S3 versioning на state + отдельные аккаунты — это базовый минимум для стейджа с боевыми данными.

[nikita_sql]

А на последней версии так же работает? Боюсь обновляться.