ProHoster >> Blog >> Administrimi >> Të fillojmë Keycloak në modalitetin HA në Kubernetes

Të fillojmë Keycloak në modalitetin HA në Kubernetes

Të fillojmë Keycloak në modalitetin HA në Kubernetes

TL;DR: do të përshkruhet Keycloak, një sistem kontrolli qasjeje me kod të hapur, analizë të strukturës së brendshme, detaje rreth konfigurimit.

Hyrje dhe ide kryesore

Në këtë artikull do të shohim idetë kryesore që duhet të mbani mend gjatë vendosjes së një klasteri Keycloak mbi Kubernetes.

NĂ«se dĂ«shironi tĂ« dini mĂ« shumĂ« rreth Keycloak — konsultohuni me lidhjet nĂ« fund tĂ« artikullit. PĂ«r tĂ« thelluar praktikat — mund tĂ« shqyrtoni repozitore tonĂ« me modul qĂ« implementon idetĂ« kryesore tĂ« kĂ«tij artikulli (udhĂ«zimi pĂ«r fillim atje po ashtu, nĂ« kĂ«tĂ« artikull do tĂ« jetĂ« njĂ« pĂ«rmbledhje e strukturĂ«s dhe konfigurimeve, shĂ«nim i pĂ«rkthyesit).

Keycloak është një sistem kompleks, i shkruar në Java dhe ndërtuar mbi serverin e aplikacioneve Wildfly. Nëse do ta përmbledhim, është një framework për autorizim, duke ofruar përdoruesve të aplikacioneve federim dhe mundësinë e SSO (single sign-on).

Ju ftojmë të lexoni faqen zyrtare sitin ose Wikipedia për një kuptim të detajuar.

Startimi i Keycloak

Për Keycloak nevojiten dy burime të dhënash që ruhen përhershëm për të filluar:

  • NjĂ« bazĂ« tĂ« dhĂ«nash, e cila pĂ«rdoret pĂ«r ruajtjen e tĂ« dhĂ«nave tĂ« konsoliduara, si informacioni mbi pĂ«rdoruesit
  • Cache-i i datagrid, i cili pĂ«rdoret pĂ«r ruajtjen e tĂ« dhĂ«nave nga baza, si dhe pĂ«r mbajtjen e disa metadatave tĂ« shkurtra dhe shpesh tĂ« ndryshueshme, siç janĂ« seancat e pĂ«rdoruesve. ShpĂ«rndahet Infinispan, i cili zakonisht Ă«shtĂ« shumĂ« mĂ« i shpejtĂ« se baza e tĂ« dhĂ«nave. Por nĂ« çdo rast, tĂ« dhĂ«nat e ruajtura nĂ« Infinispan janĂ« efemere — dhe nuk duhet tĂ« ruhet askund gjatĂ« rindizjes sĂ« klasterit.

Keycloak punon në katër mënyra të ndryshme:

  • Normale — vetĂ«m njĂ« proces, konfigurimi i tĂ« cilit bĂ«het pĂ«rmes skedarit standalone.xml
  • Kluster normal (varianti me disponueshmĂ«ri tĂ« lartĂ«) — tĂ« gjithĂ« proceset duhet tĂ« pĂ«rdorin tĂ« njĂ«jtĂ«n konfigurim, e cila duhet tĂ« sinkronizohet manualisht. CilĂ«simet ruhen nĂ« skedarin standalone-ha.xml, pĂ«rveç kĂ«saj duhet tĂ« bĂ«het njĂ« akses i pĂ«rbashkĂ«t nĂ« bazĂ«n e tĂ« dhĂ«nave dhe njĂ« balancues ngarkese.
  • Klusteri i domenit — aktivizimi i njĂ« klasteri nĂ« mĂ«nyrĂ« tĂ« zakonshme shpejt bĂ«het njĂ« detyrĂ« rutinĂ« dhe e mĂ«rzitshme me rritjen e klasterit, pasi çdo herĂ« kur konfigurimi ndryshon, duhen bĂ«rĂ« ndryshimet nĂ« secilĂ«n nyje tĂ« klasterit. Modin e punĂ«s domain zgjidh kĂ«tĂ« çështje duke konfiguruar njĂ« hapĂ«sirĂ« tĂ« pĂ«rbashkĂ«t pĂ«r ruajtje dhe publikim tĂ« konfigurimeve. KĂ«to konfigurime mbahen nĂ« skedarin domain.xml
  • Replikimi ndĂ«rmjet qendrave tĂ« tĂ« dhĂ«nave — nĂ« rast se dĂ«shironi tĂ« aktivizoni Keycloak nĂ« njĂ« klaster nga disa qendra tĂ« tĂ« dhĂ«nave, shpesh herĂ« nĂ« vende gjeografikisht tĂ« ndryshme. NĂ« kĂ«tĂ« rast, çdo qendĂ«r tĂ« dhĂ«nash do tĂ« ketĂ« klasterin e vet tĂ« serverĂ«ve Keycloak.

