🥇Kubernetesте HA режиминде Keycloak иштеп жатат

TL; DR: Keycloak сыпаттамасы, ачык булактуу кирүү мүмкүнчүлүгүн башкаруу системасы, ички түзүлүштүн анализи, конфигурациянын деталдары болот.

Киришүү жана негизги идеялар

Бул макалада биз Kubernetesтин үстүнө Keycloak кластерин жайгаштырууда эске алуу керек болгон негизги идеяларды көрөбүз.

Эгерде сиз Keycloak жөнүндө көбүрөөк билгиңиз келсе, макаланын аягындагы шилтемелерди караңыз. Практикага көбүрөөк чөмүлүү үчүн сиз окусаңыз болот биздин репозиторий Бул макаланын негизги идеяларын ишке ашыруучу модулу менен (ишке киргизүү колдонмосу бар, бул макалада түзмөк жана орнотуулар жөнүндө жалпы маалымат берилет, болжол менен котормочу).

Keycloak – бул Java тилинде жазылган жана колдонмо серверинин үстүнө курулган комплекстүү система Wildfly. Кыскача айтканда, бул колдонмо колдонуучулар федерациясына жана SSO (бир жолу кирүү) мүмкүнчүлүктөрүн берген авторизациянын негизи.

Сизди расмий окууга чакырабыз сайты же Wikipedia деталдуу түшүнүү үчүн.

Keycloak ишке киргизилүүдө

Keycloak иштетүү үчүн эки туруктуу маалымат булагын талап кылат:

Колдонуучунун маалыматы сыяктуу белгиленген маалыматтарды сактоо үчүн колдонулган маалымат базасы
Datagrid кэши, маалымат базасынан берилиштерди кэштөө үчүн, ошондой эле кээ бир кыска мөөнөттүү жана тез-тез өзгөрүп туруучу метаберилиштерди сактоо үчүн колдонулат, мисалы, колдонуучу сессиялары. Аткарылган Infinispan, бул адатта маалымат базасына караганда бир кыйла ылдамыраак. Бирок кандай болгон күндө да, Infinispanда сакталган маалыматтар эфемердик болуп саналат - жана кластер кайра иштетилгенде аны эч жерде сактоонун кереги жок.

Keycloak төрт түрдүү режимде иштейт:

демейдеги - файл аркылуу конфигурацияланган бир гана процесс standalone.xml
Кадимки кластер (жогорку жеткиликтүүлүк опциясы) - бардык процесстер кол менен синхрондоштурууга тийиш болгон бирдей конфигурацияны колдонушу керек. Орнотуулар файлда сакталат standalone-ha.xml, Мындан тышкары, сиз маалымат базасына жана жүк балансына жалпы мүмкүндүк алуу керек.
Домен кластери — кластерди кадимки режимде баштоо тез эле кадимки жана кызыксыз иш болуп калат, анткени кластер өскөн сайын конфигурация өзгөргөн сайын, бардык өзгөртүүлөр ар бир кластер түйүнүндө жасалышы керек. Домендин иштөө режими бул маселени жалпы сактагычтын ордун орнотуу жана конфигурацияны жарыялоо менен чечет. Бул орнотуулар файлда сакталат domain.xml
Маалымат борборлорунун ортосундагы репликация — эгер сиз Keycloakти бир нече маалымат борборлорунун кластеринде, көбүнчө ар кайсы географиялык жерлерде иштеткиңиз келсе. Бул параметрде ар бир маалымат борборунда Keycloak серверлеринин өзүнүн кластери болот.

Бул макалада биз майда-чүйдөсүнө чейин экинчи вариантын карап чыгабыз, башкача айтканда үзгүлтүксүз кластер, жана биз маалымат борборлорунун ортосундагы репликация темасына бир аз токтолобуз, анткени Kubernetesте бул эки вариантты иштетүү мааниси бар. Бактыга жараша, Kubernetesте бир нече поддондордун (Keycloak түйүндөрүнүн) жөндөөлөрүн синхрондоштурууда көйгөй жок. домен кластери Бул өтө кыйын болбойт.

