Rhedeg Keycloak yn y modd HA ar Kubernetes

TL; DR: bydd disgrifiad o Keycloak, system rheoli mynediad ffynhonnell agored, dadansoddiad o'r ddyfais fewnol, manylion cyfluniad.

Cyflwyniad a phrif syniadau

Yn yr erthygl hon, byddwn yn gweld y prif syniadau i'w cofio wrth ddefnyddio clwstwr Cloak ar ben Kubernetes.

Os ydych chi eisiau gwybod mwy am Keycloak, cyfeiriwch at y dolenni ar ddiwedd yr erthygl. Er mwyn ymgolli'n ddyfnach yn ymarferol, gallwch astudio ein cadwrfa gyda modiwl sy'n gweithredu prif syniadau'r erthygl hon (mae'r canllaw lansio yno, yn yr erthygl hon bydd trosolwg o'r ddyfais a'r gosodiadau, tua. cyfieithydd).

Mae Keycloak yn system gymhleth sydd wedi'i hysgrifennu yn Java ac wedi'i hadeiladu ar ben gweinydd cymhwysiad. Pryf gwyllt. Yn fyr, mae'n fframwaith awdurdodi sy'n rhoi ffederasiwn i ddefnyddwyr cymwysiadau a gallu SSO (arwyddo sengl).

Rydym yn eich gwahodd i ddarllen y swyddog сайт neu Wicipedia am ddealltwriaeth fanwl.

Dechrau Keycloak

Mae angen dwy ffynhonnell ddata barhaus ar Keycloak i'w rhedeg:

• Cronfa ddata a ddefnyddir i storio data parhaus, megis gwybodaeth am ddefnyddwyr
• Celc datagrid, a ddefnyddir i storio data o'r gronfa ddata, yn ogystal â storio rhai metadata byrhoedlog a newidir yn aml, megis sesiynau defnyddwyr. Rhyddhawyd Infinispan, sydd fel arfer yn sylweddol gyflymach na'r gronfa ddata. Ond beth bynnag, mae'r data a arbedwyd yn Infinispan yn fyrhoedlog - ac nid oes angen ei arbed yn rhywle pan fydd y clwstwr yn cael ei ailgychwyn.

Mae cloak yn gweithio mewn pedwar dull gwahanol:

• Normal - un a dim ond un broses, wedi'i ffurfweddu trwy ffeil arunig.xml
• clwstwr rheolaidd (opsiwn sydd ar gael yn fawr) - Rhaid i bob proses ddefnyddio'r un ffurfweddiad, y mae'n rhaid ei gydamseru â llaw. Mae gosodiadau yn cael eu storio mewn ffeil arunig-ha.xml, yn ogystal, mae angen i chi wneud mynediad a rennir i'r gronfa ddata a balancer llwyth.
• Clwstwr parth - mae cychwyn y clwstwr yn y modd arferol yn dod yn dasg arferol a diflas yn gyflym wrth i'r clwstwr dyfu, oherwydd bob tro y bydd y cyfluniad yn cael ei newid, rhaid gwneud pob newid ar bob nod o'r clwstwr. Mae'r dull gweithredu parth yn datrys y mater hwn trwy sefydlu rhywfaint o storfa a rennir a chyhoeddi'r ffurfweddiad. Mae'r gosodiadau hyn yn cael eu storio mewn ffeil parth.xml
• Dyblygiad rhwng canolfannau data - rhag ofn eich bod am redeg Keycloak mewn clwstwr o sawl canolfan ddata, gan amlaf mewn gwahanol leoliadau daearyddol. Yn yr opsiwn hwn, bydd gan bob canolfan ddata ei chlwstwr ei hun o weinyddion Keycloak.

Yn yr erthygl hon, byddwn yn edrych yn agosach ar yr ail opsiwn, h.y. clwstwr rheolaidd, yn ogystal â chyffwrdd ychydig ar y pwnc o ddyblygu rhwng canolfannau data, gan ei bod yn gwneud synnwyr i redeg y ddau opsiwn hyn yn Kubernetes. Yn ffodus nid oes gan Kubernetes broblem gyda chysoni gosodiadau codennau lluosog (nodau Allweddell), felly clwstwr parth ni fydd yn rhy anodd ei wneud.

Sylwch hefyd fod y gair clwstwr hyd nes y bydd diwedd yr erthygl ond yn berthnasol i grŵp o nodau Cloak yn gweithio gyda'i gilydd, nid oes angen cyfeirio at glwstwr Kubernetes.

Clwstwr Cloak Bysellau Rheolaidd

I redeg Keycloak yn y modd hwn, mae angen:

• sefydlu cronfa ddata allanol a rennir
• gosod balancer llwyth
• cael rhwydwaith mewnol gyda chefnogaeth ip multicast

Ni fyddwn yn dadansoddi cyfluniad y gronfa ddata allanol, gan nad dyna yw pwrpas yr erthygl hon. Gadewch i ni dybio bod yna gronfa ddata weithredol yn rhywle - ac mae gennym ni bwynt cysylltu iddi. Yn syml, byddwn yn ychwanegu'r data hwn at y newidynnau amgylchedd.

Er mwyn deall yn well sut mae Keycloak yn gweithio mewn clwstwr failover (HA), mae'n bwysig gwybod faint mae'r cyfan yn dibynnu ar alluoedd clystyru Wildfly.

Mae Wildfly yn defnyddio sawl is-system, mae rhai ohonynt yn cael eu defnyddio fel cydbwysedd llwyth, mae rhai yn cael eu defnyddio ar gyfer methiant. Mae'r cydbwysedd llwyth yn sicrhau bod y cais ar gael pan fydd y nod clwstwr wedi'i orlwytho, ac mae methiant yn sicrhau bod y cymhwysiad ar gael hyd yn oed os bydd rhai o'r nodau clwstwr yn methu. Rhai o'r is-systemau hyn yw:

• mod_cluster: yn gweithio ar y cyd ag Apache fel balancer llwyth HTTP, yn dibynnu ar TCP multicast ar gyfer darganfod gwesteiwr diofyn. Gellir ei ddisodli gan balancer allanol.

• infinispan: storfa wedi'i ddosbarthu gan ddefnyddio sianeli JGroups fel haen trafnidiaeth. Yn ddewisol, gall ddefnyddio'r protocol HotRod i gyfathrebu â chlwstwr Infinispan allanol i gydamseru cynnwys y storfa.

• jgroups: Yn darparu cefnogaeth i gymdeithas grŵp ar gyfer gwasanaethau sydd ar gael yn fawr yn seiliedig ar sianeli JGroups. Mae pibellau a enwir yn caniatáu i achosion cais mewn clwstwr gael eu cysylltu'n grwpiau fel bod gan y cysylltiad briodweddau megis dibynadwyedd, trefnusrwydd a sensitifrwydd methiant.

cydbwysedd llwyth

Wrth osod cydbwysedd fel rheolydd mynediad mewn clwstwr Kubernetes, mae'n bwysig cadw'r pethau canlynol mewn cof:

Mae gwaith Keycloak yn awgrymu mai cyfeiriad anghysbell y cleient sy'n cysylltu trwy HTTP â'r gweinydd dilysu yw cyfeiriad IP go iawn cyfrifiadur y cleient. Dylai gosodiadau cydbwysedd a mynediad osod penawdau HTTP yn gywir X-Forwarded-For и X-Forwarded-Proto, a chadw'r teitl gwreiddiol HOST. Fersiwn diweddaraf ingress-nginx (> 0.22.0) yn ei analluogi yn ddiofyn

Actio baner proxy-address-forwarding trwy osod newidyn amgylchedd PROXY_ADDRESS_FORWARDING в true yn rhoi'r ddealltwriaeth i Keycloak ei fod yn rhedeg y tu ôl i ddirprwy.

Mae angen i chi hefyd alluogi sesiynau gludiog yn dod i mewn. Mae Keycloak yn defnyddio storfa ddosbarthedig Infinispan i storio data sy'n gysylltiedig â'r sesiwn ddilysu gyfredol a sesiwn y defnyddiwr. Mae caches yn berchennog sengl yn ddiofyn, mewn geiriau eraill mae'r sesiwn benodol honno'n cael ei storio ar ryw nod clwstwr a rhaid i nodau eraill ofyn amdano o bell os oes angen mynediad i'r sesiwn honno arnynt.

Yn benodol, yn groes i'r ddogfennaeth, nid oedd atodi sesiwn gyda'r cwci enw yn gweithio i ni AUTH_SESSION_ID. Mae Keycloak wedi dolennu'r ailgyfeiriad, felly rydym yn argymell dewis enw cwci gwahanol ar gyfer y sesiwn gludiog.

Mae cloak hefyd yn atodi enw'r gwesteiwr a atebodd gyntaf AUTH_SESSION_ID, a chan fod pob nod yn y fersiwn sydd ar gael yn fawr yn defnyddio'r un gronfa ddata, pob un ohonynt rhaid cael ID nod unigryw ac ar wahân ar gyfer rheoli trafodion. Argymhellir rhoi i mewn JAVA_OPTS paramedrau jboss.node.name и jboss.tx.node.id unigryw ar gyfer pob nod - er enghraifft, gallwch chi osod enw'r pod. Os rhowch enw'r pod - peidiwch ag anghofio am y terfyn o 23 nod ar gyfer newidynnau jboss, felly mae'n well defnyddio StatefulSet, nid Deployment.

Un rhaca arall - os caiff pod ei ddileu neu ei ailgychwyn, caiff ei storfa ei golli. Gyda hyn mewn golwg, mae'n werth gosod nifer y perchnogion caches ar gyfer pob caches i o leiaf ddau, felly bydd copi o'r storfa. Yr ateb yw rhedeg sgript ar gyfer Wildfly wrth gychwyn y pod, ei osod yn y cyfeiriadur /opt/jboss/startup-scripts mewn cynhwysydd:

Cynnwys y sgript

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

yna gosodwch werth newidyn yr amgylchedd CACHE_OWNERS i'r gofyn.

Rhwydwaith preifat gyda chefnogaeth ip multicast

Os ydych chi'n defnyddio Weavenet fel eich CNI, bydd aml-ddarllediad yn gweithio ar unwaith - a bydd eich nodau Cloak yn gweld ei gilydd cyn gynted ag y byddant ar waith.

Os nad oes gennych gefnogaeth ip multicast yn eich clwstwr Kubernetes, gallwch ffurfweddu JGroups i weithio gyda phrotocolau eraill i ddod o hyd i nodau.

Yr opsiwn cyntaf yw ei ddefnyddio KUBE_DNSsy'n defnyddio headless service i ddod o hyd i nodau Keycloak, rydych chi'n pasio enw'r gwasanaeth a ddefnyddir i ddod o hyd i'r nodau i JGroups.

Opsiwn arall yw defnyddio'r dull KUBE_PING, sy'n gweithio gyda'r API ar gyfer dod o hyd i nodau (mae angen i chi ffurfweddu serviceAccount gyda hawliau list и get, ac yna ffurfweddu'r codennau i weithio gyda hyn serviceAccount).

Mae sut mae nodau'n cael eu chwilio ar gyfer JGroups yn cael ei ffurfweddu trwy osod newidynnau amgylchedd JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. I KUBE_PING mae angen dewis codennau trwy ofyn namespace и labels.

️ Os ydych yn defnyddio multicast ac yn rhedeg dau neu fwy o glwstwr Cloak yn yr un clwstwr Kubernetes (gadewch i ni ddweud un yn y gofod enw production, yr ail - staging) - gall nodau o un clwstwr Cloak ymuno â chlwstwr arall. Gwnewch yn siŵr eich bod chi'n defnyddio cyfeiriad aml-ddarlledu unigryw ar gyfer pob clwstwr trwy osod newidynnaujboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Dyblygiad rhwng canolfannau data

Связь

Mae Keycloak yn defnyddio Clystyrau Cache Infinispan lluosog ar wahân ar gyfer pob canolfan ddata sy'n cynnal clystyrau Keycloack sy'n cynnwys nodau Keycloak. Ond ar yr un pryd, nid oes gwahaniaeth rhwng nodau Keycloak mewn gwahanol ganolfannau data.

Mae nodau cloak yn defnyddio Grid Data Java allanol (gweinyddion Infinispan) i gyfathrebu rhwng canolfannau data. Mae cyfathrebu yn gweithio yn unol â'r protocol HotRod Infinispan.

Rhaid ffurfweddu caches Infinispan gyda'r priodoledd remoteStore, fel y gellir storio'r data o bell (mewn canolfan ddata arall, tua. cyfieithydd) caches. Mae yna glystyrau infinispan ar wahân ymhlith y gweinyddwyr JDG, felly mae data'n cael ei storio ar JDG1 ar y safle site1 yn cael ei ailadrodd i JDG2 ar y safle site2.

Yn olaf, mae'r gweinydd JDG sy'n derbyn yn hysbysu gweinyddwyr Keycloak ei glwstwr trwy gysylltiadau cleient, sy'n nodwedd o brotocol HotRod. Nodau cloak ar site2 diweddaru eu caches Infinispan a bydd y sesiwn defnyddiwr penodol ar gael ar y nodau Keycloak ymlaen site2.

Mae hefyd yn bosibl i rai caches beidio â chael eu gwneud copi wrth gefn ac i wrthod yn llwyr i ysgrifennu data drwy'r gweinydd Infinispan. I wneud hyn, mae angen i chi gael gwared ar y gosodiad remote-store storfa Infinispan penodol (mewn ffeil arunig-ha.xml), wedi hyny rhai neillduol replicated-cache hefyd ni fydd ei angen mwyach ar ochr y gweinydd Infinispan.

Sefydlu caches

Mae dau fath o caches yn Keycloak:

• Lleol. Mae wedi'i leoli wrth ymyl y gronfa ddata, mae'n lleihau'r llwyth ar y gronfa ddata, yn ogystal â lleihau hwyrni ymateb. Mae'r math hwn o storfa yn storio'r deyrnas, cleientiaid, rolau a metadata defnyddwyr. Nid yw'r math hwn o storfa yn cael ei ailadrodd, hyd yn oed os yw'r storfa hon yn rhan o glwstwr Keycloak. Os bydd rhywfaint o gofnod yn y storfa yn newid, anfonir neges newid at weddill y gweinyddwyr yn y clwstwr, ac ar ôl hynny caiff y cofnod ei eithrio o'r storfa. gweler y disgrifiad work isod am ddisgrifiad manylach o'r weithdrefn.

• Dyblygadwy. Yn prosesu sesiynau defnyddwyr, tocynnau all-lein, ac yn monitro methiannau mewngofnodi i ganfod ymdrechion gwe-rwydo cyfrinair ac ymosodiadau eraill. Mae'r data sy'n cael ei storio yn y caches hyn dros dro, wedi'i storio mewn RAM yn unig, ond gellir ei ailadrodd ar draws y clwstwr.

Caches Infinispan

Sesiynau - cysyniad yn Keycloak, caches ar wahân, sy'n cael eu galw authenticationSessions, yn cael eu defnyddio i storio data defnyddwyr penodol. Fel arfer mae angen ceisiadau o'r caches hyn gan y porwr a gweinyddwyr Keycloak, nid cymwysiadau. Dyma lle mae'r ddibyniaeth ar sesiynau gludiog yn amlygu ei hun, ac nid oes angen ailadrodd caches o'r fath eu hunain, hyd yn oed yn achos modd Active-Active.

Tocynnau gweithredu. Cysyniad arall, a ddefnyddir fel arfer ar gyfer gwahanol senarios, pan, er enghraifft, mae angen i'r defnyddiwr wneud rhywbeth yn asyncronig trwy'r post. Er enghraifft, yn ystod y weithdrefn forget password storfa actionTokens a ddefnyddir i olrhain metadata tocynnau cysylltiedig - er enghraifft, mae'r tocyn eisoes wedi'i ddefnyddio ac ni ellir ei ail-greu. Yn nodweddiadol, dylai'r math hwn o storfa gael ei ailadrodd rhwng canolfannau data.

