Infinispan что это

Infinispan что это

Have something interesting to share with Java Eastern Europe community?

Toggle navigation

Infinispan – громкое имя для JBoss Cache или еще одно NoSQL решение?

Описание: JBoss Cache уже несколько лет как вырос из “коротких штанишек” и называется Infinispan. Сейчас это вполне серьезный Key-Value NoSQL со своими изюминками, такими как транзакционность. Попробуем разобраться детальнее как и в каких случаях имеет смысл его применять.

Тип выступления: Мини-доклад (15 минут)

Виталий Тимчишин

Luxoft, Украина
Виталий занимается разработкой и проектированием систем на языке Java более 9 лет. Имеет большой опыт работы с коммуникационными протоколами, базами данных и многопоточными приложениями, является экспертом в разработке и внедрении сложных неоднородных систем. На текущий момент занимается проектированием, разработкой и внедрением Java инфраструктуры для банковских систем связи повышеной надежности.

Настраиваем отказоустойчивый Keycloak с Infinispan в Kubernetes

В этой статье мы поделимся опытом развертывания в кластере Kubernetes устойчивой и масштабируемой инсталляции популярного решения для обеспечения «единого входа» (SSO) — Keycloak в связке с Infinispan (для кэширования пользовательских метаданных).

Keycloak и область применения

Keycloak – проект с открытым исходным кодом компании Red Hat, предназначенный для управления аутентификацией и авторизацией в приложениях, функционирующих на серверах приложений WildFly, JBoss EAP, JBoss AS и прочих web-серверах. Keycloak упрощает реализацию защиты приложений, предоставляя им бэкенд авторизации практически без дополнительного кода. За подробной информацией о том, как это осуществляется, можно обратиться к этому руководству.

Как правило, Keycloak устанавливается на отдельный виртуальный или выделенный сервер приложений WildFly. Пользователи однократно аутентифицируются с помощью Keycloak для всех приложений, интегрированных с данным решением. Таким образом, после входа в Keycloak пользователям не нужно снова входить в систему для доступа к другому приложению. Аналогично происходит и с выходом.

Для хранения своих данных Keycloak поддерживает работу с рядом наиболее популярных реляционных систем управления базами данных (РСУБД): Oracle, MS SQL, MySQL, PostgreSQL. В нашем случае использовалась CockroachDB — современная распределенная СУБД (изначально Open Source, а впоследствии — под BSL), которая обеспечивает согласованность данных, масштабируемость и устойчивость к авариям. Одной из её приятных особенностей является совместимость с PostgreSQL на уровне протокола.

Кроме того, в своей работе Keycloak активно использует кэширование: кэшируются пользовательские сессии, авторизационные и аутентификационные токены, успешные и неуспешные попытки авторизации. По умолчанию для хранения всего этого используется Infinispan. На ней мы остановимся подробнее.

Infinispan

Infinispan — это масштабируемая, высокодоступная платформа для хранения данных типа ключ-значение, написанная на Java и распространяемая под свободной лицензией (Apache License 2.0). Основная область применения Infinispan — распределенный кэш, но также её применяют как KV-хранилище в базах данных типа NoSQL.

Платформа поддерживает два способа запуска: развертывание в качестве отдельно-стоящего сервера / кластера серверов и использование в виде встроенной библиотеки для расширения функций основного приложения.

KC в конфигурации по умолчанию использует встроенный кэш Infinispan. Он позволяет настраивать распределенные кэши, чтобы репликация и перекаты данных осуществлялись без простоя. Таким образом, даже если мы полностью отключим сам KC, а потом поднимем его обратно, авторизованных пользователей это не затронет.

Сам IS хранит всё в памяти, а на случай переполнения (или полного отключения IS) можно настроить сбрасывание его данных в БД. В нашем случае эту функцию выполняет CockroachDB.

Постановка задачи

Клиент уже использовал KC как бэкенд авторизации своего приложения, но переживал за устойчивость решения и сохранность кэшей при авариях / развертываниях. Поэтому перед нами стояли две задачи:

1. Обеспечить надежность/устойчивость к авариям, высокую доступность.
2. Сохранить пользовательские данные (сессии, токены) при потенциальном переполнении памяти.

