🥇Keycloak di moda HA de li ser Kubernetes dimeşîne

TL; DR: dê ravekirina Keycloak, pergalek kontrolkirina gihîştina çavkaniya vekirî, analîzkirina avahiya hundurîn, hûrguliyên veavakirinê hebe.

Destpêk û ramanên sereke

Di vê gotarê de, em ê ramanên bingehîn bibînin ku meriv di hişê xwe de bigire dema ku komek Keycloak li ser Kubernetes bicîh dike.

Heke hûn dixwazin di derbarê Keycloak de bêtir zanibin, li lînkên li dawiya gotarê binihêrin. Ji bo ku hûn bêtir di pratîkê de bin, hûn dikarin bixwînin depoya me bi modulek ku ramanên sereke yên vê gotarê pêk tîne (rêbera destpêkirinê li wir e, ev gotar dê li ser cîhaz û mîhengan nêrînek giştî peyda bike, approx. wergêr).

Keycloak pergalek berfireh e ku bi Java-yê hatî nivîsandin û li ser serverek serîlêdanê hatî çêkirin Wildfly. Bi kurtasî, ew çarçoveyek destûrnameyê ye ku kapasîteyên federasyonê û SSO (nîşana yekane) dide bikarhênerên serîlêdanê.

Em we vedixwînin ku hûn fermî bixwînin malpera an Wikipedia ji bo têgihiştina berfireh.

Destpêkirina Keycloak

Keycloak ji bo xebitandinê du çavkaniyên daneya domdar hewce dike:

Databasek ku ji bo hilanîna daneyên sazkirî, wekî agahdariya bikarhêner tê bikar anîn
Datagrid cache, ku ji bo cachekirina daneyan ji databasê, û hem jî ji bo hilanîna hin metadaneyên demkurt û pir caran diguhere, wekî danişînên bikarhêneran tê bikar anîn. Pêk anîn Infinispan, ku bi gelemperî ji databasê pir zûtir e. Lê di her rewşê de, daneyên ku di Infinispan de têne hilanîn domdar e - û dema ku kom ji nû ve dest pê dike ne hewce ye ku li her deverê were hilanîn.

Keycloak di çar awayên cûda de dixebite:

adî - yek û yek pêvajoyek, ku bi pelê ve hatî mîheng kirin standalone.xml
Cluster Regular (vebijarka hebûna bilind) - pêdivî ye ku hemî pêvajo heman veavakirinê bikar bînin, ku divê bi destan were senkronîze kirin. Mîheng di pelê de têne hilanîn standalone-ha.xml, ji bilî vê yekê hûn hewce ne ku gihîştina hevpar a databasê û balansek barkirinê bikin.
Cluster domain - Di moda normal de destpêkirina komekê zû dibe karekî rûtîn û bêzar her ku kom mezin dibe, ji ber ku her carê ku veavakirin diguhezîne, divê hemî guhertin li ser her girêka komê bêne çêkirin. Moda xebitandinê ya domainê bi sazkirina hin cîhê hilanîna hevpar û weşandina veavakirinê vê pirsgirêkê çareser dike. Ev mîheng di pelê de têne tomar kirin domain.xml
Replication di navbera navendên daneyê - Heke hûn dixwazin Keycloak-ê di komek ji çend navendên daneyê de, bi gelemperî li deverên cihêreng ên erdnîgarî bimeşînin. Di vê vebijarkê de, her navendek daneyê dê komek xweya serverên Keycloak hebe.

Di vê gotarê de em ê bi hûrgulî vebijarka duyemîn, ango, binirxînin koma bi rêkûpêk, û em ê di heman demê de hinekî li ser mijara dubarekirina di navbera navendên daneyê de jî bisekinin, ji ber ku ev du vebijarkan di Kubernetes de bimeşînin. Xweşbextane, di Kubernetes de pirsgirêkek hevdengkirina mîhengên çend pods (girêkên Keycloak) tune ye, ji ber vê yekê koma domain Ew ê ne pir dijwar be.

Di heman demê de ji kerema xwe vê peyvê jî bîr bînin komkirin ji ber ku gotara mayî dê tenê li komek girêkên Keycloak bi hev re bixebite, ne hewce ye ku meriv li komek Kubernetes binihêre.

Cluster Keycloak Regular

Ji bo xebitandina Keycloak di vê modê de hûn hewce ne:

databasa hevpar a derveyî mîheng bike
balansa barkirinê saz bikin
xwedan torgilokek navxweyî ye ku bi piştgiriya multicast IP-yê re heye

Em ê li ser sazkirina databasek derveyî nîqaş nekin, ji ber ku ew ne armanca vê gotarê ye. Ka em bihesibînin ku li cîhek databasek xebatê heye - û me xalek pêwendiyê pê re heye. Em ê tenê vê daneyê li guhêrbarên jîngehê zêde bikin.

