Comments 8
Спасибо большое за статью и за примеры использования.
Я бы хотел задать пару вопросов:
А почему выбрали метод DNS_PING, а не KUBE_PING
Снимаете ли вы метрики с WildFly и метрики самого Keycloak?
Есть опыт снятия метрик с Infinispan? Честно у меня так и не завелось.
Бывали ли у вас проблемы с таймаутами у infinispan? У меня были странные развалы кластера infinispan и пока проблема решилась только переключением на TCP с UDP.
livenessProbe/readinessProbe специально отсутствуют у Infinispan?
Бывали ли у вас проблемы с replicated cache у Infinispan? С режимом работы sync/async? Я пока перешел на sync из-за развала replicated cache.
А что это за IP-адреса в JAVA_OPTS ?
-Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?
Проводили ли вы нагрузочное тестирование? Возможно есть какие-то утилиты для проведения таких тестов?
А точно ли это лучший способ? Может стоит заменить на корректный shutdown:
jboss-cli.sh --connect command=':shutdown(timeout=30)'
Год назад мне очень помог этот репозиторий и соответствующая статья.
Тестировали ли вы реальную отказоустойчивость? Т.е. убивали ли поды Keycloak/Infinispan/Вырубали одну из нод в кластере. И как это все переживало эти тесты?
Поды - да, включали / выключали. С нодами - специально нет.
Про метрики. мы используем вот этот плагин: https://github.com/aerogear/keycloak-metrics-spi
И вот мой дашборд под них, который показывает всё, что нам нужно: https://grafana.com/grafana/dashboards/14607
А что это за IP-адреса в JAVA_OPTS ? -Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106https://en.wikipedia.org/wiki/IP_multicast
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml
В дополнение спрошу, а почему не использовали JDBC_PING (про KUBE_PING уже спросили) и deployments.
Зачем modcluster в данной настройке, можно просто балансить по clusterip?
Multicast так же не нужен (он в большинстве инсталляций облаков\куберов не работает), все задачи jgroups выполняются на unicast.
Если позволите, несколько «оффтоп»-вопрос по keycloak, как к более опытным специалистам в данном вопросе:
Пробую использовать keycloak в своем pet-проекте (пока больше в целях самообучения):
Развернул в докере: keycloak, postgries БД для него, nginx со статическим vue приложением и arangodb+foxx в качестве основной базы приложении и REST API к ней.
Стыковка Vue и Keycloak прошли без проблем — проверяется наличие актуального токена, если что кидается на форму авторизации, получаем оттуда токен обратно — дальше данные по пользователю получаю без проблем.
А вот дальше начались проблемы.
Я надеялся, что я полученный токен передам в свой REST API и там смогу его проверить — ну то есть уже со стороны серверного приложения внутри REST API дернуть какой-нибудь endpoint (например: auth/realms/{realm}/protocol/openid-connect/token/introspect или auth/realms/{realm}/protocol/openid-connect/userinfo) и подтвердив что он валидный и проверив доступы отдать пользователю то, что он просит.
Но ни один из перечисленных endpoint не хочет признавать мой токен валидным при обращении с серверной стороны REST API.
Так же пробовал делать валидацию без обращения к endpoint, но не смог найти рабочего решения под NodeJS для декодирования RS256, а keycloak только его сейчас и поддерживает насколько я понял.
Подскажите пожалуста:
- Могут ли токены передаваться между разными клиентами? Ну то есть сайт получивший токен на чистом клиенте, отдает его на сервер, где уже другой keycloak клиент должен проверить его валидность и получить данные по нему из keycloak? Возможен ли такой сценарий?
- Возможно нужно использовать и там и там реквизиты одного keycloak-клиента, но ведь по логике статическое веб-приложение должно быть клиентом c Access type = public, в то время, как серверное приложение должно быть bearer-only. Или я ошибаюсь?
- Выяснил, что если даже одним клиентом обращаться к keycloak по разным адресам, то корректный результат он отдает только при обращении на тот же адрес, по которому изначально авторизовывался. Поясню: при перенаправлении на форму авторизации с сайта идет обращение на публичный адрес, а когда обращаюсь с серверного приложения он доступен уже по внутреннему адресу, который от внешнего отличается. Опять же возможный ли это сценарий? И если да, то какие особенности настройки keycloak под это могут быть?
Настраиваем отказоустойчивый Keycloak с Infinispan в Kubernetes