Në këtë artikull ne do të shqyrtojmë në detaje variantin e dytë, domethënë klasterin e zakonshëm, si dhe do të prekim pak temën e replikimit ndërmjet qendrave të të dhënave, pasi këto dy variante ka kuptim të aktivizohen në Kubernetes. Për fat të mirë, në Kubernetes nuk ekziston problemi i sinkronizimit të konfigurimeve të disa podëve (nyjeve Keycloak), kështu që klasteri domain nuk do të jetë shumë e vështirë të bëhet.

Gjithashtu, ju lutem vini re se fjala klaster Në vazhdim, artikulli do të fokusohet ekskluzivisht në grupin e nyjeve Keycloak që punojnë së bashku; nuk ka nevojë për të referuar në klustërin Kubernetes.

Klastër standard i Keycloak

Për të nisur Keycloak në këtë mod, duhen:

  • tĂ« konfigurohet njĂ« bazĂ« tĂ« dhĂ«nash e jashtme e pĂ«rbashkĂ«t
  • tĂ« instalohet njĂ« balancues ngarkese
  • tĂ« ketĂ« njĂ« rrjet tĂ« brendshĂ«m qĂ« mbĂ«shtet ip multicast

Nuk do tĂ« shqyrtojmĂ« konfigurimin e bazĂ«s sĂ« jashtme, pasi nuk Ă«shtĂ« qĂ«llimi i kĂ«tij artikulli. Le tĂ« supozojmĂ« se ka njĂ« bazĂ« tĂ« dhĂ«nash funksionale ndonjĂ«herĂ« — dhe ne kemi njĂ« pikĂ« lidhjeje. Thjesht do t’i shtojmĂ« kĂ«to tĂ« dhĂ«na nĂ« variablat e ambientit.

Për një kuptim më të mirë të mënyrës se si funksionon Keycloak në një klaster me disponueshmëri të lartë (HA), është e rëndësishme të dihet se sa shumë kjo varet nga aftësitë e Wildfly për klasterizim.