Ji bo ku hûn çêtir fam bikin ka Keycloak çawa di komikek têkçûn (HA) de dixebite, girîng e ku hûn zanibin ka ew çiqas bi kapasîteyên komkirinê yên Wildfly ve girêdayî ye.

Wildfly gelek binepergalan bikar tîne, hin ji wan wekî balansek barkirinê, hin ji bo tolerasyona xeletiyê têne bikar anîn. Balansa barkirinê hebûna serîlêdanê dema ku girêkek komê zêde tê barkirin peyda dike, û tolerasyona xeletiyê hebûna serîlêdanê misoger dike jî heke hin girêkên komê têk biçin. Hin ji van jêrpergalan:

mod_cluster: Bi Apache re wekî hevsengek barkirina HTTP-ê dixebite, bi TCP multicast ve girêdayî ye ku ji hêla xwerû ve mêvandar bibîne. Dikare bi balansek derve were guheztin.
infinispan: Cacheyek belavkirî ku kanalên JGroups wekî qatek veguhastinê bikar tîne. Wekî din, ew dikare protokola HotRod bikar bîne da ku bi komek Infinispan-a derveyî re têkilî dayne da ku naveroka cache hevdeng bike.
jgroups: Ji bo karûbarên pir berdest ên li ser kanalên JGroups-ê piştgirîya ragihandina komê peyda dike. Boriyên binavkirî dihêlin ku mînakên serîlêdanê yên di komekê de bi koman ve werin girêdan da ku pêwendiyek xwedan taybetmendiyên wekî pêbawerî, rêkûpêk, û hesasiya têkçûnê be.

Balansa barkirinê

Dema ku balansek wekî kontrolkerek ketinê di komek Kubernetes de saz dikin, girîng e ku hûn tiştên jêrîn li ber çavan bigirin:

Keycloak dihesibîne ku navnîşana dûr a xerîdar ku bi HTTP ve bi servera rastkirinê ve girêdide navnîşana IP-ya rastîn a komputera xerîdar e. Divê mîhengên balanser û têketinê sernavên HTTP rast destnîşan bikin X-Forwarded-For и X-Forwarded-Proto, û sernavê orîjînal jî hilînin HOST. Guhertoya herî dawî ingress-nginx (>0.22.0) vê ji hêla xwerû ve neçalak dike

Aktîvkirina ala proxy-address-forwarding bi danîna guhêrbarek jîngehê PROXY_ADDRESS_FORWARDING в true Keycloak fêm dike ku ew li pişt proxy-ê dixebite.

Hûn jî hewce ne ku çalak bikin danişînên asê di nav de. Keycloak cacheya Infinispan-ê ya belavkirî bikar tîne da ku daneyên ku bi danişîna pejirandina heyî û rûniştina bikarhêner ve girêdayî ye hilîne. Caches ji hêla xwerû ve bi xwedanek yekane re tevdigerin, bi gotinek din, ew danişîna taybetî li ser hin nodek di komê de tê hilanîn, û girêkên din ger hewcedariya wan bi gihîştina wê danişînê hebe divê ji dûr ve jê bipirsin.

Bi taybetî, berevajî belgekirinê, pêvekirina danişînek bi navê cookie ji me re nexebitî AUTH_SESSION_ID. Keycloak xwedan xelekek beralîkirî ye, ji ber vê yekê em pêşniyar dikin ku ji bo danişîna asê navek cookie-ya cûda hilbijêrin.

Keycloak di heman demê de navê girêka ku yekem bersiv daye jî girêdide AUTH_SESSION_ID, û ji ber ku her nodek di guhertoya pir berdest de heman databasê bikar tîne, her yek ji wan divê hebe ji bo birêvebirina danûstendinan nasnameyek girêk cihê û yekta. Tête pêşniyar kirin ku têxin hundur JAVA_OPTS Parametreyên jboss.node.name и jboss.tx.node.id ji bo her girêkek yekta - hûn dikarin, mînakî, navê podê bidin. Ger hûn navek pod danin, sînorê 23 karakteran ji bo guhêrbarên jboss ji bîr nekin, ji ber vê yekê çêtir e ku hûn ji Deploymentek StatefulSet bikar bînin.

Rake din - heke pod were jêbirin an ji nû ve were destpêkirin, cache wê winda dibe. Li gorî vê yekê, hêja ye ku jimara xwedan cache-ê ji bo hemî cache-ê bi kêmî ve du kes were danîn, da ku kopiyek cache bimîne. Çareserî rev e script ji bo Wildfly dema ku pod dest pê dike, wê di pelrêçê de bicîh bikin /opt/jboss/startup-scripts di konteynerê de:

Naveroka Skrîptê

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

paşê nirxa guhêrbar jîngehê danîn CACHE_OWNERS ji bo pêwîst.

Tora taybet a bi piştgiriya multicast IP

Ger hûn Weavenet wekî CNI bikar bînin, multicast dê tavilê bixebite - û girêkên weya Keycloak dê gava ku werin destpêkirin hevûdu bibînin.

Ger di koma xweya Kubernetes de piştgirîya ip-ya multicast tune be, hûn dikarin JGroups mîheng bikin ku bi protokolên din re bixebitin da ku girêkan bibînin.

Vebijêrk yekem e ku bikar bînin KUBE_DNSku bikar tîne headless service ji bo dîtina girêkên Keycloak, hûn bi tenê JGroups navê karûbarê ku dê ji bo dîtina girêkan were bikar anîn derbas bikin.

Vebijêrkek din jî karanîna rêbazê ye KUBE_PING, ya ku bi API-yê re dixebite ku li girêkan bigere (hûn hewce ne ku mîheng bikin serviceAccount bi mafan list и get, û dûv re pêlavan mîheng bikin ku bi vê re bixebitin serviceAccount).

Awayê ku JGroup girêkan dibîne bi danîna guhêrbarên jîngehê ve tê mîheng kirin JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. bo KUBE_PING hûn hewce ne ku bi pirsê pods hilbijêrin namespace и labels.

️ Ger hûn multicast bikar bînin û du an zêdetir komikên Keycloak di yek koma Kubernetes de bimeşînin (ka em bibêjin yek di navan de production, ya duyem - staging) - girêkên komeke Keycloak dikarin tevlî komeke din bibin. Bawer bikin ku ji bo her komê navnîşek pirzimanî ya yekta bi danîna guherbaran bikar bîninjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Replication di navbera navendên daneyê

Têkilî

Keycloak ji bo her navendek daneyê ku komên Keycloack ji girêkên Keycloak-ê pêk tên, gelek komikên cache yên Infinispan-ê yên cihêreng bikar tîne. Lê di navendên daneyên cihêreng de di navbera nodên Keycloak de cûdahî tune.

Nodên Keycloak ji bo danûstendina di navbera navendên daneyê de tora daneya Java ya derveyî (pêşkêşkerên Infinispan) bikar tînin. Ragihandin li gorî protokolê dixebite Infinispan HotRod.

Pêdivî ye ku keşeyên Infinispan bi taybetmendiyê bêne mîheng kirin remoteStore, da ku daneyên ji dûr ve bêne hilanîn (li navendek daneya din, approx. wergêr) caş. Di nav serverên JDG de komên infinispan ên cihêreng hene, da ku daneyên li ser JDG1 li ser malperê têne hilanîn. site1 dê li ser malperê li JDG2-ê were dubare kirin site2.

Û di dawiyê de, servera JDG ya wergir bi navgîniya girêdanên xerîdar, ku taybetmendiyek protokola HotRod-ê ye, serverên Keycloak ji koma xwe agahdar dike. Nodên Keycloak li ser site2 kaşên xwe yên Infinispan nûve bikin û danişîna bikarhêner a taybetî jî li ser girêkên Keycloak-ê peyda dibe site2.

Ji bo hin cache, di heman demê de gengaz e ku meriv paşve nekişîne û bi tevahî servera Infinispan ji nivîsandina daneyan dûr bixe. Ji bo vê yekê hûn hewce ne ku mîhengê jêbirin remote-store cacheya taybetî ya Infinispan (di pelê de standalone-ha.xml), piştî ku hin taybetî replicated-cache di heman demê de dê êdî li ser servera Infinispan ne hewce be.

Sazkirina caches

Di Keycloak de du celeb cache hene:

Herêmî. Ew li kêleka databasê ye û ji bo kêmkirina barkirina databasê, û hem jî ji bo kêmkirina derengiya bersivê kar dike. Ev celeb cache warê, xerîdar, rol, û metadata bikarhêner hilîne. Ev celeb cache nayê dubare kirin, tevî ku cache beşek ji komek Keycloak be. Ger têketinek di kaşê de biguhere, peyamek di derbarê guheztinê de ji serverên mayî yên di komê re tê şandin, piştî ku têketin ji cache tê derxistin. Binêre şirove work Ji bo ravekek berfirehtir a pêvajoyê li jêr binêrin.
Replicated. Danişînên bikarhêner, nîşaneyên negirêdayî pêvajoyê dike, û di heman demê de xeletiyên têketinê jî dişopîne da ku hewildanên phishing şîfreyê û êrişên din bibîne. Daneyên ku di van cache de têne hilanîn demkî ne, tenê di RAM-ê de têne hilanîn, lê dikare li seranserê komê were dubare kirin.

kaşên Infinispan

Danişîn - têgehek di Keycloak de, kaşeyên cuda yên jê re tê gotin authenticationSessions, ji bo hilanîna daneyên bikarhênerên taybetî têne bikar anîn. Daxwazên ji van cache bi gelemperî ji hêla gerok û serverên Keycloak ve hewce ne, ne ji hêla serîlêdanan ve. Li vir girêdayîbûna bi danişînên asê ve tê lîstin, û caşên weha bixwe ne hewce ne ku bêne dubare kirin, tewra di rewşa moda Çalak-Çalak de.

Action Tokens. Têgehek din, bi gelemperî ji bo senaryoyên cihêreng tê bikar anîn dema ku, mînakî, pêdivî ye ku bikarhêner bi e-nameyê tiştek asynchronous bike. Mînakî, di dema pêvajoyê de forget password cache actionTokens ji bo şopandina metadaneyên nîşaneyên têkildar têne bikar anîn - mînakî, nîşanek berê hatî bikar anîn û dîsa nayê çalak kirin. Ev celeb cache bi gelemperî pêdivî ye ku di navbera navendên daneyê de were dubare kirin.

Caching û pîrbûna daneyên hilanîn ji bo barkirina li ser databasê kar dike. Ev celeb caching performansê çêtir dike, lê pirsgirêkek eşkere zêde dike. Ger serverek Keycloak daneyan nûve bike, pêdivî ye ku serverên din werin agahdar kirin da ku ew daneyên di kaşên xwe de nûve bikin. Keycloak kaşên herêmî bikar tîne realms, users и authorization ji bo cachkirina daneyan ji databasê.

Di heman demê de cacheyek cuda jî heye work, ku li hemî navendên daneyê tê dubare kirin. Ew bixwe tu daneyan ji databasê hilnagire, lê ji bo şandina peyamên di derbarê pîrbûna daneyê de ji bo girêkên komê yên di navbera navendên daneyê de kar dike. Bi gotinek din, gava ku dane têne nûve kirin, girêka Keycloak peyamek ji girêkên din ên navenda daneya xwe re, û hem jî girêkên li navendên daneyên din re dişîne. Piştî wergirtina peyamek wusa, her nodek daneyên têkildar di kaşên xwe yên herêmî de paqij dike.

Danişînên bikarhêner. Caches bi navên sessions, clientSessions, offlineSessions и offlineClientSessions, bi gelemperî di navbera navendên daneyê de têne dubare kirin û ji bo hilanîna daneyên li ser danişînên bikarhêner ên ku çalak in dema ku bikarhêner di gerokê de çalak e têne hilanîn. Van cache bi serîlêdana pêvajoyên daxwazên HTTP-ê yên ji bikarhênerên dawîn re dixebitin, ji ber vê yekê ew bi danişînên asê ve girêdayî ne û divê di navbera navendên daneyê de bêne dubare kirin.

Parastina hêza hovane. Cache loginFailures Ji bo şopandina daneyên xeletiya têketinê tê bikar anîn, wek mînak çend caran bikarhênerek şîfreyek nerast nivîsandiye. Berpirsiyariya vê cacheyê berpirsiyar e. Lê ji bo hesabek rast, hêja ye ku dubarekirina di navbera navendên daneyê de çalak bike. Lê ji hêla din ve, heke hûn van daneyan dubare nekin, hûn ê performansê baştir bikin, û heke ev pirsgirêk derkeve, dibe ku dubare neyê çalak kirin.

Dema ku komek Infinispan radike, hûn hewce ne ku pênaseyên cache li pelê mîhengan zêde bikin:

<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" />

Berî destpêkirina koma Keycloak, divê hûn koma Infinispan mîheng bikin û dest pê bikin

Hingê hûn hewce ne ku mîheng bikin remoteStore ji bo kaşên Keycloak. Ji bo vê yekê, skrîptek bes e, ku bi heman rengî ya berê, ku ji bo danîna guhêrbar tê bikar anîn, tê kirin. CACHE_OWNERS, divê hûn wê li pelek tomar bikin û têxin pelrêçek /opt/jboss/startup-scripts:

Naveroka Skrîptê

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

Ji bîr nekin ku saz bikin JAVA_OPTS ji bo girêkên Keycloak ku HotRod dimeşînin: remote.cache.host, remote.cache.port û navê xizmetê jboss.site.name.

Girêdan û belgeyên zêde

Gotar ji aliyê xebatkaran ve ji bo Habrê hatiye wergerandin û amadekirin navenda perwerdeya Slurm - Kursên zexm, qursên vîdyoyê û perwerdehiya pargîdanî ji pisporên pispor (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Source: www.habr.com

Keycloak di moda HA-yê de li ser Kubernetes dimeşîne