где легачи, какие файлы, какие переменные на каком этапе, всё в кучу)

Свое легаси или чужое?

OTRS, как пример. Древний как говно мамонта. Лезть туда руками я совсем не хочу.

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

Так, мы сейчас конкретную проблему решаем или сферически в вакууме делаем всех счастивыми?

Повторюсь, можно конечную проблему описать?

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

А задача какая?

OTRS, как пример. Древний как говно мамонта. Лезть туда руками я совсем не хочу.

И его несколько энвов держать надо и еще эти энвы плодить часто?

И где не применимо?

что 12 факторов говорят про стораджа? :)

И его несколько энвов держать надо и еще эти энвы плодить часто?

Да, на него завязаны наши сервисы. QA'м хочется поднимать полное окружение для тестов.

А задача какая?

Задача - каталог каких-либо итемов, другие приложения разные запросы к нему делают и получают данные

Да, на него завязаны наши сервисы. QA'м хочется поднимать полное окружение для тестов.

Ну тогда в чем проблема создать обвязку в качестве точки входа, которая и будет генерить конфиг на основе переменных среды?

Тут проблема не в задаче а в правильности размещения приложений.

Ок. Опишу более детально. Есть около 40 сервисов (часть своих, часть легаси). У каждого из них есть свои конфиги (свои можно переписать на ENV, но это будет долго). Сейчас есть сервис хранения и раздачи конфигов. При подъеме сервиса дергаем курлом конфиг и поднимаемся. Вроде все отлично, но меня смущает безопасность и сама идеология. Хотелось бы отказаться от этого сервиса с конфигами и хранить их как-то более правильно.

Етцд/консул

Вместо курла

Не?

чем будет отличаться от прошлого новаторского подхода с сервисом хранения и раздачи конфигов? =)

опять запускаешь что то, что непонятно как конфигурируется и неизвестно какое состояние имеет

Вот

Конфигмап выглядит куда лучше. Хотя я пока и не до конца понимаю

опять запускаешь что то, что непонятно как конфигурируется и неизвестно какое состояние имеет

Почему непонятно и неизвестно?

Ваще если конфиг никогда во время жизни приложения не меняется, то конфигмапы ок

Почему непонятно и неизвестно?

потому что конфиг это внешняя сущность получается. не ясно состояние конфига, он зависит от времени запуска или от момента перечитывания конфига. я хз как такие динамические варианты с конфигурированием ПО решаются. железный вариант - изменился конфиг - ты или ролллинг апдейт сделал, или форсил релод приложения. и ты видишь в состоянии аппа какой у него конфиг

Ваще если конфиг никогда во время жизни приложения не меняется, то конфигмапы ок

Именно, если приложение поддерживает динамическую конфигурацию и фактически запрашивает значения и во время работы по определенной бизнес логике, то etcd/consul/zookeper вполне ок.

Конфигмап выглядит куда лучше. Хотя я пока и не до конца понимаю

Я вот не понял, если у тебя всё запскается через ansible, и ты в нём максимально используешь enventory, то почему бы тебе не генерить на лету yaml файл из темплейта посредством envsubst и транслировать его напрямую в kubectl create/apply -f - ? Зачем ещё конфигматы городить?

Если только при старте или явном релоаде то зачем приседать и тащить еще одну зависимость.

потому что конфиг это внешняя сущность получается. не ясно состояние конфига, он зависит от времени запуска или от момента перечитывания конфига. я хз как такие динамические варианты с конфигурированием ПО решаются. железный вариант - изменился конфиг - ты или ролллинг апдейт сделал, или форсил релод приложения. и ты видишь в состоянии аппа какой у него конфиг

В нашем случае конфиг статический и меняется сильно редко. Дергаем при старте из сервиса и сохраняем внутри контейнера.

А чем не нравится текущий подход, ну не считая, что это велосипед?

Я вот не понял, если у тебя всё запскается через ansible, и ты в нём максимально используешь enventory, то почему бы тебе не генерить на лету yaml файл из темплейта посредством envsubst и транслировать его напрямую в kubectl create/apply -f - ? Зачем ещё конфигматы городить?

У меня ансибль только для дева/стейджа. Локально в офисе для бареметал. В AWS там ансибля нет.

Резюмирую: "env legacy, потому что в нашем случае конфиг статический"

У меня ансибль только для дева/стейджа. Локально в офисе для бареметал. В AWS там ансибля нет.

но какой-то CD же есть?

А чем не нравится текущий подход, ну не считая, что это велосипед?

Да я не говорил, что он мне не нравится. Смущает - да.

но какой-то CD же есть?

Есть

А что смущает?

на нём можно тоже самое сделать

В проде пока нет куба. Строю в деве и хочу сделать более-менее правильно.

А что смущает?