Wildfly përdor disa nën-sisteme, disa prej të cilave përdoren si balancues ngarkese, disa për disponueshmëri të lartë. Balancuesi i ngarkesës siguron aksesin në aplikacion gjatë ngarkesës mbi nyjën e klasterit, ndërsa disponueshmëria e lartë garanton aksesin në aplikacion edhe në rast të dështimit të disa nyjeve të klasterit. Disa nga këto nën-sisteme:

  • mod_cluster: punon sĂ« bashku me Apache si njĂ« balancues HTTP, i varur nga TCP multicast pĂ«r tĂ« gjetur nyjat nĂ« mĂ«nyrĂ« tĂ« parazgjedhur. Mund tĂ« zĂ«vendĂ«sohet me njĂ« balancues tĂ« jashtĂ«m.

  • infinispan: njĂ« cache i shpĂ«rndarĂ« qĂ« pĂ«rdor kanale JGroups si nivelin e transportit. ShtesĂ«, mund tĂ« zbatojĂ« protokollin HotRod pĂ«r tĂ« komunikuar me njĂ« klaster tĂ« jashtĂ«m Infinispan pĂ«r tĂ« sinkronizuar pĂ«rmbajtjen e cache-it.

  • jgroups: ofron mbĂ«shtetje pĂ«r komunikimin nĂ« grupe pĂ«r shĂ«rbime me DisponueshmĂ«ri tĂ« LartĂ« qĂ« bazohen nĂ« kanalet JGroups. Kanalet me emĂ«r lejojnĂ« qĂ« instancat e aplikacioneve nĂ« klaster tĂ« lidhen nĂ« grupe, duke siguruar qĂ« komunikimi tĂ« ketĂ« prona si besueshmĂ«ria, renditja, dhe ndjeshmĂ«ria ndaj dĂ«shtimeve.

Balancuesi i ngarkesës

Kur konfiguroni një balancues si një kontrollues ingress në klasterin Kubernetes, është e rëndësishme të mbani parasysh këto gjëra:

Funksionimi i Keycloak nënkupton se adresa e largët e klientit të lidhur përmes HTTP në serverin e autentifikimit është adresa reale IP e kompjuterit të klientit. Konfigurimet e balancuesit dhe ingress duhet të vendosin saktësisht kokat HTTP X-Forwarded-For dhe X-Forwarded-Proto, si dhe të ruajnë kokën origjinale HOST. Versioni më i fundit ingress-nginx (> 0.22.0) e deaktivon këtë si parazgjedhje

Aktivizimi i flamurit proxy-address-forwarding duke vendosur një variable ambienti PROXY_ADDRESS_FORWARDING në e vërtetë i jep Keycloak kuptimin që po punon pas një proxy.

Duhet gjithashtu të aktivizohet seancat ngjitëse në ingress. Keycloak përdor një cache të shpërndarë Infinispan për të ruajtur të dhënat e lidhura me seancën aktuale të autentifikimit dhe seancën e përdoruesit. Cache-t punojnë me një pronar të vetëm si parazgjedhje, në fjalë tjetër, kjo seancë specifike ruhet në një nod të klasterit, ndërsa nodet e tjera duhet ta kërkojnë atë në distancë, nëse u nevojitet qasja në këtë seancë.

Konkretisht, për ne, përkundër dokumentacionit, nuk funksionoi ngjitja e seancës me emrin e cookie AUTH_SESSION_ID. Keycloak përsëriti ridrejtimin, ndaj ne rekomandojmë të zgjidhni një emër tjetër cookie për seancën ngjitëse.

Gjithashtu, Keycloak lidh emrin e nodit qĂ« pĂ«rgjigjet i pari me AUTH_SESSION_ID, dhe pasi çdo nod nĂ« variantin me disponueshmĂ«ri tĂ« lartĂ« pĂ«rdor tĂ« njĂ«jtĂ«n bazĂ« tĂ« dhĂ«nash, secili prej tyre duhet tĂ« ketĂ« njĂ« identifikues tĂ« veçantĂ« dhe unik tĂ« nodit pĂ«r menaxhimin e transaksioneve. Rekomandohet tĂ« vendosni nĂ« JAVA_OPTS parametrat jboss.node.name dhe jboss.tx.node.id unike pĂ«r çdo nod — mund tĂ« vendosni emrin e pod-it. NĂ«se do tĂ« vendosni emrin e pod-it — mos harroni kufizimin prej 23 karakteresh pĂ«r variablat jboss, kĂ«shtu qĂ« Ă«shtĂ« mĂ« mirĂ« tĂ« pĂ«rdorni StatefulSet, jo Deployment.

NjĂ« tjetĂ«r problem — nĂ«se pod-i fshihet ose ri-startohet, cached-i i tij humbet. Me kĂ«tĂ« nĂ« mendje, Ă«shtĂ« e nevojshme tĂ« vendosni numrin e pronarĂ«ve tĂ« cache-it pĂ«r tĂ« gjithĂ« cached-at tĂ« paktĂ«n nĂ« dy, kĂ«shtu do tĂ« mbetet njĂ« kopje e cache-it. Zgjidhja — ekzekutoni skriptin pĂ«r Wildfly gjatĂ« lançimit tĂ« pod-it, duke e vendosur nĂ« katalogun /opt/jboss/startup-scripts nĂ« konteiner:

PĂ«rmbajtja e skriptit

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

echo * Duke CACHE_OWNERS në "${env.CACHE_OWNERS}" në të gjitha cache-conteiners

/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

pas të cilit vendosni vlerën e variablës së ambientit CACHE_OWNERS në nevojshmëri.

Rrjeti privat me mbështetje për ip multicast

NĂ«se po pĂ«rdorni Weavenet si CNI, multicast do tĂ« funksionojĂ« menjĂ«herĂ« — dhe nodet tuaja Keycloak do tĂ« shohin njĂ«ri-tjetrin sapo tĂ« jenĂ« aktivizuar.

Nëse nuk keni mbështetje për ip multicast në klasterin Kubernetes, mund të konfiguroni JGroups për të punuar me protokolle të tjera për të gjetur nodet.

Opsioni i parë është përdorimi i KUBE_DNS, i cili përdor shërbim pa krye për të gjetur nyjet Keycloak, ju thjesht i jepni JGroups emrin e shërbimit që do të përdoret për të gjetur nyjet.

Një opsion tjetër është aplikimi i metodës KUBE_PING, e cila funksionon me API për të gjetur nyjet (duhet të konfigurohet serviceAccount me të drejta listë dhe merr, pas së cilës do të konfiguroni pod-et për të punuar me këtë serviceAccount).

Mënyra e gjetjes së nyjeve për JGroups konfigurohet duke vendosur variablat e ambientit JGROUPS_DISCOVERY_PROTOCOL dhe JGROUPS_DISCOVERY_PROPERTIES. Për KUBE_PING duhet të zgjidhni pod-et duke caktuar namespace dhe etiketat.

 NĂ«se pĂ«rdorni multicast dhe nisni dy ose mĂ« shumĂ« klasterĂ« Keycloak nĂ« njĂ« klaster Kubernetes (supozoni njĂ« nĂ« namespace production, tjetri — staging) — nyjet e njĂ« klasteri Keycloak mund tĂ« bashkohen me njĂ« klaster tjetĂ«r. Sigurohuni qĂ« tĂ« pĂ«rdorni njĂ« adresĂ« unike multicast pĂ«r çdo klaster duke vendosur variablatjboss.default.multicast.address dhe jboss.modcluster.multicast.address nĂ« JAVA_OPTS.

Replikimi ndërmjet qendrave të të dhënave

Të fillojmë Keycloak në modalitetin HA në Kubernetes

Lidhja

Keycloak përdor klastera të shumtë të veçanta të caches Infinispan për çdo qendër date ku ndodhen klasterët Keycloak, të përbërë nga nyje Keycloak. Por nuk ka asnjë ndryshim mes nyjeve Keycloak në qendra të ndryshme date.

Nodet Keycloak përdorin një Java Data Grid të jashtme (serverë Infinispan) për lidhjen ndërmjet qendrave të të dhënave. Lidhja funksionon sipas protokollit Infinispan HotRod.

Keçat Infinispan duhet të konfigurohen me atributin remoteStore, në mënyrë që të dhënat të mund të ruhen në keçat e largët (në një qendër tjetër të të dhënave, shënim i përkthyesit) Keçat janë grupe të veçanta infinispan midis serverave JDG, kështu që të dhënat, që ruhen në JDG1 në vendin site1 do të replikohen në JDG2 në vendin site2.

