M
угу
Size: a a a
2019 June 03
AO
да тоже интересноя
AO
насколько смог понять он более гибко позволяет настраивать и запускать терраформ.
VT
я лично его не использую.
он был очень нужен года 2-3 назад, когда много его фитч не было в core
он был очень нужен года 2-3 назад, когда много его фитч не было в core
AO
но типичных кейсов для себя не выявил, вероятно потому что у меня все примитивно
VT
у меня самописные врапперы на bash с тем же самым подходом.
AO
а можно пример? в каких сценариях
VT
есть некрасивый с использованием workspaces
и есть красивый без них.
и есть красивый без них.
VT
я уже как-то писал здесь об этом.
VT
можно наверное статью сделать если хотите, но думаю мало кому-то это будет интересно.
VT
terragrunt просто помогает красиво организовать код.
VT
тоже самое можно достичь с помощью своих скриптов.
MM
а какое руководство по терраформу/террагрунту можете посоветовать? в частоности вот сейчас пишут структуру где много модулей юзается и между ними взаимосдействие, передача переменных например. и пока не до конца понимаю best practices как верно хотя бы код писать.
MM
про офиц доку в курсе)
VT
использовать модули, везде где только возможно,
для всех компонентов.
это сделает код красивее и юзабельнее между проектами и окружениями.
для всех компонентов.
это сделает код красивее и юзабельнее между проектами и окружениями.
MM
ну вот например такое взаимодействие модулей это норма? или пишу хрень?
VT
vpc, security groups, rds-*, и прочее-прочее - всё выносить. (компоненты)
в инфраструктурном модуле должны быть только компонентные модули (в идеале), никаких описаний ресурсов которые неудобно читать.
в инфраструктурном модуле должны быть только компонентные модули (в идеале), никаких описаний ресурсов которые неудобно читать.
VT
общение между инфраструктурными модулями посредством data resources и лучше всего - data remote-state - меньше api вызовов.
VT
назначение модуля data не понятно.
VT
в целом - да, ок.