Спасибо за видео! Очень интересная тема! Соглашусь с Денисом, что код в этого дела очень непонятный и тяжело воспринимается. Для сравнения, когда я читаю Terraform код, то для меня все понятно, что там прописано + легко ориентироватся в самом коде. А Денису еще раз ОГРОМНОЕ спасибо за труды!
Страшно интересно! Орнул с вывода) Но единственной плюс, который увидел - это, что можно задеплоить или замочить инфраструктуру на всех стендах. Но вопрос ещё зачем и в каких ситуациях это делать? С самого начала мне непонятно, зачем дублировать код для разных стендах? Можно же сделать отдельные config для backend'ов и tfvars файлы для всех стендов. Обозвать их единообразно с префиксами -dev, -test и - prod, например. Тогда это отлично параметризуется и запускается из любого ci/cd инструмента. Код самой инфраструктуры один, параметры для каждого стендах отдельно. Нафиг ещё какие-то высокоуровневые абстракции?
Terragrunt: мы используем принцип DRY, никакого повторяющегося кода Также terragrunt: плодит кучу файлов terragrunt.hcl с одинаковым содержимым и единственным отличием в названии окружения
добрый день спасибо за урок подскажи пожалуйста каким расширением для хрома ты пользуешься, чтоб переключать аккаунты aws, увидел на этом уроке, показалось очень удобно!
Расскажи практики структуры проектов в терраформ, часто используют workspace на проектах? По-моему делить по папкам моветон какой-то, если там тысячи строк как гарантировать соответствие среды? Как протягиваются cреды выше по гиту с dev до prod
Спасибо! Для понимания очень полезно. Насчёт необычности языка верно подмечено. Подкупает только то, что можно вынести в общие переменные провайдеров и переменные. Обычно это симлинками решаю. Как быть если ресурс terraform не из модуля брать? Вместо него прописывать required_version и required_providers?
Парочку вопросов: 1. Дополнения кода откуда вылазят при редактировании terragrant файлов ? 2. Ежели подключить copilot , он не делает создание automation менее рутинным процессом , что для языка терраформ, так и террагрант ?
@@ADV-IT На настоящий момент Microsoft , как автор Copilot и собственник github , докладывает, что до трети кода на github генерирует этот инструмент. Инструмент натренирован на коде , что лежит на github, поэтому не исключено , что хорошо должен работать как раз над такими рубинами, как Automation , я не проверял, хотел узнать положение вещей. Возможно, что коллеги и зрители знают
Хочу спросить за терраформ way deployment Зачем для каждого енваримента плоидить свой папку с кодом и копипастить его же для каждого енваримента? У нас же консистентность теряется, если что-то поменять то надо менять везде где же тут DRY? можно ж использовать разные файлы terraform.tfvars но одна проблема с инитом евнваримента но это решаемо
Интересная тема. Но террагрант, как обертка наверное только на примере большого проекта будет целиком раскрыта? Я как раз столкнулся с таким кейсом на своем первом же проекте)). Ждем, Денис!
Использовать Global variable концепт 1. Или деплоймент в котором только Outputs и используешь remote state 2. Или Module в котором только Outputs и просто зовешь это модуль
Обожаю сей канал и подачу автора, не сочтите за хейтерство, но 6 раз заходить и запускать, можно было бы и скриптец простой сделать, что тоже бы было полезно для юных девопсов.
тут как с любой автоматизацией - если задача разовая и на автоматизацию ты потратишь сильно больше времени, то может ну его на? (например, вспоминая заклинания bash - я с ним имею дело крайне эпизодически, многие вещи тупо забываешь)
мне кажется этот велосипед я могу сделать и без террагранта. а такой воркероун имеет смысл только есть есть создавать отдельные тестовые енваерменты, каждый день и много
@@ADV-IT кхмм это пример очень красиво можно сделать с terraform workspaces и стейт будет также красиво по папкам разбросан и код не нужно дублировать. Apply на всё workspaces в один раз не сделать как в terragrunt.
@@ADV-IT Ну как же разные, ты же писал, что не используешь его. ) Workspaces - отлично решает задачу создания идентичных env наиболее простым и логичным способом, все на одном уровне и каждый компонент видит соседний без свистоплясок, и не нужно ипаться с кучей директорий, которые еще нужно связать зависимостями, аутпутами, инпутами - да это мрак просто. Да еще и менеджить потом.
@@jurkinss1 > Apply на всё workspaces в один раз не сделать как в terragrunt. Не представляю кейса, когда ну вот реально нужно прям все-все-все env сразу задеплоить. Да и это решается простым скриптом на bash в несколько строк, при необходимости, на самом деле. Если ради этого держать terragrunt - ну зря. ) Сами создаем себе проблему и потом героичесски ее решаем. )
Ни разу пока terragrunt не использовал, потому что вызывает скепсис один state-файл на все окружения. Не будет ли это создавать проблему в большой команде, когда у нас то и дело несколько человек будут пушить свои изменения в разные окружения и одновременно и ждать их разлочивания?
Здесь вы неправы. Можете сделать на каждаю сущность свой path в бакете со своим состоянием. Terragrunt на самом деле очень классная штука, которая упрощает работу.
Куда-то пропал мой комментарий со ссылкой на пулл-реквест. Продублирую на всякий случай: открыл PR в репозиторий автора с небольшим рефакторингом, без генерации _config . tf и с хранением "своего" стейта в каждом аккаунте, а не всех в основном.
тут заявляют что terragrunt уже особо не нужен th-cam.com/video/w0NxjbBj_38/w-d-xo.html , но он действительно уменьшает код (dry) и позволяет теплейтить то что tf не умеет.
изобретение велосипеда, куча копи-паста, притом подача как DRY решения. Изначально не верно выбранная схема директорий и подход ещё и завернут в сторонний продукт. Ну не... читайте бест практики по terraform и не используёте эту муть. Мнение человека сдавшего сертификат Terrafom-003
Что посоветуете? Я вот terraform workspace использую и это отлично решает задачу создания идентичных env, и при этом код прост, линеен, легко читабелен и прост в поддержке. Прилетела задача обернуть все в terragrant, сижу уже неделю переписываю, ради мнимых надуманных выгод. ) Не понимаю, как можно было придумать такой каличный подход. )
@@cheshirecat2504 Всё конечно зависит от задач. Terraform workspaces отлично справиться с multi-environment задачами. Остальные, считай все, задачи можно написать на терраформ, плюс файлы конфигов с переменными. Естественно использовать модули и прочее. Никакой дедупликации кода Terragrunt не даёт, если подумать. Просто неправильный подход со структурой. Кидать доп файлы в каталоги. Какая тут дедупликация кода? Да ещё вводите дополнительный продукт в проект. Чтобы ещё его, Terragrunt, баги чинить и искать по рынку кто его знает на суппорт? Извольте. И товарищи из Сloudposse (крутые ребята, не чета Бабенко) не дадут соврать. Посмотрите на их модули и подход. Космос. Если вам кажется, что задача однозначно требует Terragrunt - значит задача должна быть переосмыслена. За 7-8 лет с терраформом я ни разу не сталкивался с задачами, где нужно было по что-то кроме него. Даже в крупных проектах на 300-500 разработчиков. После версии 1.0 считаю функционал вышел на 100% покрытие всех вопросов. А теперь с terraform test, preconditions, validations и так далее и подавно. Для мега крупных проектов для AWS есть подход с AFT - account factory terraform. Мега удобная штука для AWS control tower + organizations. Также могу посоветовать посмотреть вот на это atmos.tools/ И ещё я считаю что Terragrunt должен быть разрушен )))
не ну музло орное подобрал))) спасибо за полезный урок
Спасибо за видео! Очень интересная тема! Соглашусь с Денисом, что код в этого дела очень непонятный и тяжело воспринимается. Для сравнения, когда я читаю Terraform код, то для меня все понятно, что там прописано + легко ориентироватся в самом коде. А Денису еще раз ОГРОМНОЕ спасибо за труды!
Тема 🔥, давно хотел понять в чем разница и для чего Terragrunt 👍
блин, ты прекрасен.
так легко и приятно твой материал изучать !
Страшно интересно!
Орнул с вывода) Но единственной плюс, который увидел - это, что можно задеплоить или замочить инфраструктуру на всех стендах. Но вопрос ещё зачем и в каких ситуациях это делать?
С самого начала мне непонятно, зачем дублировать код для разных стендах? Можно же сделать отдельные config для backend'ов и tfvars файлы для всех стендов. Обозвать их единообразно с префиксами -dev, -test и - prod, например. Тогда это отлично параметризуется и запускается из любого ci/cd инструмента. Код самой инфраструктуры один, параметры для каждого стендах отдельно. Нафиг ещё какие-то высокоуровневые абстракции?
Чтобы было :)
Привет, наконец-то и мне понадобился Terragrunt, с меня 401й лайк :)
Спасибо за гавайское настроение. Сразу подумал что это мелодия из мульта про русалочку Ариэль 😄
Terragrunt: мы используем принцип DRY, никакого повторяющегося кода
Также terragrunt: плодит кучу файлов terragrunt.hcl с одинаковым содержимым и единственным отличием в названии окружения
Самый шикарный ответ на моей памяти на вопрос смотреть ли видео или нет, 13 сек и я всё понял )))
добрый день
спасибо за урок
подскажи пожалуйста каким расширением для хрома ты пользуешься, чтоб переключать аккаунты aws, увидел на этом уроке, показалось очень удобно!
AWS switch Roles plugin
У меня есть видео про AWS Organizations там показываю и рассказываю про этот Plugin.
Terragrunt при помощи dependency уже строит зависимости, не обязательно указывать dependencies
Спасибо
круто) было бы идеально сделать цикл по работе с terragrunt
Делаешь модуль-обертку, в которой на вход ожидается регион и прочие энв-зависимые штуки. Вызываешь модуль, профит.
АХАХАХАХАХАХА, супер !!!! золото или гавно !!! отлично =) Надеюсь у тебя есть курсы по дженкинсу.
Есть конечно
Расскажи практики структуры проектов в терраформ, часто используют workspace на проектах? По-моему делить по папкам моветон какой-то, если там тысячи строк как гарантировать соответствие среды? Как протягиваются cреды выше по гиту с dev до prod
workspace вообще никогда ни используют как я вижу, я его тоже не использую
Посоветуйте плз визуализатор Терагрант конфигов. Для Тераформ нашел более-менее норм а для Терагрант нет
Добрый День,Денис а ты с Active Directory работал? Разбираешься вообще со службами каталогов
Работал, делал даже уроки по AWS Directory сервисам
Спасибо! Для понимания очень полезно.
Насчёт необычности языка верно подмечено. Подкупает только то, что можно вынести в общие переменные провайдеров и переменные. Обычно это симлинками решаю.
Как быть если ресурс terraform не из модуля брать? Вместо него прописывать required_version и required_providers?
Можно и не модуль, просто прописываеш от куда брать все файлы *.tf
Парочку вопросов: 1. Дополнения кода откуда вылазят при редактировании terragrant файлов ?
2. Ежели подключить copilot , он не делает создание automation менее рутинным процессом , что для языка терраформ, так и террагрант ?
1. Atom Plugin
2. я не знаю что такое copilot
@@ADV-IT На настоящий момент Microsoft , как автор Copilot и собственник github , докладывает, что до трети кода на github генерирует этот инструмент. Инструмент натренирован на коде , что лежит на github, поэтому не исключено , что хорошо должен работать как раз над такими рубинами, как Automation , я не проверял, хотел узнать положение вещей. Возможно, что коллеги и зрители знают
спасибо за видеоурок
Хочу спросить за терраформ way deployment
Зачем для каждого енваримента плоидить свой папку с кодом и копипастить его же для каждого енваримента?
У нас же консистентность теряется, если что-то поменять то надо менять везде где же тут DRY?
можно ж использовать разные файлы terraform.tfvars но одна проблема с инитом евнваримента но это решаемо
Больше модулей используй, ну и Terragrunt
Интересная тема.
Но террагрант, как обертка наверное только на примере большого проекта будет целиком раскрыта? Я как раз столкнулся с таким кейсом на своем первом же проекте)). Ждем, Денис!
расскажи как менеджить переменные окружения общие для всех env - облегчит ли terragrunt такую необходимость?
Использовать Global variable концепт
1. Или деплоймент в котором только Outputs и используешь remote state
2. Или Module в котором только Outputs и просто зовешь это модуль
Супер, спасибо!
Обожаю сей канал и подачу автора, не сочтите за хейтерство, но 6 раз заходить и запускать, можно было бы и скриптец простой сделать, что тоже бы было полезно для юных девопсов.
тут как с любой автоматизацией - если задача разовая и на автоматизацию ты потратишь сильно больше времени, то может ну его на? (например, вспоминая заклинания bash - я с ним имею дело крайне эпизодически, многие вещи тупо забываешь)
мне кажется этот велосипед я могу сделать и без террагранта.
а такой воркероун имеет смысл только есть есть создавать отдельные тестовые енваерменты, каждый день и много
Terraform workspace как ты думаешь хорошая альтернатива terragrunt?
Это вообще разные вещи
@@ADV-IT кхмм это пример очень красиво можно сделать с terraform workspaces и стейт будет также красиво по папкам разбросан и код не нужно дублировать. Apply на всё workspaces в один раз не сделать как в terragrunt.
@@ADV-IT Ну как же разные, ты же писал, что не используешь его. )
Workspaces - отлично решает задачу создания идентичных env наиболее простым и логичным способом, все на одном уровне и каждый компонент видит соседний без свистоплясок, и не нужно ипаться с кучей директорий, которые еще нужно связать зависимостями, аутпутами, инпутами - да это мрак просто.
Да еще и менеджить потом.
@@jurkinss1
> Apply на всё workspaces в один раз не сделать как в terragrunt.
Не представляю кейса, когда ну вот реально нужно прям все-все-все env сразу задеплоить.
Да и это решается простым скриптом на bash в несколько строк, при необходимости, на самом деле.
Если ради этого держать terragrunt - ну зря. )
Сами создаем себе проблему и потом героичесски ее решаем. )
А что если хочется чтобы на каждое окружение стейты хранились в отдельной vpc?
стейты хранятся не в VPC а в S3.
Ни разу пока terragrunt не использовал, потому что вызывает скепсис один state-файл на все окружения. Не будет ли это создавать проблему в большой команде, когда у нас то и дело несколько человек будут пушить свои изменения в разные окружения и одновременно и ждать их разлочивания?
Здесь вы неправы. Можете сделать на каждаю сущность свой path в бакете со своим состоянием. Terragrunt на самом деле очень классная штука, которая упрощает работу.
а в курс терраформ на юдеми это видео не попадет?
Там Курс чисто по Тераформу, и четко для экзамена.
@@ADV-IT думал как vip смогу посмотреть до релиза
@@dark4igi у меня нету VIP
Наконецто!!!
Обращал ли внимание на Terraspace?
Выглядит куда удобнее в использовании, чем Terragrunt
неа
Куда-то пропал мой комментарий со ссылкой на пулл-реквест. Продублирую на всякий случай: открыл PR в репозиторий автора с небольшим рефакторингом, без генерации _config . tf и с хранением "своего" стейта в каждом аккаунте, а не всех в основном.
TH-cam часто блокирует коменты с ссылками
А если уже есть стейт, могу я переписать конфиг с использованием террагранта, используя тот же стейт файл?
Конечно
A etu Git funkciju neljzja cherez Locals vnedritj?
В remote state нельзя все равно использовать variables, только hard coded values
на интервью спрашивают постоянно про терагрунт
тут заявляют что terragrunt уже особо не нужен th-cam.com/video/w0NxjbBj_38/w-d-xo.html , но он действительно уменьшает код (dry) и позволяет теплейтить то что tf не умеет.
Eвгений Брикман еврей походу, не русский
put your git repo with source codes under videos
Ай, не посмотрю. Работу работаю
Ссылка на гит с 404 ошибкой
Сделал Public, Try again
упрощАет
изобретение велосипеда, куча копи-паста, притом подача как DRY решения. Изначально не верно выбранная схема директорий и подход ещё и завернут в сторонний продукт. Ну не... читайте бест практики по terraform и не используёте эту муть. Мнение человека сдавшего сертификат Terrafom-003
Что посоветуете?
Я вот terraform workspace использую и это отлично решает задачу создания идентичных env, и при этом код прост, линеен, легко читабелен и прост в поддержке.
Прилетела задача обернуть все в terragrant, сижу уже неделю переписываю, ради мнимых надуманных выгод. )
Не понимаю, как можно было придумать такой каличный подход. )
@@cheshirecat2504 Всё конечно зависит от задач. Terraform workspaces отлично справиться с multi-environment задачами. Остальные, считай все, задачи можно написать на терраформ, плюс файлы конфигов с переменными. Естественно использовать модули и прочее.
Никакой дедупликации кода Terragrunt не даёт, если подумать. Просто неправильный подход со структурой. Кидать доп файлы в каталоги. Какая тут дедупликация кода? Да ещё вводите дополнительный продукт в проект. Чтобы ещё его, Terragrunt, баги чинить и искать по рынку кто его знает на суппорт? Извольте.
И товарищи из Сloudposse (крутые ребята, не чета Бабенко) не дадут соврать. Посмотрите на их модули и подход. Космос.
Если вам кажется, что задача однозначно требует Terragrunt - значит задача должна быть переосмыслена. За 7-8 лет с терраформом я ни разу не сталкивался с задачами, где нужно было по что-то кроме него. Даже в крупных проектах на 300-500 разработчиков.
После версии 1.0 считаю функционал вышел на 100% покрытие всех вопросов. А теперь с terraform test, preconditions, validations и так далее и подавно.
Для мега крупных проектов для AWS есть подход с AFT - account factory terraform. Мега удобная штука для AWS control tower + organizations.
Также могу посоветовать посмотреть вот на это atmos.tools/
И ещё я считаю что Terragrunt должен быть разрушен )))
Только плиз не на языке Голливудских фильмов о русской мафии )))
on chisto po dely bratka
Huligany
@@ADV-IT na zdrov'e
Привет. Очень хотелось бы задать важный вопрос. Отправил приглашения в ЛинкедИн. Добавь пожалуйста в друзья.
Спасибо за видео.