Ошондой эле сөз экенине көңүл буруңуз кластердик макаланын калган бөлүгү чогуу иштеген Keycloak түйүндөрүнүн тобуна гана тиешелүү болот, Kubernetes кластерине кайрылуунун кереги жок.

Кадимки Keycloak кластери

Бул режимде Keycloak иштетүү үчүн сизге керек:

тышкы жалпы маалымат базасын конфигурациялоо
жүк балансын орнотуу
IP мультикаст колдоосу менен ички тармакка ээ

Тышкы маалымат базасын түзүү жөнүндө сөз кылбайбыз, анткени бул макаланын максаты эмес. Келгиле, бир жерде иштеп жаткан маалымат базасы бар деп ойлойлу - жана бизде ага байланыш чекити бар. Биз жөн гана бул маалыматтарды чөйрө өзгөрмөлөрүнө кошобуз.

Keycloak иштебей калуу (HA) кластеринде кантип иштээрин жакшыраак түшүнүү үчүн, анын баары Wildflyдин кластерлөө мүмкүнчүлүктөрүнөн канчалык көз каранды экенин билүү маанилүү.

Wildfly бир нече подсистемаларды колдонот, алардын айрымдары жүк балансы катары колдонулат, кээ бирлери каталарга чыдамдуулук үчүн. Кластер түйүнү ашыкча жүктөлгөндө жүк баланстоочу колдонмонун жеткиликтүүлүгүн камсыздайт, ал эми катага чыдамдуулук кээ бир кластер түйүндөрү иштебей калса дагы, колдонмонун жеткиликтүүлүгүн камсыздайт. Бул подсистемалардын айрымдары:

mod_cluster: Apache менен бирдикте HTTP жүк балансы катары иштейт, демейки боюнча хостторду табуу үчүн TCP мультикастка көз каранды. Тышкы баланстоочу менен алмаштырылышы мүмкүн.
infinispan: JGroups каналдарын транспорттук катмар катары колдонгон бөлүштүрүлгөн кэш. Кошумча, ал кэштин мазмунун синхрондоштуруу үчүн тышкы Infinispan кластери менен байланышуу үчүн HotRod протоколун колдоно алат.
jgroups: JGroups каналдарынын негизинде жогорку жеткиликтүү кызматтар үчүн топтук байланыш колдоо көрсөтөт. Аты аталган түтүктөр кластердеги тиркеме инстанцияларын топторго бириктирүүгө мүмкүндүк берет, андыктан байланыш ишенимдүүлүк, иреттүүлүк жана каталарга сезгичтик сыяктуу касиеттерге ээ.

Load Balancer

Баланстарды Kubernetes кластерине кириш контроллери катары орнотуп жатканда, төмөнкү нерселерди эске алуу маанилүү:

Keycloak HTTP аркылуу аутентификация серверине туташкан кардардын алыскы дареги кардар компьютеринин чыныгы IP дареги деп болжолдойт. Баланс түзүүчү жана кирүү жөндөөлөрү HTTP баштарын туура коюшу керек X-Forwarded-For и X-Forwarded-Proto, жана ошондой эле баштапкы аталышын сактаңыз HOST. Акыркы версия ingress-nginx (>0.22.0) муну демейки боюнча өчүрөт

Желекти активдештирүү proxy-address-forwarding чөйрө өзгөрмөсүн орнотуу менен PROXY_ADDRESS_FORWARDING в true Keycloak проксидин артында иштеп жатканын түшүнөт.

Сиз да иштетишиңиз керек жабышчаак сессиялар кириште. Keycloak учурдагы аутентификация сессиясы жана колдонуучу сеансы менен байланышкан маалыматтарды сактоо үчүн бөлүштүрүлгөн Infinispan кэшин колдонот. Кэштер демейки боюнча бир ээси менен иштейт, башкача айтканда, ошол сеанс кластердин кээ бир түйүндөрүндө сакталат жана башка түйүндөр ошол сессияга кирүү керек болсо, аны алыстан сурашы керек.

Тактап айтканда, документтерге карама-каршы, cookie аты менен сессияны тиркөө биз үчүн иштеген жок AUTH_SESSION_ID. Keycloak кайра багыттоо циклине ээ, андыктан жабышчаак сеанс үчүн башка куки атын тандоону сунуштайбыз.

Keycloak ошондой эле биринчи жооп берген түйүндүн атын кошот AUTH_SESSION_ID, жана жогорку жеткиликтүү версиядагы ар бир түйүн бирдей маалымат базасын колдонгондуктан, алардын ар бири болушу керек транзакцияларды башкаруу үчүн өзүнчө жана уникалдуу түйүн идентификатору. коюу сунушталат JAVA_OPTS параметрлер jboss.node.name и jboss.tx.node.id ар бир түйүн үчүн уникалдуу - сиз, мисалы, поддондун атын коё аласыз. Эгер сиз подкасттын атын койсоңуз, jboss өзгөрмөлөрү үчүн 23 символдук чекти унутпаңыз, андыктан Жайгаштыруу эмес, StatefulSet колдонуу жакшыраак.

Дагы бир тырмоо - эгер подкаст жок кылынса же кайра иштетилсе, анын кэши жоголот. Муну эске алуу менен, кэштин көчүрмөсү кала бериши үчүн, бардык кэштер үчүн кэш ээлеринин санын жок дегенде экиге коюу керек. Чечим - чуркап Wildfly үчүн сценарий подключени баштаганда, аны каталогго жайгаштырыңыз /opt/jboss/startup-scripts контейнерде:

Скрипттин мазмуну

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo * Setting CACHE_OWNERS to "${env.CACHE_OWNERS}" in all cache-containers

/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})

run-batch
stop-embedded-server

андан кийин чөйрө өзгөрмөнүн маанисин орнотуңуз CACHE_OWNERS талап кылынганга.

IP мультикаст колдоосу менен жеке тармак

Эгер сиз Weavenetти CNI катары колдонсоңуз, мультикаст дароо иштейт - жана Keycloak түйүндөрүңүз ишке киргизилгенден кийин бири-бирин көрүшөт.

Kubernetes кластериңизде IP мультикаст колдоосу жок болсо, сиз JGroups түйүндөрүн табуу үчүн башка протоколдор менен иштөө үчүн конфигурациялай аласыз.

Биринчи параметр колдонуу болуп саналат KUBE_DNSколдонот headless service Keycloak түйүндөрүн табуу үчүн, сиз жөн гана JGroups'ка түйүндөрдү табуу үчүн колдонула турган кызматтын атын тапшырасыз.

Дагы бир вариант - бул ыкманы колдонуу KUBE_PING, түйүндөрдү издөө үчүн API менен иштейт (сиз конфигурациялашыңыз керек serviceAccount укуктары менен list и get, анан муну менен иштөө үчүн подкектерди конфигурациялаңыз serviceAccount).

JGroups түйүндөрүн табуу жолу чөйрө өзгөрмөлөрүн орнотуу менен конфигурацияланат JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES... For KUBE_PING сиз суроо менен поддон тандоо керек namespace и labels.

️ Эгер сиз мультикастты колдонсоңуз жана бир Kubernetes кластеринде эки же андан көп Keycloak кластерин иштетсеңиз (ат мейкиндигинде бирөөсүн дейли) production, экинчи - staging) - бир Keycloak кластеринин түйүндөрү башка кластерге кошула алат. Өзгөрмөлөрдү коюу менен ар бир кластер үчүн уникалдуу мультикаст дарегин колдонууну унутпаңызjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Маалымат борборлорунун ортосундагы репликация

байланыш

Keycloak Keycloak түйүндөрүнөн турган Keycloack кластерлери жайгашкан ар бир маалымат борбору үчүн бир нече Infinispan кэш кластерлерин колдонот. Бирок ар кандай маалымат борборлорундагы Keycloak түйүндөрүнүн ортосунда эч кандай айырма жок.

Keycloak түйүндөрү маалымат борборлорунун ортосундагы байланыш үчүн тышкы Java Data Grid (Infinispan серверлери) колдонушат. Байланыш протокол боюнча иштейт Infinispan HotRod.

Infinispan кэштери атрибут менен конфигурацияланышы керек remoteStore, маалыматтар алыстан сакталышы үчүн (башка маалымат борборунда, болжол менен котормочу) кэштер. JDG серверлеринин арасында өзүнчө Infinispan кластерлери бар, андыктан JDG1де сакталган маалыматтар сайтта site1 сайтында JDG2ге көчүрүлөт site2.

Акырында, кабыл алуучу JDG сервери HotRod протоколунун өзгөчөлүгү болгон кардар байланыштары аркылуу өзүнүн кластери жөнүндө Keycloak серверлерине кабарлайт. Keycloak түйүндөрү күйүк site2 алардын Infinispan кэштерин жаңыртыңыз жана белгилүү бир колдонуучу сеансы Keycloak түйүндөрүндө да жеткиликтүү болот site2.

Кээ бир кэштер үчүн камдык көчүрмөлөрдү жасабоо жана маалыматтарды толугу менен Infinispan сервери аркылуу жазуудан качуу да мүмкүн. Бул үчүн сиз орнотууну алып салышыңыз керек remote-store белгилүү Infinispan кэши (файлда standalone-ha.xml), андан кийин кээ бир конкреттүү replicated-cache мындан ары Infinispan сервер тарабында керектелбейт.

Кэштерди орнотуу

Keycloakте кэштердин эки түрү бар:

Жергиликтүү. Ал маалымат базасынын жанында жайгашкан жана маалымат базасына жүктөөнү азайтуу үчүн, ошондой эле жооп күтүү убактысын азайтуу үчүн кызмат кылат. Кэштин бул түрү аймакты, кардарларды, ролдорду жана колдонуучунун метадайындарын сактайт. Кэштин бул түрү, кэш Keycloak кластеринин бир бөлүгү болсо да, кайталанбайт. Эгерде кэштеги жазуу өзгөрсө, өзгөртүү жөнүндө билдирүү кластердеги калган серверлерге жөнөтүлөт, андан кийин жазуу кэштен чыгарылат. Сүрөттөмөнү караңыз work Процедуранын кеңири сүрөттөмөсүн төмөндө караңыз.
Репликацияланган. Колдонуучунун сеанстарын, оффлайн белгилерин иштетет, ошондой эле сырсөз фишинг аракеттерин жана башка чабуулдарды аныктоо үчүн кирүү каталарын көзөмөлдөйт. Бул кэштерде сакталган маалыматтар убактылуу, оперативдүү эс тутумда гана сакталат, бирок кластер боюнча репликациялоого болот.

Infinispan кэштери

Сессиялар - Keycloak концепциясы, өзүнчө кэштер деп аталат authenticationSessions, белгилүү бир колдонуучулардын маалыматтарын сактоо үчүн колдонулат. Бул кэштерден сурамдар адатта колдонмолорго эмес, браузерге жана Keycloak серверлерине керек болот. Бул жерде жабышчаак сеанстарга көз карандылык пайда болот жана мындай кэштердин өздөрүн Активдүү-Актив режиминде да кайталоонун кереги жок.

Action Tokens. Башка концепция, адатта, ар кандай сценарийлер үчүн колдонулат, мисалы, колдонуучу почта аркылуу асинхрондук түрдө бир нерсе жасашы керек. Мисалы, процедура учурунда forget password кэш actionTokens байланышкан токендердин метаберилиштерин көзөмөлдөө үчүн колдонулат - мисалы, токен мурунтан эле колдонулган жана аны кайра иштетүү мүмкүн эмес. Кэштин бул түрү адатта маалымат борборлорунун ортосунда репликацияланышы керек.

Сакталган маалыматтарды кэштөө жана эскирүү маалымат базасына жүктү жеңилдетүү үчүн иштейт. Мындай кэш иштөөнү жакшыртат, бирок анык көйгөйдү кошот. Эгерде бир Keycloak сервери маалыматтарды жаңыртса, башка серверлер кэштериндеги маалыматтарды жаңыртуу үчүн эскертилиши керек. Keycloak жергиликтүү кэштерди колдонот realms, users и authorization маалымат базасынан маалыматтарды кэштөө үчүн.

Ошондой эле өзүнчө кэш бар work, ал бардык маалымат борборлорунда кайталанат. Ал өзү маалымат базасынан эч кандай маалыматты сактабайт, бирок маалымат борборлорунун ортосундагы кластердик түйүндөргө маалыматтардын эскириши жөнүндө билдирүүлөрдү жөнөтүү үчүн кызмат кылат. Башкача айтканда, маалыматтар жаңыртылгандан кийин, Keycloak түйүнү өзүнүн маалымат борборундагы башка түйүндөргө, ошондой эле башка маалымат борборлорундагы түйүндөргө билдирүү жөнөтөт. Мындай билдирүүнү алгандан кийин, ар бир түйүн өзүнүн жергиликтүү кэштериндеги тиешелүү маалыматтарды тазалайт.

Колдонуучу сессиялары. Аты бар кэштер sessions, clientSessions, offlineSessions и offlineClientSessions, адатта маалымат борборлорунун ортосунда репликацияланат жана колдонуучу браузерде активдүү болуп турганда активдүү болгон колдонуучу сеанстары жөнүндө маалыматтарды сактоо үчүн кызмат кылат. Бул кэштер акыркы колдонуучулардын HTTP сурамдарын иштетүүчү тиркеме менен иштейт, ошондуктан алар жабышчаак сеанстар менен байланышкан жана маалымат борборлорунун ортосунда репликацияланышы керек.

Катуу күч коргоо. Кэш loginFailures Колдонуучу канча жолу туура эмес сырсөз киргизгени сыяктуу кирүү катасынын маалыматтарына көз салуу үчүн колдонулат. Бул кэштин репликациясы администратордун жоопкерчилигинде. Бирок так эсептөө үчүн маалымат борборлорунун ортосунда репликацияны активдештирүү керек. Бирок, экинчи жагынан, эгерде сиз бул маалыматтарды кайталабасаңыз, анда сиз өндүрүмдүүлүктү жакшыртасыз жана бул маселе келип чыкса, репликация иштетилбей калышы мүмкүн.

Infinispan кластерин чыгарууда, орнотуулар файлына кэш аныктамаларын кошушуңуз керек:

<replicated-cache-configuration name="keycloak-sessions" mode="ASYNC" start="EAGER" batching="false">
</replicated-cache-configuration>

<replicated-cache name="work" configuration="keycloak-sessions" />
<replicated-cache name="sessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineSessions" configuration="keycloak-sessions" />
<replicated-cache name="actionTokens" configuration="keycloak-sessions" />
<replicated-cache name="loginFailures" configuration="keycloak-sessions" />
<replicated-cache name="clientSessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineClientSessions" configuration="keycloak-sessions" />

Keycloak кластерин баштоодон мурун Infinispan кластерин конфигурациялап, башташыңыз керек

Андан кийин сиз конфигурациялашыңыз керек remoteStore Keycloak кэштери үчүн. Бул үчүн, өзгөрмө орнотуу үчүн колдонулган мурункуга окшош жасалган сценарий жетиштүү. CACHE_OWNERS, сиз аны файлга сактап, каталогго салышыңыз керек /opt/jboss/startup-scripts:

Скрипттин мазмуну

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo *** Update infinispan subsystem ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Add remote socket binding to infinispan server **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})

echo ** Update replicated-cache work element **
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=work, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)

/subsystem=infinispan/cache-container=keycloak/replicated-cache=work:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache sessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=sessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache offlineSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache clientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=clientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache offlineClientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineClientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache loginFailures element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=loginFailures, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache actionTokens element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    cache=actionTokens, 
    remote-servers=["remote-cache"], 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache authenticationSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

echo *** Update undertow subsystem ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

run-batch
stop-embedded-server

орнотууну унутпаңыз JAVA_OPTS HotRodду иштетүү үчүн Keycloak түйүндөрү үчүн: remote.cache.host, remote.cache.port жана кызматтын аталышы jboss.site.name.

Шилтемелер жана кошумча документтер

Макаланы кызматкерлер которгон жана Хабрга даярдашкан Slurm окуу борбору — практикалык адистерден интенсивдүү курстар, видеокурстар жана корпоративдик тренингдер (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Source: www.habr.com

Kubernetes'те HA режиминде Keycloak иштеп жатат