Как стать автором
Обновить
8
0

Пользователь

Отправить сообщение
Здравствуйте. Передал вопрос ответственным коллегам.
Да, мы понимаем, что MySQL не самый подходящий для этого инструмент. И как только у нас появятся проблемы, сразу же напишем реализацию под другое хранилище, архитектура проекта позволяет очень легко это сделать. За счет наличия локального кеша в памяти у каждого инстанса приложения обращений к бд не так много.
Пулл реквест такого масштаба равен переписыванию selenoid. А ggr в нашем случае не нужен, так как мы решили проблему с другой стороны.

Чем не подошел selenoid, написано в статье:


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

Фундаментальная проблема в методе хранения сессий.
Образы обновляются в конфигурации, а оркестрация для гибкой работы с кластером.

Внутри кластера конфигурация у каждого будут отличаться в зависимости от версии kubernetes и практик принятых в компании. Бд можно положить снаружи и просто указать адрес в конфиге. Алгоритм strategy kubernetes: происходит сравнение capabilities из запроса с нодами из конфигурации из стратегии, при совпадаении создается под. Possible values поправил, спасибо за комментарий.

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность