С спринг бутом прилагается нетфликсовый стек- eureka service registry и прочее <.>, по видимости, завязанное на жаву.
У Кубернетис свой реестр и он не завязан на жаву. А еще кубернетис выкинул докера в актуальной версии.
Нужно ли переходить на Ккбернетис, или уходить с кубернетиса? Дискас.
PS плотно не интересовался этой темой, прошу не кидать помидорами за наивные вопросы.
Здравствуйте, Артём, Вы писали:
Аё>С спринг бутом прилагается нетфликсовый стек- eureka service registry и прочее <.>, по видимости, завязанное на жаву. Аё>У Кубернетис свой реестр и он не завязан на жаву.
И? Вроде как Эврика — это несколько другое по сравнению с кубиком, нет?
Аё>А еще кубернетис выкинул докера в актуальной версии.
С точки зрения деплоя приложений не изменяется вообще ничего.
Аё>Нужно ли переходить на Ккбернетис,
Нет, не нужно.
Аё>или уходить с кубернетиса?
Нет, не нужно.
Аё>Дискас.
Что конкретно тебя интересует-то? Или решил мразеца 19-го косплеить?
"Нужно" — это громкое слово.
Аё>PS плотно не интересовался этой темой, прошу не кидать помидорами за наивные вопросы.
Ты реальные вопросы-то задай для начала. По эврике ничем не помогу, с кубиком, может, что и подскажу.
Здравствуйте, Артём, Вы писали:
Аё>С спринг бутом прилагается нетфликсовый стек- eureka service registry и прочее <.>, по видимости, завязанное на жаву. Аё>У Кубернетис свой реестр и он не завязан на жаву. А еще кубернетис выкинул докера в актуальной версии.
Аё>Нужно ли переходить на Ккбернетис, или уходить с кубернетиса? Дискас.
Нужно переходить на кубернетес. Я вот перехожу. Сложная штука. Чем раньше начнёшь, тем раньше разберёшься. Пока кубернетес цветёт и пахнет и серьёзных альтернатив ему не видно.
Здравствуйте, vsb, Вы писали:
vsb>Пока кубернетес цветёт и пахнет
Именно цветёт и именно пахнет, известно какой субстанцией. Глючный чрезвычайно. Огроменные дыры в архитектуре. Работать будет только если к нему привязать штат админов, которые в режиме кручения педалей будут обеспечивать его работоспособность. Поделие редгада, которые как раз зарабатывают на том, что продают в красивой красной обёртке то, что без их поддержки просто не работает.
> и серьёзных альтернатив ему не видно.
В 90%-ах всех случаев, где сейчас пихают это кубернетис, он там вообще не нужен. Просто стадо обезьян повторяют друг за другом.
Здравствуйте, vsb, Вы писали:
vsb>Нужно переходить на кубернетес.
Нужно, чтобы что именно? Назови мне хотя бы одну универсальную причину, по которой можно вот так просто сказать "нужно переходить и точка", не зная ни стоящих перед командой задач, ни их проблем, ни их ограничений.
vsb>Я вот перехожу.
Для чего?
vsb>Сложная штука.
Сложно его завести. Дальше он работает нормально в целом, в общем-то. Ну, и нужно, чтобы кто-то инфраструктуру поддерживал, поэтому кубернетес в отрыве от провайдера, облачного или сервисного в виде какой-то фирмы или собственного отдела внутри компании — это так себе решение.
vsb>Пока кубернетес цветёт и пахнет и серьёзных альтернатив ему не видно.
Альтернатив-то полно. От отдельно стоящей машины под домашним столом админа, на которой работает приложение, до разных оркестраторов со всеми промежуточными шагами.
Здравствуйте, vsb, Вы писали:
vsb>Нужно переходить на кубернетес. Я вот перехожу. Сложная штука. Чем раньше начнёшь, тем раньше разберёшься. Пока кубернетес цветёт и пахнет и серьёзных альтернатив ему не видно.
Я не лезу в это пока (других тем хватает), но у меня возникают вопросы к эффективности того, что сделано у нас на базе стека Нетфликс. Кубернетис становится или стал де-факто стандарт с одной стороны (и AWS поддерживает из коробки). С другой- у нас в завязано на eureka, FeignClient и т.п. в "новом коде". Можно FeignClient прозрачно переключить с Eureka на Kubernetis?
Здравствуйте, _ABC_, Вы писали:
vsb>>Нужно переходить на кубернетес. _AB>Нужно, чтобы что именно? Назови мне хотя бы одну универсальную причину, по которой можно вот так просто сказать "нужно переходить и точка", не зная ни стоящих перед командой задач, ни их проблем, ни их ограничений.
Ну про то, что нужно переходить на контейнеры, я полагаю, объяснять не нужно. А если нужны контейнеры — то выбора 2. Либо колхозные docker-compose-ы, либо кубер. docker swarm сдох. У колхозных docker-compose-ов слишком много проблем и ограничений, поэтому кроме как для самого первого этапа, когда вообще некому этим заниматься, они не подходят.
Здравствуйте, Артём, Вы писали:
Аё>С спринг бутом прилагается нетфликсовый стек- eureka service registry и прочее <.>, по видимости, завязанное на жаву.
Ну так все как обычно, с блекджеком и шлюхами. Что тебя удивляет?
Аё>У Кубернетис свой реестр и он не завязан на жаву.
Что ты под реестром понимаешь? Pod list? Или custom resources?
Аё> А еще кубернетис выкинул докера в актуальной версии.
И правильно сделал.
Аё>Нужно ли переходить на Ккбернетис, или уходить с кубернетиса? Дискас.
Нужно переходить, ибо industry standard. О чем тут можно еще дискутировать? И при чем тут service registry?
Здравствуйте, _ABC_, Вы писали:
_AB>Нужно, чтобы что именно? Назови мне хотя бы одну универсальную причину, по которой можно вот так просто сказать "нужно переходить и точка", не зная ни стоящих перед командой задач, ни их проблем, ни их ограничений.
Причина простая — заказчик хочет.
vsb>>Сложная штука. _AB>Сложно его завести.
Да не особо то и сложно, если не пытаться поднимать с нуля. Локально есть docker desktop, в облаке нативные решения типа AKS, в онпреме OpenShift.
А вот что сложно, так это поднять и отладить свой CI/CD. Какого то стандарта нет, helm и kustomize ужасны, всякие skaffold, gitops и argocd сыры и не особо дружелюбны к новичкам.
vsb>>Пока кубернетес цветёт и пахнет и серьёзных альтернатив ему не видно. _AB>Альтернатив-то полно.
Это пока ты не попытаешься свое решение кому то продать. И в этот момент альтернативы пропадают.
Здравствуйте, vsb, Вы писали:
vsb>Ну про то, что нужно переходить на контейнеры, я полагаю, объяснять не нужно.
Нужно. Контейнеры нужны в двух случаях
1) Если свою прикладуху нужно исполнять в облаке и загрузить туда можно только в виде котейнера.
2) Приложение писал макакин, который собрал его из кучи разношерстных компонентов, скачанных с разных источников и разными менеджерами. Это рабатать будеть только у макакина на локалохосте. Чтоб это заработало где-то ещё, единственный способ-это взять образ этого локалхоста, завернуть в контейнер, и этот контейнер уже таскать на другие машины.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да не особо то и сложно, если не пытаться поднимать с нуля. Локально есть docker desktop, в облаке нативные решения типа AKS, в онпреме OpenShift.
Что сложного в том, чтобы поднять его с нуля? Я как раз этим последние недели занимаюсь. Пока в целом всё понятно и просто — kubeadm init / kubeadm join. Я чего-то важного не вижу?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Причина простая — заказчик хочет.
Да, это железная причина. Но не всем заказчикам это интересно.
НС>Да не особо то и сложно, если не пытаться поднимать с нуля. Локально есть docker desktop, в облаке нативные решения типа AKS, в онпреме OpenShift.
Ну, скажем, я слышал мнения нескольких людей, чья профессия — в том числе поднимать кубернетес как локально, так и в облаках провайдеров. С их мнением я согласен, исходя из своего опыта. При том, что я и не настраивал с нуля все эти ноды и прочее, а только разворачивал на этом свой продукт, плотно взаимодействуя с теми, кто разворачивал инфраструктуру. Есть много того, что делается проще и очевиднее при помощи других продуктов типа EBS, например. Одна только настройка ингресс контроллера в частной сети AKS — это отдельный квест уровня хардкор. При том, что документация предоставляет готовый рецепт. Если всё это с нуля поднимать онпрем с сисадмином у которого с его стороны пуля вылетела — я лучше повешусь.
Настройка правил реверс прокси по документации кубика — это другой захватывающий квест. Линукс подход во всей красе — иди читай мануалы самых основ и приходи к нам через несколько лет матёрым сисадмином. Тогда у тебя будет шанс правильно настроить редирект url паттерна, исходя из тех обрывков сведений, что мы предоставили.
В общем, там далеко не всё просто и очевидно. И даже наше архитектурно простое решение развернуть оказалось не так уж прямолинейно и просто.
НС>Это пока ты не попытаешься свое решение кому то продать. И в этот момент альтернативы пропадают.
Я именно что возглавляю техническую часть команды, чьё решение продаётся клиентам. В том числе и в варианте развёртывания решения на базе инфраструктуры заказчика.
Пока что только один клиент из всех захотел кубик на базе AKS. А потом поменял решение, исходя из того, что у него нет людей, которые могли бы это поддерживать. Несмотря на то, что мы со своей стороны успешно развернули решение на AKS. В итоге для него мы развернём всё тупо внутри одной ВМ. Точнее, по одной ВМ на среду — дев, тест, прод. Причина проста — заказчик хочет.(с)
Здравствуйте, vsb, Вы писали:
vsb>Ну про то, что нужно переходить на контейнеры, я полагаю, объяснять не нужно.
Нужно. Не, мы сами на них, но, повторюсь, слово "нужно" слишком громкое.
vsb>А если нужны контейнеры — то выбора 2. Либо колхозные docker-compose-ы, либо кубер.
Либо использовать что-то другое. AWS, Azure и остальные вовсю предлагают serverless applications, например.
Здравствуйте, smeeld, Вы писали:
vsb>>Ну про то, что нужно переходить на контейнеры, я полагаю, объяснять не нужно.
S>Нужно. Контейнеры нужны в двух случаях S>1) Если свою прикладуху нужно исполнять в облаке и загрузить туда можно только в виде котейнера. S>2) Приложение писал макакин, который собрал его из кучи разношерстных компонентов, скачанных с разных источников и разными менеджерами. Это рабатать будеть только у макакина на локалохосте. Чтоб это заработало где-то ещё, единственный способ-это взять образ этого локалхоста, завернуть в контейнер, и этот контейнер уже таскать на другие машины.
S>В остальных случаях контейнеры нафиг не нужны.
Смотри, что мне даёт докер. Про кубер не пишу, пока сам с ним разбираюсь, но раз уж вопрос про контейнеры.
У нас есть около двух десятков разного рода сервисов.
1. Для разработки желательно поднимать его зависимости, то бишь сервисы, с которыми разрабатываемый сервис взаимодействует. Ну по крайней мере нужные. В том числе, например, СУБД. А ещё разные сервисы разрабатывались в разное время и для разных версий постгреса. Оно, конечно, вроде как обратно совместимо, но всякое бывает. С докером нужно знать только как пишется docker-compose и скопипастить с серверного докер-композа нужные строчки. Делов на 5 минут. Без докера тебе надо: установить node.js, причём несколько штук и нужных версий, установить несколько штук СУБД. Ещё сервисы любят биндиться на 8080 или 3000, то бишь тебе надо ещё с настройками портов мудохаться.
Я вот вообще не представляю, как это делать без геморроя. Даже если всё по уму, тебе надо по каждому сервису вести актуальную документацию, при его установке читать эту документацию, искать там нужные параметры. В общем докер тут экономит много времени.
Если у тебя в компании разрабатывается ровно одно приложение, в котором всё сразу, то этой проблемы нет. Ну я такого в своей жизни ещё не видел.
2. Для сборки нужно устанавливать окружения. Причём опять же желательно нужной версии. Ибо, опять же, обратная совместимость вроде везде есть, но по факту бывают нюансы. И разбираться с этими нюансами — не самое интересное времяпрепровождение, особенно, когда тебе этот сервис нафиг не нужен, только как необходимая для запуска зависимость.
3. Упрощение CI. Сейчас все проекты собираются одной командой — docker build . Раньше для каждого проекта в женкинсе настраивалась задача, это было довольно геморройно. Так уж получается, что Dockerfile удобней, чем женкинсовая муть.
4. Единообразие с ОС. В контейнерах линукс и всё. Не нужно париться со всякой кроссплатформенностью там, где можно не париться. При этом у разработчика может быть винда или макось, это не важно.
Твои пункты тут не применимы. Но польза от контейнеров велика.
Здравствуйте, vsb, Вы писали:
vsb>1 Без докера тебе надо: установить node.js, причём несколько штук и нужных версий
Это тот самый варинт макакина.
> установить несколько штук СУБД. Ещё сервисы любят биндиться на 8080 или 3000, то бишь тебе надо ещё с настройками портов мудохаться.
Это всё без докеров делалось и делается прекрасно в одну команду, если админ есть квалифицировнный, а не девляпс.
vsb>Я вот вообще не представляю, как это делать без геморроя.
Это всё прекрасно делается без доокеров. В докерах по самые уши только мелкие комашки у которых нет админов. Зрелый прод их не использует, только для организиции приватных облаков, построенных на контейнерах.
Здравствуйте, _ABC_, Вы писали:
vsb>>Ну про то, что нужно переходить на контейнеры, я полагаю, объяснять не нужно. _AB>Нужно. Не, мы сами на них, но, повторюсь, слово "нужно" слишком громкое.
Ну лично я вижу единственный вариант, где контейнеры не принесут особой пользы — если компания разрабатывает ровно один продукт. Один, так сказать, проект.
vsb>>А если нужны контейнеры — то выбора 2. Либо колхозные docker-compose-ы, либо кубер. _AB>Либо использовать что-то другое.
Но что.
>AWS, Azure и остальные вовсю предлагают serverless applications, например.
Это вариант, но тут опасность в том, что это абсолютно проприетарное АПИ, намертво привязывающее твоё приложение к конкретному облаку. Забанят твою компанию и будет больно. Кубернетес это открытая штуковина с кучей альтернативных предложений и возможностью всё сделать самому. Тут, конечно, уже бизнесу решать, какие риски и какие плюсы-минусы у каждого варианта. Судя по популярности кубернетеса привязываться люди не очень хотят.
Здравствуйте, smeeld, Вы писали:
vsb>>1 Без докера тебе надо: установить node.js, причём несколько штук и нужных версий
S>Это тот самый варинт макакина.
Почему?
>> установить несколько штук СУБД. Ещё сервисы любят биндиться на 8080 или 3000, то бишь тебе надо ещё с настройками портов мудохаться.
S>Это всё без докеров делалось и делается прекрасно в одну команду, если админ есть квалифицировнный, а не девляпс.
Квалифицированный админ, это тот, который бегает к квалифицированному разработчику и ставит ему постгрес? Почему бы квалифицированному админу не заниматься более интересными вещами, а квалифицированный разработчик будет делать это с докерами в одну команду.
vsb>>Я вот вообще не представляю, как это делать без геморроя.
S>Это всё прекрасно делается без доокеров. В докерах по самые уши только мелкие комашки у которых нет админов.
Может быть и так. Почему это плохо?
S>Зрелый прод их не использует, только для организиции приватных облаков, построенных на контейнерах.