Dhe përfundimisht, serveri përfshirës JDG e njofton serverat Keycloak të grupit të tij përmes lidhjeve klient, që është një veçori e protokollit HotRod. Nodet Keycloak në site2 përditësojnë keçat e tyre Infinispan, dhe sesioni specifik i përdoruesit bëhet gjithashtu i disponueshëm në nodet Keycloak në site2.

Për disa keça gjithashtu është e mundur të mos bëhen kopje rezervë dhe të hiqet plotësisht regjistrimi i të dhënave nëpërmjet serverit Infinispan. Për këtë, duhet të hiqet konfigurimi remote-store në keshin specifik Infinispan (në skedarin standalone-ha.xml), pas së cilës një kesh i caktuar replicated-cache nuk do të jetë më i nevojshëm në anën e serverit Infinispan.

Konfigurimi i keçave

Ka dy tipe keçash në Keycloak:

  • Lokal. ËshtĂ« e vendosur pranĂ« bazĂ«s, shĂ«rben pĂ«r tĂ« reduktuar ngarkesĂ«n nĂ« bazĂ«n e tĂ« dhĂ«nave, si dhe pĂ«r tĂ« ulur vonesĂ«n e pĂ«rgjigjes. NĂ« kĂ«tĂ« tip cache ruhen realm, klientĂ«t, rolet dhe metadata e pĂ«rdoruesve. Ky tip cache nuk replikohet, edhe nĂ«se ky cache Ă«shtĂ« pjesĂ« e njĂ« klasteri Keycloak. NĂ«se njĂ« regjistrim nĂ« cache ndryshon — serverĂ«t e tjerĂ« nĂ« klaster pĂ«rfitojnĂ« njĂ« njoftim pĂ«r ndryshimin, pas sĂ« cilĂ«s regjistrimi fshihet nga cache. Shih pĂ«rshkrimin puna mĂ« tej, pĂ«r njĂ« pĂ«rshkrim mĂ« tĂ« detajuar tĂ« procedurĂ«s.

  • Replikohet. Trajton sesionet e pĂ«rdoruesve, tokenĂ«t offline, si dhe monitoron gabimet e hyrjes pĂ«r tĂ« identifikuar pĂ«rpjekjet e phishing-ut tĂ« fjalĂ«kalimeve dhe sulmeve tĂ« tjera. TĂ« dhĂ«nat e ruajtura nĂ« kĂ«to caches janĂ« temporale, ruhen vetĂ«m nĂ« memorien operative, por mund tĂ« replikohen nĂ«pĂ«r klaster.

Caches Infinispan

Sesiones — koncept nĂ« Keycloak, cache tĂ« veçanta, tĂ« cilat quhen authenticationSessions, pĂ«rdoren pĂ«r ruajtjen e tĂ« dhĂ«nave tĂ« pĂ«rdoruesve tĂ« caktuar. KĂ«rkesat nga kĂ«to cache zakonisht i nevojiten shfletuesit dhe serverave Keycloak, jo aplikacioneve. KĂ«tu shfaqet varĂ«sia nga sesionet e ngjitura, dhe kĂ«to cache nuk duhet tĂ« riplikohen, as nĂ« rastin e skenarĂ«ve Active-Active.

Tokat e veprimit. Një koncept tjetër, zakonisht i aplikuar për skenarë të ndryshëm, kur, për shembull, përdoruesi duhet të bëjë diçka asinkronisht përmes postës. Për shembull, gjatë procedurës harro passwordin cache actionTokens përdoret për të ndjekur metadatën e tokave të lidhura - për shembull, token ka qenë tashmë i përdorur dhe nuk mund të aktivizohet përsëri. Ky lloj cache zakonisht duhet të riplikohet midis qendrave të të dhënave.

Caching dhe skadimi i të dhënave të ruajtura punon për të hequr ngarkesën nga baza e të dhënave. Ky lloj caching përmirëson performancën, por sjell një problem të dukshëm. Nëse një server Keycloak përditëson të dhënat, serverat e tjerë duhet të njoftohen për këtë, në mënyrë që të mund të realizojnë përditësimin e të dhënave në caches e tyre. Keycloak përdor cache lokale realms, përdoruesit dhe autorizimi për caching të të dhënave nga baza.

