Pull to refresh

Comments 11

Infinispan кстати еще раньше Keycloak перешел на кваркус и уже ушел в натив.

А с болью и временем запуска Keycloak - скорее бы.

>> у Quarkus быстрее запуск приложения, причём есть разница между первым и повторным запуском.

В отличии от того же SpringBoot, у Кваркуса очень много чего перенесено в build time из runtime. Например, RestClient который мы подключаем в виде интерфейса и аннотации @RegisterRestClientна стадии билда готовит код, а не создает все в рантайме.

Так же стоит заметить, что везде, где только возможно, там переходят на Vert.x и реактивное программирование, что так же сильно положительно сказывается на блокировках, трэдах и памяти в рантайм.

Есть конечно и ложка дегтя, некоторые вещи затянуты в кваркус из vertx имеют experimental статус в последнем и в самом кваркусе - статус Preview (который видно, только если собирать из стартера), баги там жуткие местами встречаются. Но т.к. код саппортится как в Кваркусе так и в Vert.x ребятами из RedHat, то в моем случае решали все очень оперативно (завтра опять пойду просить фиксить Vert.x под Oracle, который мягко говоря не работает).

Но в целом впечатление о Кваркус - сугубо положительные.

А какая боль времени запуска keycloak?
Он сам по себе стартует секунд 60, кажется на wildfly и при нескольких репликах это вообще не проблема. С кваркусом становится быстрее, но это не особо важно. Поэтому, например, мы не стали делать сборку с --build.
Долго там стартует кеш, если он большой и много офлайн токенов, но lazy loading таки завезли и он отлично решает проблему офлайн токенов.

Про кваркус согласен — звучит классно с точки зрения разработки, но, по крайней мере пока, на код кейклока влияния нет никакого и ничего не меняется.

чтобы не вдаваться в холивары, давайте просто скажу - контейнер или нода стартующая за 50-100ms из коробки всегда лучше чем та же но старующая 60 секунд. А keycloak даже голый стартует(или стартовал, на кваркусе пока не щупал) безумно долго.

>>  по крайней мере пока, на код кейклока влияния нет никакого и ничего не меняется.

Должны стать меньше расходы по memory/cpu, должен держать больше CCU. В теории. Что там на практике - надо мерять.

P.S. Пробежался по исходникам 17го Keycloak. Они работу с базами (без реактивщины) поменяли. Местами http server/rest client (местами с реактивщиной, местами без) + подтянули мониторинг/healthcheck. Остальное пока осталось родное похоже.

Нативом пока не пахнет, но тенденция у RedHat похоже такая есть. Перевод продуктов на кваркус и в натив.

Это все, конечно, здорово, но приложение пятерочки больше месяца не работает:)

А с темой статьи это как связано?

Ну кушает человек плохо... Скоро 2й месяц... Мерещится...

Или AI/ML так написан, что на что-то так среагировал :)

пока пользуемся 15.х, для конфигурации используется возможность запуска скриптов на старте через "/opt/jboss/startup-scripts/ХХХ" - проще, чем тягать конфиги целиком и мигрировать при смене версии

Мы тоже, кстати.
И я вот вроде не вижу криминала в этом, но почему-то дописывать нужное сразу в xml мне кажется более правильным. Сердцем чую :)

Кстати в чистом докере без кубера магия стартап скриптов не работает. При рестарте контейнера он пытается дописать в xml конфиги, которые там уже есть и грустит.

Оставлю для тех, кто найдет эту статью. С чем столкнулся я, когда переходил со старого кейклока на новый:

  1. У нас используются самописные плагины. Чтобы они работали в JAVA_OPTS_APPEND пришлось добавить параметр -Dkeycloak.profile.feature.scripts=enabled

  2. Если используете Helm-чарт для KeycloakX, то переменные KC_HEALTH_ENABLED=true, KC_METRICS_ENABLED=true, KC_PROXY=edge, KC_HTTP_RELATIVE_PATH=/auth активны из коробки. Они активируются через разные параметры в values.yaml. Если вы определите их в своем кастомном файле в разделе extraEnv, то они задвоятся. В целом, ничего страшного, чарт задеплоится, но переменные будут отображаться в 2 экземплярах.

  1. Еще для работы самописного плагина пришлось активировать фичу Scripts. Документация говорит, что ее можно активировать через переменную окружения KC_FEATURES, но у меня не заработало. Заработало через добавление ключа --features='scripts' в раздел commands чарта. Вероятно, фичи изначально активируются/отключаются через ключи, а потом их можно включать и выключать через переменную окружения. В документации ответа на это не нашел.

Документация говорит, что ее можно активировать через переменную окружения KC_FEATURES, но у меня не заработало.

У меня в docker-compose заработло так: KC_FEATURES: "scripts"

Sign up to leave a comment.