Описание инфраструктуры и архитектуры решения

Изначально KC был запущен в 1 реплике и настройками кэширования по умолчанию, т.е. использовался встроенный Infinispan, который все держал в памяти. Источником данных был кластер CockroachDB.

Для обеспечения надежности потребовалось развернуть несколько реплик KC. Keycloak позволяет это сделать, используя несколько механизмов автообнаружения. В первой итерации мы сделали 3 реплики KC, использующих IS в качестве модуля/плагина:

К сожалению, IS, используемый как модуль, предоставлял недостаточно возможностей для настройки поведения кэшей (кол-во записей, объем занимаемой памяти, алгоритмы вытеснения в постоянное хранилище) и предлагал только файловую систему как постоянное хранилище для данных.

Поэтому на следующей итерации мы развернули отдельный кластер Infinispan и отключили встроенный модуль IS в настройках Keycloak:

Решение было развернуто в кластере Kubernetes. Keycloak и Infinispan запущены в одном namespace по 3 реплики. За основу для такой инсталляции был взят этот Helm-чарт. CockroachDB разворачивалась в отдельном пространстве имен и использовалась совместно с другими компонентами клиентского приложения.

Практическая реализация

Полные примеры Helm-шаблонов доступны в нашем репозитории flant/examples.

1. Keycloak

КС поддерживает несколько режимов запуска: standalone, standalone-ha, domain cluster, DC replication. Режим standalone-ha является идеальным вариантом для запуска в Kubernetes, потому что легко добавлять/удалять реплики, общий конфиг-файл хранится в ConfigMap, правильно выбранная стратегия развертывания обеспечивает доступность узлов при обновлении ПО.

Хотя для KC не требуется постоянного файлового хранилища (PV/PVC) и можно было выбрать тип Deployment, мы используем StatefulSet. Это делается для того, чтобы задавать имя узлов в Java-переменной jboss.node.name при настройке обнаружения узлов на основе DNS_PING . Длина этой переменной должна быть меньше 23 символов.

Для настройки KC используются:

• переменные окружения, которые задают режимы работы KC (standalone, standalone-ha и т.д.);
• конфигурационный файл /opt/jboss/keycloak/standalone/configuration/standalone-ha.xml , который позволяет выполнить максимально полную и точную настройку Keycloak;
• переменные JAVA_OPTS , определяющие поведение Java-приложения.

По умолчанию KC запускается со standalone.xml — этот конфиг сильно отличается от HA-версии. Для получения нужной нам конфигурации добавим в values.yaml :

# Additional environment variables for Keycloak extraEnv: | … - name: JGROUPS_DISCOVERY_PROTOCOL value: "dns.DNS_PING" - name: JGROUPS_DISCOVERY_PROPERTIES value: "dns_query=>-headless.>.svc.>" - name: JGROUPS_DISCOVERY_QUERY value: ">-headless.>.svc.>"

После первого запуска можно достать из pod’а c KC нужный конфиг и на его основе подготовить .helm/templates/keycloak-cm.yaml :

$ kubectl -n keycloak cp keycloak-0:/opt/jboss/keycloak/standalone/configuration/standalone-ha.xml /tmp/standalone-ha.xml

После получения файла переменные JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES можно переименовать или удалить, чтобы KC не пытался создавать этот файл при каждом повторном деплое.

Устанавливаем JAVA_OPTS в .helm/values.yaml :

java: _default: "-server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED -Djava.awt.headless=true -Djboss.default.jgroups.stack=kubernetes -Djboss.node.name=$ -Djboss.tx.node.id=$ -Djboss.site.name=$ -Dkeycloak.profile.feature.admin_fine_grained_authz=enabled -Dkeycloak.profile.feature.token_exchange=enabled -Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106 -Djboss.as.management.blocking.timeout=3600"

Для корректной работы DNS_PING указываем:

-Djboss.node.name=$, -Djboss.tx.node.id=$ -Djboss.site.name=$ и -Djboss.default.multicast.address=230.0.0.5 -Djboss.modcluster.multicast.address=224.0.1.106 

Все остальные манипуляции проводим с .helm/templates/keycloak-cm.yaml .

    jdbc:postgresql://$/$$ postgresql IdleConnections  $ $ SELECT 1 true 60000    org.postgresql.xa.PGXADataSource     … 

         true org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory   =2) - для их сохранности в момент редеплоя --> 

Настройки JGROUPS и DNS_PING :

        $ .   $ .    "/> "/> "/> " multicast-port="45700"/>  " multicast-port="45688"/> "/> "/> " multicast-port="23364"/>  

Наконец, подключаем внешний Infinispan:

  … " port="11222"/> … 

Подготовленный XML-файл монтируем в контейнер из ConfigMap’а .helm/templates/keycloak-cm.yaml :

apiVersion: apps/v1 kind: StatefulSet metadata: name: keycloak-stand spec: serviceName: keycloak-stand-headless template: spec: containers: image: registry.host/keycloak name: keycloak volumeMounts: - mountPath: /opt/jboss/keycloak/standalone/configuration/standalone-ha.xml name: standalone subPath: standalone.xml volumes: - configMap: defaultMode: 438 name: keycloak-stand-standalone name: standalone

2. Infinispan

Для настройки Infinispan будем использовать конфиг по умолчанию /opt/infinispan/server/conf/infinispan.xml из Docker-образа infinispan/server:12.0 и на его основе готовим .helm/templates/infinispan-cm.yaml .

Первым делом настраиваем auto-discovery. Для этого устанавливаем уже знакомые нам переменные окружения в .helm/templates/infinispan-sts.yaml :

 env: > - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: JGROUPS_DISCOVERY_PROTOCOL value: "dns.DNS_PING" - name: JGROUPS_DISCOVERY_PROPERTIES value: dns_query=>

… и добавляем секцию jgroups в XML-конфиг:

   " bind_port="$" enable_diagnostics="false"/> " dns_record_type="A" stack.combine="REPLACE" stack.position="MPING"/>  " dns_record_type="A" stack.combine="REPLACE" stack.position="PING"/>  

Для корректной работы Infinispan c CockroachDB нам пришлось пересобрать образ Infinispan, добавив в него новую версию SQL-драйвера PostgreSQL. Для сборки использовалась утилита werf с таким простым werf.yaml :

--- image: infinispan from: infinispan/server:12.0 git: - add: /jar/postgresql-42.2.19.jar to: /opt/infinispan/server/lib/postgresql-42.2.19.jar shell: setup: | chown -R 185:root /opt/infinispan/server/lib/

Добавим в XML-конфиг секцию :

    value   

В Infinispan мы должны описать те кэши, которые в KC были созданы с типом distributed-cache. Например, offlineSessions :

Таким же образом настраиваем и остальные кэши.

Подключение XML-конфига происходит аналогично тому, что мы рассматривали Keycloak.

На этом настройка Keycloak и Infinispan закончена. Повторюсь, что полные листинги доступны на GitHub: flant/examples.

Заключение

Использование Kubernetes в качестве фундамента позволило легко масштабировать решение, добавляя по мере необходимости или узлы Keycloak для обработки входящих запросов, или узлы Infinispan для увеличения емкости кэшей.

С момента сдачи данной работы клиенту прошло 2 месяца. Каких-либо жалоб и недостатков за этот период не выявлено. Поэтому можно считать, что поставленные цели достигнуты: мы получили устойчивое, масштабируемое решение для обеспечения SSO.

P.S.

Читайте также в нашем блоге:

• «Обзор операторов PostgreSQL для Kubernetes. Часть 1: наш выбор и опыт»;
• «Наш опыт с графовой базой данных Dgraph в Kubernetes»;
• «Миграция Cassandra в Kubernetes: особенности и решения».

In-Memory Distributed Data Store

Infinispan is an open-source in-memory data grid that offers flexible deployment options and robust capabilities for storing, managing, and processing data. Infinispan provides a key/value data store that can hold all types of data, from Java objects to plain text. Infinispan distributes your data across elastically scalable clusters to guarantee high availability and fault tolerance, whether you use Infinispan as a volatile cache or a persistent data store.

Ready to start using Infinispan?

Infinispan 14.0.19

Features

Interoperability

Access data across multiple protocols and programming languages.

Resilient and Fault Tolerant Data

Ensure data is always available to meet demanding workloads.

ACID Transactions

Guarantee that data is always valid and consistent.

Clustered Processing

Process data in real-time without burdening resources.

Queries

Perform simple, accurate, and fast searches across distributed data sets.

Boost Application Performance

Infinispan turbocharges applications by storing data closer to processing logic, which reduces latency and increases throughput.

Available as a Java library, you simply add Infinispan to your application dependencies and then you’re ready to store data in the same memory space as the executing code.

If you want to provision a data layer that is independent of your applications, you can use Infinispan Server for remote access to data with in-memory performance. Clients are a single network hop away from data through consistent hashing techniques and can make requests over HTTP or with a custom binary TCP protocol called Hot Rod.

Achieve High Availability and Elasticity

Infinispan provides trusted open-source technology to deliver scalability to meet workload demands and reduce resource utilization. At the same time, Infinispan distributes your data across clusters so no single point of failure causes data loss.

One popular use for Infinispan is as a shared store for stateful data, such as user HTTP sessions. Applications can stay lightweight and avoid heap usage by externalizing sessions to Infinispan clusters, which act as an independent data layer.

Backup Across Data Centers

Infinispan clusters running in different geographical locations can form global clusters to back up your data across sites. If sites go offline clients can immediately switch to an available cluster, making sure data center faults do not cause service interruptions.

When using the Infinispan Operator with Kubernetes environments such as Red Hat OpenShift, cross-site replication capabilities make your data ready for hybrid and multi cloud deployments.

Infinispan also guarantees data consistency when using cross-site replication, even in cases where clients make concurrent writes at different locations that use asynchronous replication. So your data is always there and always accurate, no matter where you’re running.

Keycloak X. Что за зверь и с чем его едят?

Недавно мы с коллегами из X5 Tech проводили митап, на котором разбирали, что такое Keycloak X и чего от него ждать. Для тех, кто пропустил или предпочитает читать, а не смотреть, подготовили текстовый вариант.

Меня зовут Виктор Попов, я техлид DevOps-команды в X5 Tech. И я расскажу, как сэкономить время на чтении плохой документации, с какими сложностями можно столкнуться при обновлении на Keycloak X и как их преодолеть.

Что такое Keycloak X

Keycloak — это Java-приложение, которое запускается на application-сервере. Исторически это был Wildfly для open source версии или JBoss EAP для Red Hat SSO.

Keycloak X — это тот же Keycloak, только на Quarkus. Само приложение остаётся прежним, но есть нюансы.

Quarkus — это фреймворк Java, заточенный под Kubernetes и container first. С Quarkus можно использовать GraalVM, но Keycloak пока этого не делает. Надеюсь, что пока.

Зачем всё это надо

Зачем нужно было менять Wildfly на Quarkus? Например, вот зачем:

Согласно официальной документации, у Quarkus быстрее запуск приложения, причём есть разница между первым и повторным запуском. А еще нужно меньше памяти.

Также разработчики поменяли модель хранения данных и упростили конфигурацию, но обо всём по порядку.

Смена модели хранения данных

Наконец-то Keycloak переходит на полностью внешний Infinispan. В WildFly версии Keycloak выпилить Infinispan полностью невозможно. Можно добавить внешние ноды или кросс-DCрепликацию в другой кластер IS, но полностью отделить Infinispan от Keycloak не получится, только расширить его.

Теперь же Infinispan используется как внешний сервис. Да, он может запускаться в тех же контейнерах, что и Keycloak, но возможность запуска внешнего Infinispan рассматривается как продавая и целевая.

Подробнее про смену модели хранения данных тут:

Упрощение конфигурации

Раньше Wildfly конфижился здоровенными XML-никами. Пример дефолтных конфигов, которые идут в контейнере вместе с Keycloak:

Первое — из Keycloak 16, а второе — из Keycloak 17. Как видите, XML-ник на первом скрине — это 652 строчки, на втором — 45 строчек, причём большая часть — это комментарии. Новая версия подарила нам, нормально читаемый конфигурационный файл.

Но немного XML всё же осталось:

Infinispan конфижится в XML, так что у нас сохраняется файл, в котором описывается состояние кэшей. Но для небольших инсталляций можно его даже ни разу не увидеть и жить счастливо. По умолчанию, в стандартном файле всего 85 строк.

Плюс, Keycloak умеет самостоятельно создавать нужную конфигурацию кэшей во внешнем Infinispan. Если Keycloak видит пустой Infinispan, он создаёт из конфига кэши в той конфигурации, которая описана. Больше не нужно подготавливать внешние реплики Infinispan, как это было раньше при расширении кластера кешей.

В каком всё это состоянии

11 февраля 2022 года вышел Keycloak 17.0.0 – это первая стабильная Quarkus-версия. В целом Quarkus-версии с нами уже почти год, но это были превью разной степени сырости. В них часто и много чего менялось. Особой пользы ковыряться в ранних версий не было, потому что стоило тебе разобраться с одной, как в следующей всё уже было по-другому.

Сейчас Widfly версия объявлена Legacy. То есть дефолтная версия Keycloak на Quarkus. И ориентировочно в июле Widfly версии перестанут выходить вообще.

Для пользователей RedHat SSO обещают ещё два года поддержки JBoss версии — они могут мигрировать сильно медленнее. Но Enterprise платит деньги, в конце концов. Всем остальным стоит заранее позаботиться о миграции на Keycloak X — все там будем, ничего с этим не поделать. Но процесс перехода можно сделать чуть менее болезненным.

В каком состоянии документация

Этапы, которые я прошёл при подготовке этого доклада:

Когда я начинал готовиться, была только шестнадцатая версия, и документация отсутствовала вообще. Keycloak 17.0.0 наконец-то принёс нам документацию, и сначала она показалась вполне приличной.

Вот несколько полезных ссылок:

По мере того как я закапывался во всё это, я понял, что прямо сейчас с документацией всё по-прежнему плохо. Много вещей не документированы. Есть прикольные штуки, которые встречаются в примерах, но не встречаются в документации.

Предположим, мы тюним connection pool к базе данных. В документации есть такие настройки:

Они хорошо описаны, их можно использовать. Но, представим, что мы также тюним time out подключения к базе данных или проверку подключения. Раньше это настраивалось в XML-нике. Как настраивается сейчас — непонятно, потому что такой информации нет.

А вот настройка, которая есть в примере, но нет в документации:

Понять, что делает параметр, вроде можно, но в документации его нет. Остаётся только гадать и ждать пока допишут. Ну или лезть в исходники, ведь это лучшая документация ��

У нас осталось с десяток параметров, которые не перенесли с Wildfly на Quarkus-версию. Ждём, когда станет понятно, как это сделать.
В основном это всякие настройки подключения Keycloak к базе данных, в нашему случае к Postgres.
Но даже без этих параметров мы планируем миграцию на Quarkus в ближайшие пару месяцев.

Важные изменения: настройки по умолчанию

Изменились настройки по умолчанию, которые важно учитывать при миграции:

Keycloak в его текущей Wildfly-реализации реагирует на хедер Host либо X-Forward-Host и отдаёт все эндпоинты и токены согласно тому, что получил в этих хедерах. Например, вы кидаете curl запрос на получение токена с произвольным хедером Host и у токена в поле Issuer будет указано имя хоста из хедера.

Мы в X5 это используем. У нас некоторые приложения внутри кластера Kubernetes входят в Keycloak и получают токены от одного издателя. А снаружи через Ingres получают токены от другого издателя. В некоторых ситуациях это полезно и удобно.

Теперь же по умолчанию Keycloak выдаёт все токены и эндпоинты строго по hostname, указанному в настройках. И указывать hostname обязательно.
Но если выставить hostname-strict=false , то поведение будет такое же, как и в Wildfly версиях.

Это ломает существующие liveness и readiness проверки, а также прочие запросы к API, которые внешние пользователи могут использовать.
Добавление в настройки http-relative-path=/auth сохраняет старые пути.
Правда редиректа с mykeycloak.ru на mykeycloak.ru/auth всё же не будет, и ссылка по которой вы ходили в админку сломается, но можно добавить редирект на ingress перед keycloak.

