Комментарии 8
Infinispan кстати еще раньше Keycloak перешел на кваркус и уже ушел в натив.
А с болью и временем запуска Keycloak - скорее бы.
>> у Quarkus быстрее запуск приложения, причём есть разница между первым и повторным запуском.
В отличии от того же SpringBoot, у Кваркуса очень много чего перенесено в build time из runtime. Например, RestClient который мы подключаем в виде интерфейса и аннотации @RegisterRestClientна стадии билда готовит код, а не создает все в рантайме.
Так же стоит заметить, что везде, где только возможно, там переходят на Vert.x и реактивное программирование, что так же сильно положительно сказывается на блокировках, трэдах и памяти в рантайм.
Есть конечно и ложка дегтя, некоторые вещи затянуты в кваркус из vertx имеют experimental статус в последнем и в самом кваркусе - статус Preview (который видно, только если собирать из стартера), баги там жуткие местами встречаются. Но т.к. код саппортится как в Кваркусе так и в Vert.x ребятами из RedHat, то в моем случае решали все очень оперативно (завтра опять пойду просить фиксить Vert.x под Oracle, который мягко говоря не работает).
Но в целом впечатление о Кваркус - сугубо положительные.
Он сам по себе стартует секунд 60, кажется на wildfly и при нескольких репликах это вообще не проблема. С кваркусом становится быстрее, но это не особо важно. Поэтому, например, мы не стали делать сборку с --build.
Долго там стартует кеш, если он большой и много офлайн токенов, но lazy loading таки завезли и он отлично решает проблему офлайн токенов.
Про кваркус согласен — звучит классно с точки зрения разработки, но, по крайней мере пока, на код кейклока влияния нет никакого и ничего не меняется.
чтобы не вдаваться в холивары, давайте просто скажу - контейнер или нода стартующая за 50-100ms из коробки всегда лучше чем та же но старующая 60 секунд. А keycloak даже голый стартует(или стартовал, на кваркусе пока не щупал) безумно долго.
>> по крайней мере пока, на код кейклока влияния нет никакого и ничего не меняется.
Должны стать меньше расходы по memory/cpu, должен держать больше CCU. В теории. Что там на практике - надо мерять.
P.S. Пробежался по исходникам 17го Keycloak. Они работу с базами (без реактивщины) поменяли. Местами http server/rest client (местами с реактивщиной, местами без) + подтянули мониторинг/healthcheck. Остальное пока осталось родное похоже.
Нативом пока не пахнет, но тенденция у RedHat похоже такая есть. Перевод продуктов на кваркус и в натив.
Это все, конечно, здорово, но приложение пятерочки больше месяца не работает:)
пока пользуемся 15.х, для конфигурации используется возможность запуска скриптов на старте через "/opt/jboss/startup-scripts/ХХХ" - проще, чем тягать конфиги целиком и мигрировать при смене версии
И я вот вроде не вижу криминала в этом, но почему-то дописывать нужное сразу в xml мне кажется более правильным. Сердцем чую :)
Кстати в чистом докере без кубера магия стартап скриптов не работает. При рестарте контейнера он пытается дописать в xml конфиги, которые там уже есть и грустит.
Keycloak X. Что за зверь и с чем его едят?