Как уменьшить риски потери инфраструктуры при использовании Terraform?

Question

[Вадим]

Здравствуйте,

встречал мнение. что использования Terraforma для автоматического добавления или модификации инфраструктуры в продакшене может быть рискованным, так как иногда приводит к полному удалению уже существующих сервисов?

кто-то может поделилиться так ли это и как уменьшить эти риски?

спасиб,
Вадим

Comments

[Вадим]

Это собственно тоже часть вопроса !

Answer 1

[Евгений]

Потерять можно все при любом действии и любым продуктом.
Терраформ просто позволяет сделать это .. красиво и очень удобно, если вы хреново его спланировали.
Правило 1: используйте автоприменение только в тех местах где не жалко или где вы железобетонно уверены(и берете риски на себя)
Правило 2: валидируйте план. Хотя бы глазами
Вообще, есть у некоторых людей практика делать план в файл, валидировать его какой то внешней логикой, и при успешной валидации применять план из файла, не просчитывая его заново (он делается при каждом апплае) с автоподтверждением. Мне не нравится, да и терраформ честно предупреждает что на момент реального применения ситуация может отличаться и менять придется совсем другие элементы.
Правило 3: разноси элементы по логическим слоям, чтобы уменьшить зону поражения при гибельном апплае. Например настройки сети а одной папке со своим стейтом, запуск приложения - в другой. И связывайте через ремоут стейт. Главное соблюдать меру, чтобы каждую, скажем , security group в aws не создавать в отдельных слоях.
Правило 4: используйте модули, если применение логической группы ресурсов используется более одного раза. Тут тоже не стоит плодить модули на каждый ресурс и подходить разумно.
Правило 5: тестируйте изменения! (Используя одни и те же модули для стейжа и прода). Логично предположить что если вы снесли стейж то и прод снесется.
Правило 6: используйте vcs для работы с кодом терраформ (для того чтобы откатывать код для восстановления убитого стейжа например)
Правило 7: используйте lifecycle политики Prevent destroy на ресурсах, чтобы запрещать из убиение
Помидор 7.1: используйте ignore changes там где это нужно
Правило 8: используйте правильный инструмент для того что вы хотите сделать. Терраформ умеет много чего, но конфигурейшн менеджер он не заменит, хотя по функциям они чуть да пересекаются.

В принципе, если продолжать я могу до штук 20 дойти полезных советов, но на 90% мои правила, по сути - используйте для работы с кодом терраформ те же правила что и для работы с любым другим кодом - снимете 70% проблем. Остальные будут связаны с особенностью работы терраформ и радиусом кривизны рук автора терраформ кода.

P.S. пишу на ходу в метро, орфографию и пунктуацию правит т9. Спрашивайте, вдруг заметите какой нибудь термин, который я писать не собирался :D

Comments

[Евгений]

Если вдруг что - мой основной инструмент это 0.11.х терраформ. На 0.12 пока не перешли, там немного подробности меняются

[Вадим]

Спасибо за такой развернутый и подробный ответ !

Два уточнения:

1) разноси элементы по логическим слоям - пример логического слоя?
2) конфигурейшн менеджер - это типа Ansible?

респект и уважуха )
Вадим

[Евгений]

2. chef, ansible - да любой.
То, что терраформ может, скажем, темплейтировать файлы - не означает что он должен это делать всегда и везде. Тем более что делает он это плохо, а любой дополнительный ресурс - это вероятность зависимости которая тригернет пересоздание других ресурсов.

1. каждый логический слой - это отдельная папка с файлами терраформа. Терраформ всегда применяет все файлы лежащие в папке, если вы не задали таргет ключ в командной строке
Например, логический слой - элементы VPC(подсети, route tables, dhcp options и т.п.)
Логический слой - один сервис вашего приложения
Логический слой - все инфраструктурные сервисы, запускаемые с помощью нормально написанных модулей.

Здесь все обсуждаемо, поскольку если за activemq+rabbitmq отвечает одна команда - она может не задевая других делать применение изменений в своем слое.
Если это разные команды - возможно имеет смысл разнести, чтобы изменения одной команды не аффектили сервис другой команды.
Здесь нужно подходить логично и, впоследствие, итеративно решать проблемы возникающие из-за того распределения которое вы организовали.
Например, изначально мы запихали все инфраструктурные сервисы в один слой, но, все они были написаны в модулях и применялись через -target. В принципе, было норм.
Например, terraform apply -target='module.activemq' применял изменения только AMQ, даже если были реальные изменения в соседних rabbitmq, couchbase и т.п. модулях в этом же слое.
Впоследствие, мы неоднократно перераспределяли все сервисы по другим слоям, согласно зоне ответственности команд которые за них отвечают (например если rabbit уехал в другую команду из той, в которой он был изначально)

Отдельно хочется отметить, что большую попаболь в объединении сервисов в слоях доставляет корректность написанных модулей сервисов( напомню, что модули нужны, чтобы ваш препрод и прод запускались из одного кода и инфра изменения тестировались не на проде). Например, в нашем случае, один или два сервиса пересоздавались каждый раз, когда делался терраформ apply несмотря на то, что реальных изменений ни в сервисах ни в параметрах их не было - и приходилось постоянно таргетироваться на изменяемый сервис вместо того чтобы просто делать terraform apply в репозитории (валидация получившегося плана была просто адовой - куча изменений не имеющих отношения к тому, что реально должно поменяться). В нашем случае причиной было использование вполне определенных ресурсов терраформ, которые пересоздаются всегда. Например template_dir или local_file.
Приходится искать способы чтобы их не использовать.

Answer 2

[Иван Шумов]

Курим что такое terraform plan, учимся это валидировать и аппрувить