Также по умолчанию http теперь отключён. Если вы крутите Keycloak в Kubernetes и терминируете SSL на Ingress, то работать не будет.
Вернуть старое поведение можно добавив в конфиг вот такой параметр:
http-enabled=true
А лучше честно пробрасывайте TLS внутрь кластера.

Важные изменения: темы и SPI

С темами всё хорошо: с крайне высокой вероятностью они продолжат работать, и ничего не сломается. Но тестирование никто не отменял, нужно обязательно прогонять всё на демостенде.

Из нового — изменился путь, куда нужно копировать темы, потому что директория JBoss пропала из opt:

• было — /opt/jboss/keycloak/themes
• стало — /opt/keycloak/themes

С SPI аналогичная история:

• если использовался только функционал keycloak, то, скорее всего, SPI будут работать;
• если использовался функционал WildFly, то SPI работать не будут, потому что Wildfly больше нет.

Но, думаю, если вы пишите кастомные плагины, вы уже знаете, что каждая новая версия Keycloak это лотерея.
А если не пишите но хотите — вот тут коллеги рассказывают о том, как это делать и какие сложности это влечёт.

А ещё поменялся путь для плагинов — /opt/keycloak/providers
Ах да, мой любимый плагин с метриками на 17.0 работает.

Важные изменения: Build и Start

Специфика Quarkus — он предсобирает Java-приложения. При первом запуске приложение с его настройками запекается в некую исполняемую сущность, за счёт чего обеспечивается более быстрый повторный запуск.

Ключ —build «готовит» приложение к запуску с заданными настройками.

Можно сделать вот такой докерфайл:

FROM quay.io/keycloak/keycloak-x:17.0.0
RUN /opt/keycloak/bin/kc.sh —build —metrics-enabled=true

Собрать его, и получить контейнер, который будет запускать очень быстро.

Если вам критичен быстрый старт, это правильный способ. Вы сначала делаете —build, собираете контейнер, а потом используете ключ —start, чтобы запустить уже преднастроенное приложение.

Второй вариант — использовать ключ —auto-build, который при запуске всегда сначала прогоняет build, а потом запускает start. Получается дольше, но вам не нужен подготовительный этап, вы можете менять любые настройки, и ничего при этом не ломается.

Как обновлялся я: dockerfile

У нас Standalone-ha (в терминологии Wildfly релизов) инсталляция, внешняя база данных, Keycloak в 3-х репликах в Kubernetes, развёрнутый как statefull set. Мы пересобираем контейнер Keycloak, потому что подкладываем туда темы, внутренние сертификаты и прочие вещи.

Мы брали контейнер, копировали темы, добавляли сертификаты, удаляли старый XML, копировали новый XML, и возвращали на user 1000, который используется в контейнере keycloak изначально.

Поменялись пути, о которых я говорил выше. Теперь мы меняем два конфигурационных файла — у нас нет standaloneha.xml, зато есть keycloak.conf и cache.ispn

Мы меняем их на наши из репы и собираем контейнер.

Как я обновлялся: конфиги

Было:
Огромная xml портянка

Стало: keycloak.conf. Ниже его содержимое

cache=ispn cache-stack=kubernetes hostname-strict=false http-enabled=true db-pool-min-size=10 db-pool-max-size=100 http-relative-path=/auth features=token-exchange, admin-fine-grained-authz

Настроек стало сильно меньше. Теперь мы включаем фичи, меняем relative-path на /auth, чтобы все пути остались такими же как и были. Ещё тюним пул коннектов к базе данных, включаем http, отключаем strict hostname и выбираем cache-stack — некоторый набор настроек, которые идут из коробки и которые раньше отвечали за то, как собирается standalone-ha кластер.

Как я обновлялся: подключение к базе

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

DB_ADDR -> KC_DB_URL_HOST
DB_PORT -> KC_DB_PORT
DB_DATABASE -> KC_DB_URL_DATABASE
DB_USER -> KC_DB_USERNAME
DB_PASSWORD -> KC_DB_PASSWORD