Безопасность (относительная простота доступа к конфигам).

Ладно. Спасибо всем за дискуссию. Довольно не мало вариантов накидали. Буду думать и читать. :)

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

2 или 3

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

В одном сете одназначно хранить не стоит

Если не планируется увеличивать количество узлов базы в зависимости от нагрузки, я бы вообще не держал базу в кубе.

Ну тут минус в том, что накатываться апдейт долго будет, т.к. базу на новый под сливать надо. Но тогда приложение может обращаться к базе через локалхост, не ходя в сеть

Ребят, на сколько я знаю, кол-во серверов etcd изменить не выйдет, верно? Хотелось бы добавить мастеров в других локациях… А переносить текущие, тоже не очень весело

Ребят, на сколько я знаю, кол-во серверов etcd изменить не выйдет, верно? Хотелось бы добавить мастеров в других локациях… А переносить текущие, тоже не очень весело

с чего это не выйдет?

по документации etcd добавляешь ноды

etcd разве умеет в мультимастер?

только вот зачем их в другие локации уносить?

что значит добавить мастеров?

etcd разве умеет в мультимастер?

лидер всегда один

лидер всегда один

так и я о том

что значит добавить мастеров?

вангую, что мастер-ноды совмещены с etcd-нодами

только вот зачем их в другие локации уносить?

Затем что после недавнего падения hetzner пришлось ручками consul’у говорить кто там главный. Ибо большая часть кластера оказалась там.

вангую, что мастер-ноды совмещены с etcd-нодами

Да, kubespray ем разворачивал. Правда там пока ничего особо нет и крутится в тестовом режиме, но накатывать заново - тоже время

Да, kubespray ем разворачивал. Правда там пока ничего особо нет и крутится в тестовом режиме, но накатывать заново - тоже время

он не очень-то бережно с etcd обращается. в мастер недавно кучу фиксов слили насчет этого. имеет смысл обновиться.

Спасибо за инфу. Ну dev обновил, с ним всё ок было.

Вообще, лично я планирую уходить от kubespray в сторону своего ансибловелосипеда. Кубспрей тот еще черный ящик, особенно при обновлениях, имхо.

Кстати, раз уж зашел разговор: а ни у кого метрики ноды не задваиваются при использовании prom operator? В прометеусе по два раза экспортеры дискаверятся

сейчас через kubeadm кластер весьма просто разворачивается, зачем какой-то kuberspray?

Это раньше приходилось городить плэйбуки которые раскидывают бинари, конфиги, все эти дела.

И еще момент, никто не извращался так: нужно поднять еще один кластер монги, есть мысль добавить worker ноды и на них не через куб поставить монгу. Профит - легко подключить к мониторингу, минусы …?

kubeadm уже умеет мультимастер поднимать?

kubeadm уже умеет мультимастер поднимать?

пол года назад когда я смотрел это было в бэтке

сейчас через kubeadm кластер весьма просто разворачивается, зачем какой-то kuberspray?

+ за kubespray - поддержка coreos

если не ошибаюсь

kubeadm уже умеет мультимастер поднимать?

https://kubernetes.io/docs/setup/independent/high-availability/

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

тут его не любят, пиши в группу докера)

тут его не любят, пиши в группу докера)

скинь группу, плз)

скинь группу, плз)

В описании есть

В описании есть

спс

В описании есть

а она существует, та что в описании?

а она существует, та что в описании?

Ага

ого, я там забанен чтоли)) спасибо

пол года назад когда я смотрел это было в бэтке

С напильником.

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

Если у вас приложение висит вместе с базой, то вы не отмасштабировать отдельно их не сможете, ни разнести на разные ноды. Остальные два варианта debatable, классически верным считается держать базу отдельно (потому что иначе вы либо все равно ее привязываете к конкретным нодам, либо она у вас висит с сетевым диском, и там могут быть совсем интересные непредвиденные случаи), но это убивает половину ценности наличия кубера.

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

edit или apply -f не канает?

Имеется в виду ситуация, когда deployment потребляет конфиг, конфиг меняется, а deployment (точнее, поды) нужно передёргивать руками

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

рализовать в приложении перечитывание конфигов при их изменении

рализовать в приложении перечитывание конфигов при их изменении

или взять хельм

А хельм магический апи кубера использует?

кажется только обычный вариант ?

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

Ни на каких. Говоря, т.к. имею его в проде. Наколенное поделие

что 12 факторов говорят про стораджа? :)

Хорошо накинул

а можно ли прикрутить s3 bucket как shared storage?

minio?

а можно ли прикрутить s3 bucket как shared storage?

крайне не рекомендуется

хотя извращенцы находились

а что посоветуете?

BMR?

если да - ceph или локальное хранилище если нет - используйте решение вашего провайдера (Amazon EBS/Google storage)

cпасибо