Anton
А в кубере сервис который лазает в дб
Andor
Ну так и скажи этому сервису адреса твоих столонов
Andor
Тупо статикой
Anton
допустим есть 3 ноды n1 n2 n3 - на каждой входная точка, допустим n1 упал - клиент по роунд робин переключится на n2
Anton
Ну так и скажи этому сервису адреса твоих столонов
к сожалению сервис на входе понимает только 1 линк
Andor
То есть клиент сам ловит падения?
Andor
Тогда проблема в чём?
Anton
По ходу сумбурно обясняю
1. Клиент в единый момент времени может работать только с 1 сервисом, но может содержать ip других сервисов и если ответ текущего сервиса превышает таймаут - переключается на следующий
2. Сервис может работать только с одним линком к дб
Anton
client 1-> n1 svc -> n1 stolon-proxy
2-> n2 svc -> n2 stolon-proxy
3-> n3 svc -> n3 stolon-proxy
Andor
Не понял что означает второй пункт
Andor
Что значит "работать только с одним линком"?
Anton
ну в сервисе нельзя указать несколько IP постгреса
Andor
Тогда что значит "может держать другие адреса"?
Andor
Ничо не понимаю
Anton
клиент это другой софт - живет где то на компе - конектится на сервис - который в кубере
Andor
Ощущение что всё что ты хочешь можно двумя Service сделать
Andor
Если не одним
Andor
Но задачу всё ещё не понимаю
Anton
Я в кубере совсем нуб =)
Anton
Ощущение что всё что ты хочешь можно двумя Service сделать
Общая задача похожа на сервис с балансировкой - только соединение у клиента в сервис постоянное, и если он подключился к какому либо endpoint желательно чтобы он там и оставался
Andor
Общая задача похожа на сервис с балансировкой - только соединение у клиента в сервис постоянное, и если он подключился к какому либо endpoint желательно чтобы он там и оставался
Ну он если держит соединение, то так и останется к одному подключен
Anton
в общем можно все stolon-proxy обеденить в сервис
Anton
и не изголятся
Andor
Ну вот как-то так для меня выглядит, да
Anton
ну просто по мере переноса в кубер, стараюсь оставитьстарую логику, часто забывая что часть работы кубер может делать за меня =)
Andor
А могут и не быть
Andor
Ваще слабо представляю как оверлейные сети могут быть проще чем л3 роутинг
Andor
Для этого и хочется большое сравнение
Михаил
Ваще слабо представляю как оверлейные сети могут быть проще чем л3 роутинг
В инсталляции. Привез flannel и поехали, а с калико про какие-то as надо знать)
Михаил
Andor
Калико ж умеет с ип-ип
Andor
Не только бгп
Михаил
И увидишь статистику)
Andor
Девопсы
Михаил
темплейтинг может быть вообще банально на баше скрипт, который у контейнера выступает в качестве энтрипоинта
Темплейты баш скриптом путь в ад
Andor
И какую проблему решит это действие? :)
Михаил
По ходу сумбурно обясняю
1. Клиент в единый момент времени может работать только с 1 сервисом, но может содержать ip других сервисов и если ответ текущего сервиса превышает таймаут - переключается на следующий
2. Сервис может работать только с одним линком к дб
Ну так столон в кубе тебе решит эти проблемы
Andor
Кажется перенос столона в куб - сильно больше задача
Anton
Ну так столон в кубе тебе решит эти проблемы
А какие плюсы, etcd + kube-dns его не заменят? Если не считать шаблоны
Silver 👻
Гайз, а кто как конфиги в контейнер подсовывает?
Anton
Ты можешь по нормальному объяснить твою проблему?
Моя пробоема что столон получается снаружи кластера, и мне его надо прописать в сервисах так чтобы они не заметили падение ноды
Михаил
Моя пробоема что столон получается снаружи кластера, и мне его надо прописать в сервисах так чтобы они не заметили падение ноды
Ну так затащить в куб. И как раз через кубовый сервис его выставить
Silver 👻
Переменные окружения?
Да, это хорошо. Ну, а если Легаси? Энв переменные + шаблонизация? Или как?
Lex
Ну тогда в файл его и на вход легаси
Lex
Ну или враппер который готовит конфиг на основе окружения
Vladimir
а есть что нибудь готовое как в ансибле шаблонизатор j2
kube template какой нибудь?
Leo
На этапе сборки контейнера
Leo
Если есть возможность подпни разрабов
Silver 👻
Вот. Файлы у меня и есть. Все завернуто в контейнер с нжинкс, который их раздает. Но это как-то... Странно и несекурно что-ли.
Silver 👻
Вот и советуюсь, как бы это улучшить
Denis
а есть что нибудь готовое как в ансибле шаблонизатор j2
kube template какой нибудь?
Если правильно понимаю, то возможно для этого helm подойдет
Vladimir
Мы юзаем ансибль для этого, что бы на этапе сборки контейнера прокидывать в него конфиги, а их можно из ansible-secret подтягивать.
Vladimir
Вот. Файлы у меня и есть. Все завернуто в контейнер с нжинкс, который их раздает. Но это как-то... Странно и несекурно что-ли.
Silver 👻
Мы юзаем ансибль для этого, что бы на этапе сборки контейнера прокидывать в него конфиги, а их можно из ansible-secret подтягивать.
Я считаю, что хранить готовые конфиги в самом образе - это как-то не правильно.
Silver 👻
Его ж надо и на деве и на стейджа ещё запускать. И как его в девовую базу тогда отправлять?
Konstantin
Silver 👻
Т.е. таки энв + шаблонизатор?
Konstantin
Динамические конфиги, работает на ура
Silver 👻
Можно подробнее? Ссылку там какую... Спасибо.
Konstantin
Можно подробнее? Ссылку там какую... Спасибо.
Да любой докерфайл на гитхабе глянь, entrypoint скрипт кушает env и генерит. Логика одна. Кто-то на баше, кто-то на го
Silver 👻
А, ну т.е. как я и говорил. Энв + шаблон
Silver 👻
Ок. Это понятно и логично
Silver 👻
Как разделять энв для дева, стейджа, etc?
Konstantin
Шаблон (tpl) или просто строку запуска генерит
Silver 👻
Допустим вот в одном окружении Линк на одну базу, а в другом Линк в другую базу