Но, если пришлось откатить tfstate и нужного ресурса там нет — его можно вписать или скопировать, а затем также отметить для пересоздания.
Думаю, лезть в tfstate и менять его руками — плохая идея. Так можно много чего наворотить, особенно, если не до конца понимаешь, с чем имеешь дело. Рекомендации, изложенные в комментарии выше (версионирование tfstate с возможным откатом на предыдущие версии, разбивка инфраструктуры на небольшие блоки с отдельными tfstate и т.д.), я нахожу более прозрачными и безопасными.
не пойму только, чем в этом случае поможет шаблонизатор terragrunt
Как Вы правильно заметили, никак. Terragrunt — лишь расширение Terraform, позволяющее решить ряд его проблем (например, как упоминалось выше, управление зависимостями между модулями) и сделать его использование более гибким (например, управление инфраструктурой для разных окружений). Использование Terragrunt не решает проблему испорченного state.
Terraform не позволяет вам описать зависимость между модулями, если они логически на одном уровне.
Эту проблему успешно решает Terragrunt. Помимо проблем с зависимостями между модулями, Terragrunt содержит много других полезных фич, расширяющих Terraform, так что советую обратить внимание.
Основная проблема Terraform, на мой взгляд, — отсутствие полноценных rollback-ов и запись в state результатов apply только после окончания выполнения команды. State для Terraform – это все: если он будет испорчен, прощай инфраструктура. Я лично несколько раз наблюдал ситуации на проде, когда по разным причинам Terraform экстренно завершил свою работу и испортил state. И далеко не всегда его откат к предыдущей версии позволяет решить все проблемы. Однажды это привело к экстренному дестрою всей инфраструктуры приложения.
Немного деталей. Terraform успешно выполнил plan, после чего должен был добавить несколько новых ресурсов. В процессе применений изменений что-то произошло с сетью на раннере. Как результат, они не были применены в полном объеме; более того, в state не были отражены те изменения, которые уже были применены. Перезапуск пайплайна и откат state на предыдущую версию не помогли: Terraform ругался на то, что не может создать ресурсы с такими именами, которые уже есть в аккаунте.
В 90% случаев это фиксится мануальным удалением тех ресурсов, которые не были проиндексированы в state. Однако в один из деплоев в качестве "битого ресурса" оказалась security group, которая была связана правилами с Elastic Beanstalk, и у нас не получилось удалить ее. В итоге пришлось полностью дестроить инфраструктуру для приложения и раскатывать его заново. Благо у нас все равно был запланирован даунтайм для мажорных обновлений других сервисов, и на клиентах это никак не отразилось.
В моей практике бывали и другие случаи, когда state по каким-то причинам портился. Например, был случай, когда из-за проблем с управлением зависимостями между модулями Terraform ушел в панику и опять же испортил state. Пришлось удалять ресурсы вручную.
Пока я не нашел достойного варианта защиты от таких неприятных ситуаций. Интересно, бывали ли у Вас подобные случаи, и есть ли у Вас алгоритм их предотвращения или исправления?
Думаю, лезть в tfstate и менять его руками — плохая идея. Так можно много чего наворотить, особенно, если не до конца понимаешь, с чем имеешь дело. Рекомендации, изложенные в комментарии выше (версионирование tfstate с возможным откатом на предыдущие версии, разбивка инфраструктуры на небольшие блоки с отдельными tfstate и т.д.), я нахожу более прозрачными и безопасными.
Как Вы правильно заметили, никак. Terragrunt — лишь расширение Terraform, позволяющее решить ряд его проблем (например, как упоминалось выше, управление зависимостями между модулями) и сделать его использование более гибким (например, управление инфраструктурой для разных окружений). Использование Terragrunt не решает проблему испорченного state.
Эту проблему успешно решает Terragrunt. Помимо проблем с зависимостями между модулями, Terragrunt содержит много других полезных фич, расширяющих Terraform, так что советую обратить внимание.
Основная проблема Terraform, на мой взгляд, — отсутствие полноценных rollback-ов и запись в state результатов
applyтолько после окончания выполнения команды. State для Terraform – это все: если он будет испорчен, прощай инфраструктура. Я лично несколько раз наблюдал ситуации на проде, когда по разным причинам Terraform экстренно завершил свою работу и испортил state. И далеко не всегда его откат к предыдущей версии позволяет решить все проблемы. Однажды это привело к экстренному дестрою всей инфраструктуры приложения.Немного деталей. Terraform успешно выполнил
plan, после чего должен был добавить несколько новых ресурсов. В процессе применений изменений что-то произошло с сетью на раннере. Как результат, они не были применены в полном объеме; более того, в state не были отражены те изменения, которые уже были применены. Перезапуск пайплайна и откат state на предыдущую версию не помогли: Terraform ругался на то, что не может создать ресурсы с такими именами, которые уже есть в аккаунте.В 90% случаев это фиксится мануальным удалением тех ресурсов, которые не были проиндексированы в state. Однако в один из деплоев в качестве "битого ресурса" оказалась security group, которая была связана правилами с Elastic Beanstalk, и у нас не получилось удалить ее. В итоге пришлось полностью дестроить инфраструктуру для приложения и раскатывать его заново. Благо у нас все равно был запланирован даунтайм для мажорных обновлений других сервисов, и на клиентах это никак не отразилось.
В моей практике бывали и другие случаи, когда state по каким-то причинам портился. Например, был случай, когда из-за проблем с управлением зависимостями между модулями Terraform ушел в панику и опять же испортил state. Пришлось удалять ресурсы вручную.
Пока я не нашел достойного варианта защиты от таких неприятных ситуаций. Интересно, бывали ли у Вас подобные случаи, и есть ли у Вас алгоритм их предотвращения или исправления?