Ka there edhe një cache të veçantë puna, i cili replikon në të gjitha qendrat e të dhënave. Ai vetë nuk ruan asnjë të dhënë nga baza, por shërben për të dërguar mesazhe për skadimin e të dhënave në nyjet e klastri mes qendrave të të dhënave. Me fjalë të tjera, sa herë që të dhënat përditësohen, nyja Keycloak dërgon një mesazh nyjeve të tjera në qendrën e saj të të dhënave, si dhe nyjeve të qendrave të tjera të të dhënave. Pasi të marrin një mesazh të tillë, çdo nyje kryen një pastrim të të dhënave përkatëse në caches e saj lokale.

Seancat e përdoruesve. Cache me emrat sessions, clientSessions, offlineSessions dhe offlineClientSessions, zakonisht replikohen mes qendrave të të dhënave dhe shërbejnë për të ruajtur të dhënat mbi seancat e përdoruesve, të cilat janë aktive gjatë aktivitetit të përdoruesit në shfletues. Këto caches punojnë me aplikacionin që trajton kërkesat HTTP nga përdoruesit e fundit, kështu që ato lidhen me sesionet e ngjitura dhe duhet të replikohen mes qendrave të të dhënave.

Mbrojtja nga sulmet brute force. Cache loginFailures shërben për të ndjekur të dhënat e gabimeve gjatë hyrjes, për shembull sa herë përdoruesi ka futur fjalëkalimin e gabuar. Replikimi i këtij cache-i është çështje e administratorit. Por për një numërim të saktë, është e nevojshme të aktivizoni replikimin mes qendrave të të dhënave. Nga ana tjetër, nëse këto të dhëna nuk replikohen, mund të përmirësohet performanca, dhe nëse ky është një problem, replikimi mund të mos aktivizohet.

Gjatë vendosjes së klasterit Infinispan, duhet të shtoni përkufizimet e cache-ve në skedarin e konfigurimeve:

Duhet të konfigurohet dhe të fillohet klasteri Infinispan para fillimit të klasterit Keycloak

Më pas duhet të konfigurohet remoteStore për Keycloak caches. Mjafton një skript, i cili krijohet në mënyrë të ngjashme me atë të mëparshmin, që përdoret për të konfigurimin e variableve CACHE_OWNERS, duhet ta ruani atë në një skedar dhe ta vendosni në katalog /opt/jboss/startup-scripts:

PĂ«rmbajtja e skriptit

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

echo *** Përditëso subsystem-in infinispan ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Shtoni lidhjen e socket-it të largët në server-in infinispan **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})

echo ** Përditëso elementin e punës të cached-replicated **
/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 ** Përditëso elementin e seancave të cached-distributed **
/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 ** Përditëso elementin e offlineSessions të cached-distributed **
/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 ** Përditëso elementin e clientSessions të cached-distributed **
/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 ** Përditëso elementin e offlineClientSessions të cached-distributed **
/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 ** Përditëso elementin e loginFailures të cached-distributed **
/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 ** Përditëso elementin e actionTokens të cached-distributed **
/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 ** Përditëso elementin e authenticationSessions të cached-distributed **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

echo *** Përditëso subsystem-in undertow ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

run-batch
stop-embedded-server

Mos u harroni të vendosni JAVA_OPTS për nodet e Keycloak për funksionimin e HotRod: remote.cache.host, remote.cache.port dhe emrin e shërbimit jboss.site.name.

Lidhjet dhe dokumentacioni shtesë

Artikulli Ă«shtĂ« pĂ«rkthyer dhe pĂ«rgatitur pĂ«r Habr nga punonjĂ«sit e qendrĂ«s mĂ«simore Slyrm — intensive, video kurse dhe trajnim korporativ nga profesionistĂ« tĂ« praktikĂ«s (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster