Комментарии 13
А можно пожалуйста по детальнее про встроенные секреты в nomad и consul?
Написано очень поверхностно, никакой конкретики.
Насколько помню namespace в номаде никак не ограничивает связь приложений в разных контурах, это чисто ограничение на видимость для операторов и тп. В consul поддержку namespace завезли только в платной версии вроде как.
как подружить boundary с consul service discovery я вообще не нашел, что бы можно было как в consul connect быстро выбирать какие сервисы и хосты публиковать и кому.
Как используется и для чего haproxy тоже непонятно, и что такое binta?
Это все же обзорный пост без конкретных инженерных решений.
Отвечаю на ваши вопросы:
1) Namespace - у клиента на основе него разграничиваются окружения для клиентов.
2) В boundary давно обещают завести сервис дискавери. У. нас сейчас через баундари обеспечивается доступ как описано выше. К основным ресурсам за баундари. И через терраформ прокатывается доступы к ui приложней который он резолвит через consul connect.
3) Haproxy используется в роли балансировщика для приложения в ситуациях когда приложение скейлится.
И кстати забыл, в номаде можно выставлять ограничения на доступ приложения из неймспейса А к приложению в неймспейс Б. Также можно ограничивать и регилировать общение сервисов на уровне консула путем управления ACL листов
Я вот в номаде не нашел такого ограничения, может не там искал.
Да и в консуле ограничить общение приложений нельзя, ну если конешно не про consul connect и его Intentions.
Сами используем nomad+consul+vault. Смотрим на boundary. Нравится тем что связка очень простая и настраивается довольно быстро.
Я тоже фанат hashicorp (возможно даже их агент влияния) но новый проект на nomad в 2023 это необдуманное решение. Kubernetes объективно победил. Взять хотябы публичные облака. Я что-то не слышал про managed nomad в них, а вот kubernetes есть везде.
Тудаже и consul connect - тоже не самый мейнстрим мягко говоря.
просто представьте что с этим после вас будут делать хм… не фанаты hashicorp
Все же для использования кубером требуется опыт. И он нужен не малый. Это тоже объективный факт.
Что мешает развернуть точно также номад в облаке?) У нас реализации в aws, yandex cloud. И в случае необзодимости наращивать ресурсы\добавлять ноды. Весь этот процесс не составляет труда и занимаетот силы 5-10 минут. Также как и даунскейлинг ресурсов \ клиент нод.
А чем вам не нравится consul connect?
На самом деле мне, честно говоря, проще представить как будет клиент работать с номадом чем с кубером. Тем более мы оставляем после себя подробный мануал по его эксплуатации. И как по мне документация у хашиков шикарно выполнена, на все случаи жизни.
И основываясь на фидбеках клиентов им заходит номад лучше чем кубер) Как в части обслуживания так и в части эксплуатации.
И хочу отдельно подсветить что номад прекрасен тем, что его инсталяция в облаке или селф-серверах мало чем отличается
Кубернетис победил кого? Простите?! Среди тех, кто использует Nomad, до сих пор немало громких имён. То, что кубернетис пытаются запихать в каждую дырку - это да, полностью согласен.
Касательно публичных облаков, ну какбэ, Nomad не впарить всем подряд, это вытекающее из моего крайнего утверждения. Кубернетис хорошо продаётся, поэтому его везде запихали)
Объективно, заказчику фиолетово, nomad или k8s или swarm, прости господи. Оно должно работать, не падать, выполнять свои бизнес задачи.
И статья в общем-то не о том, как победить кубер, а о том, что можно не только него, можно делать хорошо на том стеке, что нравится. А если вы тоже любите, как и мы, хашикорп стек, то присоединяйтесь к нашему проекту Prism. Здесь мы в слоумо режиме пилим свой шаблонизатор для Nomad, потому что Levant нам не нравится) И мы уже его используем в наших проектах.
Приходите, пробуйте, тестируйте, оставляйте обратную связь. Будем рады новым людям, неравнодушным к нашим Hashicorp-инициативам.
У меня был опыт поддержки решения на hashicorp-стеке и я считаю, что будет большим преувеличением сказать, что этот стек в продуктиве не требует нескольких опытных и заменяемых инженеров. И он точно не обладает таким плавным переходом от простых до очень сложных возможностей, какие доступны для kubernetes. Да что там, один только Argo-stack и 100500 готовых helm chart чего стоят.
Справедливости ради, в статье и не повествуется о том, что hashicorp-стек не требует нескольких опытных и заменяемых инженеров. Этого нельзя сказать и про куб-стек. И да, согласен со второй частью вашего высказывания.
Но для номад тоже полно много чего готового, пускай это и приходится искать по крупицам в различных персональных репозиториях.
Мы же просто пытаемся развивать тот подход, который нам интересен и который мы используем в наших проектах. Тот подход, который, по нашему мнению, требует наименьших усилий в плане поддержки.
Загляните к нам в Prism как-нибудь, здесь мы как раз и пытаемся решить задачу про "переход от простых до очень сложных возможностей". Будем ради обратной связи от опытных инженеров.
«Свои грабли» detected или Hashicorp way, на тропе просветления