Выпуски с Александром всегда коротко и по делу. Спасибо. Дослушал до конца, вопрос) Что взять, какой инструмент или какой подход чтобы всех сотрудников компании загнать в 1 подсеть. Но с доступом в интернет и локацией во всем мире? Все ресурсы в амазоне. Есть SSO провайдер OKTA.
Виктор привет, очень круто было когда начали спорить, прям градус внимания сразу подскочил, это чисто так, чтобы у тебя фидбек был со стороны в целом как всегда все интересно
@@VictorVedmich ну более живая беседа вышла, однозначно, особенно когда тема общая, уж юнит тесты и инт тестирование многие прошли, у всех свое понимание сложилось
@@pipazoglovнадо больше делать шоу 😂 но в целом я согласен когда разные мнения это всегда интересно, возможно оба не правы но так интереснее. Будем пробовать больше конфликтовать
Однозначный лайк за такой подробный выпуск по терраформ. Ребят, так как вы двигаетесь в сторону «шоу» 🤣 - то пора бы уже и гостей приглашать, в данном выпуске бы подошел Senior/Lead QA с хорошим опытом😂. Жду новых выпусков!
50:00 юнит тестирование больших монолитов действительно идёт долго. Есть даже такие проекты Drill4J, которые сохраняют состояние юнит тестирования и при следующем прогоне предоставляют команду для тестирования только изменившихся функций.
Спасибо за выпуск. Вопрос для следующего - какие сейчас актуальные способы в облаках подсоединиться к польностью private k8s API (кластер доступен только из собственной vpc)?
Я прошу прощения, но ведущий в белых наушниках не компетентен в вопросах тестирования кода. Ведущий, который просил рассудить Вас в комментариях, Вы абсолютно верное понимаете юнит и интеграционнное тестирование.
Юниттесты, в идеале, не должны требовать ничего из внешних зависимостей. Если твой мегаСкрипт на go юзает Azure API - то приходится мокать Azure API, через интерфейсы например. То же самое с любыми внешними зависимостями. Бонусом - моки дают возможность отслеживать очень многое относительно поведения вызывающей сущности, типа сколько именно раз вызвали, какие аргументы передавали, и тд, и на этом строить тесты. Интеграционка - это ран тестов в реальном окружении, тут уже от подхода зависит, кто-то апает эфимерный неймспейс с всеми зависимостями, кто-то в дев деплоит и смотрит, кто-то вообще всё через service в GitLabе разруливает ) Всё выше сказанное лично моё ИМХО и может не совпадать со всем, что есть в Вашем проекте ( особенно та часть, где в unit тестах вместо моков апают рядом базу данных ).
Согласен с вами, моё мнение очень близко к тому, что вы описали. Юнит-тесты, по идее, не должны взаимодействовать с внешним миром и должны фокусироваться на проверке логики внутри кода. Однако, когда речь идёт о Terraform, ситуация может быть несколько иной. Ведь концепция юнит-тестов изначально разрабатывалась с учётом классических языков программирования.
01:27:20 есть еще одна хорошая утилита для облегчения работы - это renovatebot - Universal dependency update tool that fits into your workflows. Может создавать MR для обновления версий в файлах kubernetes flux terraform dockerfile и других.
А какая разница, что написано в Hashicorp FAQ по BSL1.1? Этот FAQ не имеет никакой юридической силы. С юридической стороны, важно только то, что написано в лицензии. А в лицензии написано: "non-production use".
Non-commercial use - это абсолютно другое. Вы путаете эксплуатацию инструмента, и предоставление конкурирующего сервиса на его основе. Обычно в таких случаях показывает практика. OpenTF - это утопичный проект от заинтересованных в своем бизнесе сторон. Там ничего про "свободу" и иные вещи. Но опять таки посмотрим :)
Ну во первых спасибо за выпуск, а во вторых, это немного снобизм говорить - ой ну кому нужен свой кубер, ой ну в каком же проекте - вы же сами говорили про комплайнс, и не во всех странах есть возможность запустить outpost, и не во всех странах есть регионы амазона, а закон о перс. данных никто не отменял или банки со своими тараканами по секурити никуда не делись %)
Если рассматривать ситуацию с этой точки зрения, то вы абсолютно правы. Мы в основном фокусировались на сценариях, когда все ресурсы уже размещены в облаке, и рассматривали варианты управления k8s в таких условиях. В случае с банками, действительно можно реализовать гибридный подход: часть инфраструктуры развернуть локально, например, с использованием EKS Anywhere, а часть, не затрагивающую персональные данные, оставить в облаке.
01:16:50 У меня есть ссылка/тема/статья в тему request limit. Прямую ссылку Ютуб забанит. Поэтому нужно загуглить Resize CPU Limit To Speed Up Java Startup on Kubernetes - Piotr's TechBlog
@@VictorVedmich В блоге terraform пишут что: "You can use terraform fmt -check and terraform validate as rudimentary unit tests. However, none of these tests verify correct variable interpolation, list iteration, or other configuration logic." А про terraform test в блоге ничего не написано.
Думаю Pulumi и CDK обретут вторую жизнь или просто новую волну популярности, и уже не только среди разработчиков, но и среди DevOps. P.S. В этом году еду не reInvent с темой про CDK :)
Не понимаю как в 2023 году можно радоваться появлению циклов в HCL, когда все вокруг пользуются cdktf (typescript/python) и имею статические и динамические циклы из коробки. Плюс проверку типов, возможно писать и переиспользовать интерфейсы, полноценный язык программирования. Я считаю HCL ужасной ошибкой. Невозможно подсчитать сколько человеко-часов было потраченого на достижение простейших целей типа динамического поведения, итераций по спискам, и тд отдельными девопсами во всем мире. Чтобы в конце двух-трех дневной отладки например осознать что HCL это говно. К сожалению в том же packer пока что альтернатив в виде typescript нету. От терраформа требуется только его интерфейс и его модули. HCL должен быть погребен в истории как недоязык.
Сильный коммент. Я согласен с многими вашими точками, но хочу добавить, что выбор между HCL и, например, cdktf на TypeScript или Python, часто зависит от конкретных проектных требований и командных предпочтений. Также как и с YAML, здесь существуют два лагеря: одни ценят декларативный подход (HCL один из примеров или весь куб на ямле) за его простоту и читаемость, другие предпочитают гибкость императивных языков. В итоге, каждый инструмент имеет свое место и свои применения.
Спасибо интересный за интересный выпуск. Жду дальнейших новостей и прогнозов по развитию OpenTF.
Будет наблюдать за OpenTF - и будем держать в курсе )
Котик на 55 минуте прям пушка!
Больше котика в кадр ?
@@DevOpsKitchenTalksобязательно!
Выпуски с Александром всегда коротко и по делу. Спасибо.
Дослушал до конца, вопрос)
Что взять, какой инструмент или какой подход чтобы всех сотрудников компании загнать в 1 подсеть. Но с доступом в интернет и локацией во всем мире?
Все ресурсы в амазоне. Есть SSO провайдер OKTA.
Спасибо за выпуск! Если сможете, запишите видео на тему best practices написания terraform кода, его тестирование, применение через cicd
Тут все будет зависеть как у Саши будет время.
Виктор привет, очень круто было когда начали спорить, прям градус внимания сразу подскочил, это чисто так, чтобы у тебя фидбек был со стороны
в целом как всегда все интересно
В следующий раз нужно устроить драку ? :) может тогда подписчики пойдут?
@@VictorVedmich ну более живая беседа вышла, однозначно, особенно когда тема общая, уж юнит тесты и инт тестирование многие прошли, у всех свое понимание сложилось
@@pipazoglovнадо больше делать шоу 😂 но в целом я согласен когда разные мнения это всегда интересно, возможно оба не правы но так интереснее. Будем пробовать больше конфликтовать
@VictorVedmich эээ
@@DevOpsKitchenTalksчто - драку в эфир показывать ну будем ?
Однозначный лайк за такой подробный выпуск по терраформ. Ребят, так как вы двигаетесь в сторону «шоу» 🤣 - то пора бы уже и гостей приглашать, в данном выпуске бы подошел Senior/Lead QA с хорошим опытом😂. Жду новых выпусков!
И Малахов ведущим )))
50:00 юнит тестирование больших монолитов действительно идёт долго. Есть даже такие проекты Drill4J, которые сохраняют состояние юнит тестирования и при следующем прогоне предоставляют команду для тестирования только изменившихся функций.
Перед тем как смотреть, ставим лайк!
Я слышал что ютуб такие лайки не очень любит ( типа считает что накрутка. Поэтому лучше посмотреть и в процессе поставить лайк.
@@DevOpsKitchenTalks буду иметь ввиду
Спасибо за выпуск. Вопрос для следующего - какие сейчас актуальные способы в облаках подсоединиться к польностью private k8s API (кластер доступен только из собственной vpc)?
От облака зависит. Классические VPN/Jump hosts наверное проще всего сделать. Остальные решения обычно требуют сложных интеграций
01:01:55 С днем рождения, Виктор!
Спасибо!!!!
Я прошу прощения, но ведущий в белых наушниках не компетентен в вопросах тестирования кода. Ведущий, который просил рассудить Вас в комментариях, Вы абсолютно верное понимаете юнит и интеграционнное тестирование.
Proof? Давайте помогать учиться друг другу. Будет всем полезно :)
За ссылки отдельное спасибо
Не за что :)
Юниттесты, в идеале, не должны требовать ничего из внешних зависимостей. Если твой мегаСкрипт на go юзает Azure API - то приходится мокать Azure API, через интерфейсы например. То же самое с любыми внешними зависимостями. Бонусом - моки дают возможность отслеживать очень многое относительно поведения вызывающей сущности, типа сколько именно раз вызвали, какие аргументы передавали, и тд, и на этом строить тесты. Интеграционка - это ран тестов в реальном окружении, тут уже от подхода зависит, кто-то апает эфимерный неймспейс с всеми зависимостями, кто-то в дев деплоит и смотрит, кто-то вообще всё через service в GitLabе разруливает ) Всё выше сказанное лично моё ИМХО и может не совпадать со всем, что есть в Вашем проекте ( особенно та часть, где в unit тестах вместо моков апают рядом базу данных ).
Согласен с вами, моё мнение очень близко к тому, что вы описали. Юнит-тесты, по идее, не должны взаимодействовать с внешним миром и должны фокусироваться на проверке логики внутри кода. Однако, когда речь идёт о Terraform, ситуация может быть несколько иной. Ведь концепция юнит-тестов изначально разрабатывалась с учётом классических языков программирования.
Лайкос, давай прогноз чего уже интересно тоже послушать =)
01:27:20 есть еще одна хорошая утилита для облегчения работы - это renovatebot - Universal dependency update tool that fits into your workflows. Может создавать MR для обновления версий в файлах kubernetes flux terraform dockerfile и других.
sposibo za vipusk! top notch !
А какая разница, что написано в Hashicorp FAQ по BSL1.1? Этот FAQ не имеет никакой юридической силы. С юридической стороны, важно только то, что написано в лицензии. А в лицензии написано: "non-production use".
Non-commercial use - это абсолютно другое. Вы путаете эксплуатацию инструмента, и предоставление конкурирующего сервиса на его основе. Обычно в таких случаях показывает практика. OpenTF - это утопичный проект от заинтересованных в своем бизнесе сторон. Там ничего про "свободу" и иные вещи. Но опять таки посмотрим :)
Спасибо!
01:18:20 warp terminal только для mac. Под Linux нет
Ну во первых спасибо за выпуск, а во вторых, это немного снобизм говорить - ой ну кому нужен свой кубер, ой ну в каком же проекте - вы же сами говорили про комплайнс, и не во всех странах есть возможность запустить outpost, и не во всех странах есть регионы амазона, а закон о перс. данных никто не отменял или банки со своими тараканами по секурити никуда не делись %)
Если рассматривать ситуацию с этой точки зрения, то вы абсолютно правы. Мы в основном фокусировались на сценариях, когда все ресурсы уже размещены в облаке, и рассматривали варианты управления k8s в таких условиях. В случае с банками, действительно можно реализовать гибридный подход: часть инфраструктуры развернуть локально, например, с использованием EKS Anywhere, а часть, не затрагивающую персональные данные, оставить в облаке.
01:16:50 У меня есть ссылка/тема/статья в тему request limit. Прямую ссылку Ютуб забанит. Поэтому нужно загуглить Resize CPU Limit To Speed Up Java Startup on Kubernetes - Piotr's TechBlog
Спасибо за видео!
На счет перемещения ресурсов декларативно. Вроде ж для этого есть moved block. Или я что-то не так понимаю?
WOW! А я о нем не знал, хотя он судя по всему существует с версии 1.1. Спасибо!
47:18 тестирование между функциями, тестирование использования функции в другой функции это интеграционное тестирование
) так а что такое юнит тестирование в Terraform?
@@VictorVedmich В блоге terraform пишут что: "You can use terraform fmt -check and terraform validate as rudimentary unit tests. However, none of these tests verify correct variable interpolation, list iteration, or other configuration logic."
А про terraform test в блоге ничего не написано.
Lattice not eq латук. :)
Интересно как повлияет изменение лицензии Hashicorp на развитие AWS CDK
Думаю Pulumi и CDK обретут вторую жизнь или просто новую волну популярности, и уже не только среди разработчиков, но и среди DevOps.
P.S. В этом году еду не reInvent с темой про CDK :)
А у вас есть канал в телеге?
Недавно появился :) подключайтесь t.me/DevOpsKitchenTalks
так а ссылочки где?))
Исправился - все добавил.
01:18:47 с помощью warp и engshell можно и bash забыть.
01:07:19 всплывашку забыли
Добавил - спасибо за заметку!
Блок кода terraform import это грубо говоря генерация terraform кода из существующих определенных ресурсов
warp пока не умеет в windows
engshell- хорошая альтернатива
Оо не знал что Warp пока еще не дошел до винды, ох давно я винду не трогал .
Не понимаю как в 2023 году можно радоваться появлению циклов в HCL, когда все вокруг пользуются cdktf (typescript/python) и имею статические и динамические циклы из коробки. Плюс проверку типов, возможно писать и переиспользовать интерфейсы, полноценный язык программирования.
Я считаю HCL ужасной ошибкой. Невозможно подсчитать сколько человеко-часов было потраченого на достижение простейших целей типа динамического поведения, итераций по спискам, и тд отдельными девопсами во всем мире. Чтобы в конце двух-трех дневной отладки например осознать что HCL это говно. К сожалению в том же packer пока что альтернатив в виде typescript нету.
От терраформа требуется только его интерфейс и его модули. HCL должен быть погребен в истории как недоязык.
Сильный коммент. Я согласен с многими вашими точками, но хочу добавить, что выбор между HCL и, например, cdktf на TypeScript или Python, часто зависит от конкретных проектных требований и командных предпочтений. Также как и с YAML, здесь существуют два лагеря: одни ценят декларативный подход (HCL один из примеров или весь куб на ямле) за его простоту и читаемость, другие предпочитают гибкость императивных языков. В итоге, каждый инструмент имеет свое место и свои применения.