Как видите, имена всех переменных для подключения к базе данных поменялись. Плюс, переменную DB_VENDOR я вынес в конфигурационный файл keycloak.conf, потому что это один из тех параметров, которые настраиваются на этапе —build. Тем самым я оставил себе возможность сделать билд на этапе сборки контейнера с настройками, если вдруг этого захочу, чтобы быстрее запускать приложение.

Зачем нужно было менять имена переменных?
У меня только одна версия:

Как я обновлялся: HA

Как HA конфижилось раньше:

У нас были переменные среды, и в Kubernetes мы использовали метод DNS_PING, чтобы ноды Infinispan находили друг друга с помощью JGroups. В переменных среды мы указывали discovery protocol, discovery properties и имя headless сервиса в k8s по которому и работал DNS_PING.

Как это конфижится сейчас:

cache=ispn cache-stack=kubernetes

Кажется, что стало намного проще. Есть настройка cache-stack, которая имеет готовый параметр для работы в kubernetes. Но проблема в том, что стэк Kubernetes берёт дефолтные настройки, где не указан адрес headles service, с помощью которого ноды находят друг друга — он смотрит непонятно куда, и кластер не собирается. Как задать адрес для dns.query в документации Keycloak не описано.

Об эту проблему я бился довольно долго, но в итоге нашёл в документации Infinispan, что можно задать адрес dns_query через Java Ops. Туда мы передали вот такой параметр:

-Djgroups.dns.query=keycloak-headless.keycloakx-tst.svc.cluster.local

И всё заработало.

Как я обновлялся: параметры запуска

Как было раньше:

В контейнер с Keycloak монтировали шельник, в котором запускался docker-entrypoint, идущий в комплекте с контейнером. Мы «скармливали» ему standalone-ha.xml и передавали какое-то количество параметров. Дальше он прогонял ещё один шельник, который обогащал XML-ник в Wildfly, добавлял в него параметры и запускался.

Теперь всё немного проще:

command: - /opt/keycloak/bin/kc.sh args: - --verbose - -cf /opt/keycloak/conf/keycloak.conf - start - --auto-build - --cache-stack kubernetes

Мы указываем путь конфигурационному файлу, с которым мы стартуем Keycloak. Говорим, что его надо стартануть и указываем ключ —auto-build, потому что мы хотим, чтобы перед стартом он сбилдился. В качестве cache-stack указываем Kubernetes.

Важно: порядок параметров имеет значение. Если мы, например, поставим —auto-build до — start, то чуда не произойдёт — об это я тоже немного побился.

Ещё пара слов про важные изменения

Разработчики обещают ещё несколько полезных изменения. Одно из них — полноценное zero downtime upgrade между версиями. На Wildfly версии rolling update для контейнеров работает нормально только в рамках одной версии. Если мы захотим обновится полностью, то нужен даунтайм. Хотя минорные версии на свой страх и риск я все же обновлял без даунтайма ��

Это важное нововведение, потому что Infinispan теперь позиционируется как внешний компонент, но при этом никакой документации как подключить внешний Infinispan нет. Понятно, что надо просто где-то настроить hotroad connector, указать ему путь к Infinispan, и дальше всё заработает. Но как и где указать Hotroad connector нигде не написано.

Следующее важное изменение связано с внешними интеграциями. Сейчас часть функционала делается плагинами, которые надо вставлять в Keycloak — это сложно, больно и зачастую не очень правильно. Нам обещают, что появится возможность интегрироваться с внешними сервисами, например, по REST. Это значит, что мы сможем настраивать логику непосредственно в Keycloak. Но никакой документации и пруфов нет. Я очень хочу всё это проверить, как только появится документация, обязательно расскажу об этом в чатике русскоязычного Keycloak комьюнити: https://t.me/keycloak_ru

Пару слов о курсе «Безопасность проекта: аутентификация в Keycloak»

Всех, кто хочет получить фундаментальные знания по работе с Keycloak, приглашаем на курс «Безопасность проекта: аутентификация в Keycloak». Вы узнаете, реализовать аутентификацию с минимальными усилиями и сосредоточиться на развитии продукта.

Вам не придётся самостоятельно искать информацию и тратить время на изобретение решений. Мы расскажем, где взять готовое и как его прикрутить.