Caching a dod i ben data storio yn gweithio i dynnu'r llwyth oddi ar y gronfa ddata. Mae'r caching hwn yn gwella perfformiad ond yn ychwanegu problem amlwg. Os yw un gweinydd Keycloak yn diweddaru'r data, rhaid hysbysu gweddill y gweinyddwyr fel y gallant ddiweddaru eu caches. Mae cloak yn defnyddio caches lleol realms, users и authorization ar gyfer cadw data o'r gronfa ddata.

Mae yna storfa ar wahân hefyd work, sy'n cael ei ailadrodd ar draws yr holl ganolfannau data. Nid yw ei hun yn storio unrhyw ddata o'r gronfa ddata, ond mae'n gwasanaethu i anfon negeseuon heneiddio data i nodau clwstwr rhwng canolfannau data. Mewn geiriau eraill, cyn gynted ag y caiff y data ei ddiweddaru, mae nod Keycloak yn anfon neges i nodau eraill yn ei ganolfan ddata, yn ogystal â nodau mewn canolfannau data eraill. Ar ôl derbyn neges o'r fath, mae pob nod yn glanhau'r data cyfatebol yn ei storfa leol.

Sesiynau defnyddwyr. Caches ag enwau sessions, clientSessions, offlineSessions и offlineClientSessions, fel arfer yn cael eu hailadrodd rhwng canolfannau data ac yn gwasanaethu i storio data am sesiynau defnyddwyr sy'n weithredol tra bod y defnyddiwr yn weithredol yn y porwr. Mae'r caches hyn yn gweithio gyda'r rhaglen sy'n delio â cheisiadau HTTP gan ddefnyddwyr terfynol, felly maent yn gysylltiedig â sesiynau gludiog a rhaid eu hailadrodd rhwng datacenters.

amddiffyn grym ysgrublaidd. Cache loginFailures a ddefnyddir i olrhain data gwall mewngofnodi, megis y nifer o weithiau y gwnaeth defnyddiwr roi cyfrinair anghywir. Mater i'r gweinyddwr yw dyblygu'r storfa hon. Ond ar gyfer cyfrifiad cywir, mae'n werth actifadu dyblygu rhwng canolfannau data. Ond ar y llaw arall, os na fyddwch chi'n ailadrodd y data hwn, byddwch chi'n gallu gwella perfformiad, ac os bydd y cwestiwn hwn yn codi, efallai na fydd ailadrodd yn cael ei actifadu.

Wrth gyflwyno clwstwr Infinispan, mae angen i chi ychwanegu diffiniadau storfa i'r ffeil gosodiadau:

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

Rhaid i chi ffurfweddu a chychwyn y clwstwr Infinispan cyn rhedeg y clwstwr Keycloak

Yna mae angen i chi sefydlu remoteStore ar gyfer caches Keycloak. Ar gyfer hyn, mae sgript yn ddigon, a wneir yn debyg i'r un flaenorol, a ddefnyddir i osod y newidyn CACHE_OWNERS, mae angen i chi ei gadw i ffeil a'i roi mewn cyfeiriadur /opt/jboss/startup-scripts:

Cynnwys y sgript

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

Peidiwch ag anghofio gosod JAVA_OPTS ar gyfer nodau cloak i weithio HotRod: remote.cache.host, remote.cache.port ac enw'r gwasanaeth jboss.site.name.

Dolenni a dogfennaeth ychwanegol

• https://www.keycloak.org/docs/latest/server_installation/index.html
• https://docs.wildfly.org/17/High_Availability_Guide.html#cluster-configuration
• https://infinispan.org/docs/9.4.x/user_guide/user_guide.html
• https://hub.docker.com/r/jboss/keycloak
• https://hub.docker.com/r/jboss/infinispan

Cafodd yr erthygl ei chyfieithu a'i pharatoi ar gyfer Habr gan weithwyr Canolfan hyfforddi slyrm — cyrsiau dwys, fideo a hyfforddiant corfforaethol gan ymarferwyr (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Ffynhonnell: hab.com