ProHoster > Blog > Administrim > Nisja e Keycloak në modin HA në Kubernetes

Nisja e Keycloak në modin HA në Kubernetes

Nisja e Keycloak në modin HA në Kubernetes

TL;DR: do të jetë një përshkrim i Keycloak, sistemit të kontrollit të aksesit me kod të hapur, analiza e strukturës së brendshme, detajet e konfigurimit.

Hyrja dhe idetë kryesore

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

NĂ«se dĂ«shironi tĂ« dini mĂ« shumĂ« rreth Keycloak — kontaktoni linket nĂ« fund tĂ« artikullit. PĂ«r tĂ« thelluar praktiken — mund tĂ« studioni repozitorn tonĂ« me modulin qĂ« implementon idetĂ« kryesore tĂ« kĂ«tij artikulli (udhĂ«zimi pĂ«r fillimin atje po ashtu, nĂ« kĂ«tĂ« artikull do tĂ« jepet njĂ« pasqyrĂ« e strukturĂ«s dhe konfigurimeve, shĂ«n. e pĂ«rkthyesit).

Keycloak është një sistem kompleks, i shkruar në Java dhe ndërtuar mbi serverin e aplikacioneve Wildfly. Nëse do të flasim shkurtimisht, është një framework për autorizim, që i jep përdoruesve të aplikacioneve federatën dhe mundësinë e SSO (single sign-on).

Ju ftojmë të lexoni zyrtarin faqen ose Wikipedia për një kuptim më të detajuar.

Fillimi 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Ă« qĂ«ndrueshme, si informacioni pĂ«r pĂ«rdoruesit
  • Cache i Datagrid, i cili pĂ«rdoret pĂ«r ruajtjen e tĂ« dhĂ«nave nga baza, si dhe pĂ«r ruajtjen e disa metadatanĂ«ve tĂ« shkurtĂ«r dhe tĂ« ndryshueshĂ«m shpesh, siç janĂ« sesionet e pĂ«rdoruesve. Realizohet Infinispan, i cili Ă«shtĂ« zakonisht 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 duhen ruajtur askund gjatĂ« rindizjes sĂ« klasterit.

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

  • Zakonisht — njĂ« dhe vetĂ«m njĂ« proces, i cili konfigurohet pĂ«rmes skedarit standalone.xml
  • NjĂ« klaster i zakonshĂ«m (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, gjithashtu duhet tĂ« bĂ«het ndarja e pĂ«rbashkĂ«t e bazĂ«s sĂ« tĂ« dhĂ«nave dhe njĂ« balancues ngarkese.
  • Klasteri i domenit — fillimi i klasterit nĂ« mĂ«nyrĂ« tĂ« zakonshme shpejt bĂ«het njĂ« aktivitet rutinor dhe i mĂ«rzitshĂ«m me rritjen e klasterit, pasi çdo herĂ« gjatĂ« ndryshimit tĂ« konfigurimit duhet tĂ« bĂ«hen tĂ« gjitha ndryshimet nĂ« çdo nyje tĂ« klasterit. MĂ«nyra e funksionimit tĂ« domenit e zgjidh kĂ«tĂ« çështje duke konfiguruar njĂ« hapĂ«sirĂ« tĂ« pĂ«rbashkĂ«t dhe botimin e konfiguracionit. KĂ«to cilĂ«sime ruhen nĂ« skedarin domain.xml
  • Replikimi midis qendrave tĂ« tĂ« dhĂ«nave — nĂ« rast se dĂ«shironi tĂ« lançoni Keycloak nĂ« njĂ« klasĂ«r nga disa qendra tĂ« tĂ« dhĂ«nave, shpesh herĂ« nĂ« vende gjeografikisht tĂ« ndryshme. NĂ« kĂ«tĂ« variant tĂ« funksionimit, çdo qendĂ«r tĂ« dhĂ«nash do tĂ« ketĂ« klastrin e vet tĂ« serverĂ«ve Keycloak.

Në këtë artikull, ne do të shqyrtojmë në detaje variantin e dytë, atë të klastri normal, si dhe do të përmendim pak mbi replikimin midis qendrave të të dhënave, pasi këto dy variante kanë kuptim të lancohen në Kubernetes. Fatmirësisht, në Kubernetes nuk ka problem me sinkronizimin e konfigurimeve të shumë pod-ëve (nodes Keycloak), kështu që klastri domen nuk do të jetë shumë e vështirë për tu realizuar.

Gjithashtu, ju lutemi, vini re se fjala klasër në fund të artikullit do të përdoret ekskluzivisht për grupin e nodes Keycloak që punojnë së bashku, nuk ka nevojë të referohemi në klastrin Kubernetes.

Klastri normal i Keycloak

Për të lancuar Keycloak në këtë mënyrë, duhet:

  • tĂ« konfiguroni njĂ« bazĂ« tĂ« dhĂ«nash tĂ« jashtme tĂ« pĂ«rbashkĂ«t
  • tĂ« instaloni njĂ« balancues ngarkese
  • tĂ« keni njĂ« rrjet tĂ« brendshĂ«m me mbĂ«shtetje pĂ«r ip multicast

Nuk do tĂ« shqyrtojmĂ« konfigurimin e bazĂ«s sĂ« jashtme, pasi nuk Ă«shtĂ« objektivi i kĂ«tij artikulli. Le tĂ« supozojmĂ« se diku ekziston njĂ« bazĂ« e dhĂ«nash funksionale — dhe ne kemi njĂ« pikĂ« lidhjeje pĂ«r tĂ«. Thjesht do t'i shtojmĂ« kĂ«to tĂ« dhĂ«na nĂ« variablat e ambientit.

Për të kuptuar më mirë se si funksionon Keycloak në një klasër me disponueshmëri të lartë (HA), është e rëndësishme të dini se sa shumë varet gjithçka nga aftësitë e Wildfly për klastrimin.

Wildfly pĂ«rdor disa nĂ«nsisteme, disa prej tĂ« cilave pĂ«rdoren si balancues ngarkese, disa — pĂ«r disponueshmĂ«ri tĂ« lartĂ«. Balancuesi i ngarkesĂ«s siguron aksesin nĂ« aplikacion kur nodi i klastrit Ă«shtĂ« i ngarkuar, kurse disponueshmĂ«ria e lartĂ« garanton aksesin nĂ« aplikacion edhe nĂ« rastin e dĂ«shtimit tĂ« pjesĂ«s sĂ« nodĂ«ve tĂ« klastrit. Disa nga kĂ«to nĂ«nsisteme janĂ«:

  • mod_cluster: punon nĂ« bashkĂ«punim me Apache si balancues HTTP, varet nga TCP multicast pĂ«r gjetjen e nodĂ«ve si parazgjedhje. Mund tĂ« zĂ«vendĂ«sohet nga njĂ« balancues tĂ« jashtĂ«m.

  • infinispan: cache e shpĂ«rndarĂ«, e cila pĂ«rdor kanale JGroups si nivel transporti. ShtesĂ« mund tĂ« pĂ«rdorĂ« protokollin HotRod pĂ«r komunikimin me klastrin e jashtĂ«m Infinispan pĂ«r sinkronizimin e pĂ«rmbajtjes sĂ« cache-it.

  • jgroups: ofron mbĂ«shtetje pĂ«r lidhjen e grupeve pĂ«r shĂ«rbime me akses tĂ« lartĂ« tĂ« bazuara nĂ« kanalet JGroups. Kanale tĂ« emĂ«ruara lejojnĂ« qĂ« instancat e aplikacionit nĂ« grup tĂ« lidhen nĂ« grupe nĂ« mĂ«nyrĂ« qĂ« lidhja tĂ« ketĂ« karakteristika si besueshmĂ«ri, renditje dhe ndjeshmĂ«ri ndaj dĂ«shtimeve.

Balancuesi i ngarkesës

Kur vendosni balancuesin si kontrolues ingress në grupe në Kubernetes, është e rëndësishme të keni parasysh gjërat e mëposhtme:

Funksionimi i Keycloak nënkupton që adresa e largët e klientit që lidhet përmes HTTP me serverin e autentikimit është adresa reale ip e kompjuterit të klientit. Cilësimet e balancuesit dhe ingress duhet të vendosin saktë titujt HTTP X-Forwarded-For dhe X-Forwarded-Proto, si dhe të mbajnë titullin origjinal HOST. Versioni më i fundit ingress-nginx (> 0.22.0) e çaktivizon këtë në mënyrë default

Aktivizimi i flamurit proxy-address-forwarding duke vendosur variablën e ambientit PROXY_ADDRESS_FORWARDING në true i jep Keycloak kuptimin se 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ë autentikimit dhe seancën e përdoruesit. Cache-t punojnë me një pronar si default, në fjalë, kjo seancë e veçantë ruhet në një nod të caktuar në grup, ndërsa nodet e tjera duhet ta kërkojnë atë në distancë nëse kanë nevojë për akses në këtë seancë.

Konkretisht, në rastin tonë, përkundër dokumentacionit, bashkimi i seancës me emrin e cookie-t AUTH_SESSION_ID. Keycloak krijoi një rrethore, prandaj rekomandojmë të zgjidhni një emër tjetër cookie për seancën e ngjitur.

Po ashtu, Keycloak bashkangjit emrin e nodit qĂ« ktheu pĂ«rgjigjen e parĂ« te AUTH_SESSION_ID, dhe pasi çdo nod nĂ« variantin me akses tĂ« lartĂ« pĂ«rdor tĂ« njĂ«jtĂ«n bazĂ« tĂ« dhĂ«nash, çdo njĂ«ri prej tyre duhet tĂ« ketĂ« njĂ« identifikues tĂ« veçantĂ« dhe unik tĂ« nodit pĂ«r menaxhimin e transaksioneve. Rekomandohet qĂ« nĂ« JAVA_OPTS parametrat jboss.node.name dhe jboss.tx.node.id tĂ« jenĂ« unike pĂ«r çdo nod — p.sh. mund tĂ« vendosni emrin e podit. NĂ«se do tĂ« vendosni emrin e podit, mos harroni rregullin e 23 karaktereve pĂ«r variablat jboss, ndaj Ă«shtĂ« mĂ« mirĂ« tĂ« pĂ«rdorni StatefulSet dhe jo Deployment.

NjĂ« tjetĂ«r problem — nĂ«se podi hiqet ose ripĂ«rndahen, cache-i humbet. Me kĂ«tĂ« nĂ« mendje, duhet tĂ« vendosni numrin e pronarĂ«ve tĂ« cache-it pĂ«r tĂ« gjithĂ« cache-t tĂ« paktĂ«n dy, nĂ« mĂ«nyrĂ« qĂ« tĂ« mbetet njĂ« kopje e cache-it. Zgjidhja Ă«shtĂ« tĂ« nisim skripti pĂ«r Wildfly kur ekzekutoni podin, duke e vendosur atĂ« nĂ« katalog /opt/jboss/startup-scripts nĂ« kontejner:

PĂ«rmbajtja e skriptit

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

echo * Duke vendosur CACHE_OWNERS në "${env.CACHE_OWNERS}" në të gjitha konteineret e cache

/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 së cilës vendosni vlerën e variablës së mjedisit CACHE_OWNERS në të nevojshme.

Rrjeti privat me mbështetje ip multicast

NĂ«se pĂ«rdorni Weavenet si CNI, multicast do tĂ« funksionojĂ« menjĂ«herĂ« — dhe nyjet tuaja Keycloak do tĂ« shohin njĂ«ra-tjetrĂ«n sa herĂ« tĂ« jenĂ« aktivizuar.

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

Opsioni i parë është përdorimi i KUBE_DNS, i cili përdor shërbimin headless për të gjetur nyjet Keycloak, thjesht i kaloni JGroups emrin e shërbimit që do të përdoret për të gjetur nyjet.

Një tjetër opsion është përdorimi i metodës KUBE_PING, e cila punon me API për të gjetur nyjet (duhet të konfiguroni serviceAccount me të drejtat list dhe merr, pas së cilës konfiguroni podet për të punuar me këtë serviceAccount).

Mënyra e gjetjes së nyjeve për JGroups konfigurimi bëhet duke vendosur variablat e mjedisit JGROUPS_DISCOVERY_PROTOCOL dhe JGROUPS_DISCOVERY_PROPERTIES. Për KUBE_PING duhet të zgjidhni podet duke caktuar namespace dhe labels.

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

Replikimi midis qendrave të të dhënave

Nisja e Keycloak në modin HA në Kubernetes

Lidhja

Keycloak përdor klastere të veçanta të koshave Infinispan për çdo qendër të të dhënave, ku ndodhen klasteret Keycloak, të përbërë nga nyjet Keycloak. Por nuk ka ndonjë ndryshim midis nyjeve Keycloak në qendrat e të dhënave të ndryshme.

Nyjet Keycloak përdorin Java Data Grid të jashtme (serverët Infinispan) për të lidhur qendrat e të dhënave. Lidhja funksionon me protokollin Infinispan HotRod.

Cache-t e Infinispan duhet të konfigurohen me atributin remoteStore, në mënyrë që të dhënat të mund të ruhen në cache të largëta (në një qendër tjetër të të dhënave, shën. e përkthyesit) cache. Ka klastere të veçanta infinispan midis serverëve JDG, kështu që të dhënat e ruajtura në JDG1 në faqen site1 do të replikohen në JDG2 në faqen site2.

Dhe në fund, serveri përballës JDG njofton serverët Keycloak të klasterit të tij përmes lidhjeve klient, që është një karakteristikë e protokollit HotRod. Nyjet Keycloak në site2 përditësojnë cache-t e tyre Infinispan, dhe një sesion i veçantë përdoruesi bëhet gjithashtu i disponueshëm në nyjet Keycloak në site2.

Për disa cache është gjithashtu e mundur të mos bëhen kopje rezervë dhe të hiqet plotësisht shkrimi i të dhënave përmes serverit Infinispan. Për këtë, duhet të hiqet konfigurimi remote-store për cache-in specifik Infinispan (në skedarin standalone-ha.xml), pas të cilit një replicated-cache nuk do të jetë më e nevojshme në anën e serverit Infinispan.

Konfigurimi i cache-ve

Ka dy lloje cache-ve në Keycloak:

  • Vendor. Ai ndodhet 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 ruhet realm, klientĂ«t, rolet dhe metadata pĂ«r pĂ«rdoruesit. Ky tip cache nuk replikon, edhe nĂ«se ky cache Ă«shtĂ« pjesĂ« e klasterit Keycloak. NĂ«se njĂ« regjistrim ndryshon nĂ« cache – tĂ« tjerĂ«t nĂ« klaster dĂ«rgohet njĂ« mesazh pĂ«r ndryshimin, pas sĂ« cilĂ«s regjistrimi pĂ«rjashtohet nga cache. Shih pĂ«rshkrimin work mĂ« poshtĂ«, pĂ«r njĂ« pĂ«rshkrim mĂ« tĂ« detajuar tĂ« procedurĂ«s.

  • Replicuesi. Trajon sesionet e pĂ«rdoruesve, tokenet offline, si dhe monitoron gabimet e hyrjes pĂ«r tĂ« identifikuar pĂ«rpjekjet e phishing tĂ« fjalĂ«kalimeve dhe sulme tĂ« tjera. TĂ« dhĂ«nat e ruajtura nĂ« kĂ«to cache janĂ« tĂ« pĂ«rkohshme, ruhen vetĂ«m nĂ« memorien operativ, por mund tĂ« replikohen nĂ« klaster.

Cache-t Infinispan

Sesione — njĂ« koncept nĂ« Keycloak, cache tĂ« veçanta, tĂ« cilat quhen authenticationSessions, pĂ«rdoren pĂ«r ruajtjen e tĂ« dhĂ«nave tĂ« pĂ«rdoruesve tĂ« veçantĂ«. KĂ«rkesat nga kĂ«to cache zakonisht i nevojiten shfletuesit dhe serverĂ«ve Keycloak, jo aplikacioneve. KĂ«tu dhe shfaqet varĂ«sia nga sesionet e ngjitura, dhe kĂ«to cache nuk kanĂ« nevojĂ« tĂ« replikohen, madje edhe nĂ« rastin e modit Active-Active.

Tokenet e veprimit. Një koncept tjetër, zakonisht përdoret 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 kesh actionTokens përdoret për të ndjekur metadata të lidhura me tokena - për shembull, një token që është përdorur tashmë dhe nuk mund të aktivizohet përsëri. Ky lloj kesh-i zakonisht duhet të riplikohet midis qendrave të të dhënave.

Keshimi dhe skadimi i të dhënave të ruajtura punon për të lehtësuar ngarkesën në bazën e të dhënave. Keshimi i tillë përmirëson performancën, por shton një problem të dukshëm. Nëse një server Keycloak përditëson të dhënat, serverët e tjerë duhet të njoftohen për këtë, në mënyrë që ata të mund të përditësojnë të dhënat në kesh-et e tyre. Keycloak përdor kesh-e lokale realms, users dhe autorizimi për keshimin e të dhënave nga baza.

Gjithashtu ekziston një kesh i veçantë work, i cili riplikohet 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ë nyjat e klasës midis qendrave të të dhënave. Në 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. Pas Marrjes së këtij mesazhi, çdo nyjë pastron të dhënat përkatëse në kesh-et e saj lokale.

Seancat e përdoruesëve. Kesh-et me emrat sessions, clientSessions, offlineSessions dhe offlineClientSessions, zakonisht riplikohen midis qendrave të të dhënave dhe shërbejnë për ruajtjen e të dhënave mbi sesionet e përdoruesve, të cilat janë aktive gjatë veprimtarisë së përdoruesit në shfletues. Këto kesh-e punojnë me aplikacionin që trajton kërkesat HTTP nga përdoruesit e fundit, ndaj janë të lidhura me sesionet e ngjitura dhe duhet të riplikohen midis qendrave të të dhënave.

Mbrojtja nga hyrjet me forcë bruto. Kesh loginFailures shërben për ndjekjen e të dhënave të gabimeve të hyrjes, për shembull, sa herë që një përdorues ka futur një fjalëkalim të gabuar. Riplikimi i këtij kesh-i është një përgjegjësi e administratorit. Por për një numër të saktë, është e rekomandueshme të aktivizohet riplikimi midis qendrave të të dhënave. Nga ana tjetër, nëse këto të dhëna nuk riplikohen, mund të përmirësohet performanca dhe nëse ky është problemi - riplikimi mund të mos aktivizohet.

Kur krijohet klasteri Infinispan, duhet të shtohen definicionet e kesh-eve në skedarin e konfigurimeve:

Duhet konfiguruar dhe nisur klasteri Infinispan para se të nisë klasteri Keycloak

Më pas, duhet të konfigurohet remoteStore për cache-t e Keycloak. Për këtë, mjafton një skenar që krijohet në mënyrë të ngjashme me të kaluarin, i cili përdoret për të konfiguruar ndryshoren CACHE_OWNERS, duhet ta ruash në një skedar dhe të vendoset 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 nënkapacitetin infinispan ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Shto lidhjen e socket të largët në serverin 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 në cached-replikuar **
/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 sesioneve në cached-shpërndarë **
/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 offlineSessions në cached-shpërndarë **
/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 clientSessions në cached-shpërndarë **
/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 offlineClientSessions në cached-shpërndarë **
/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 loginFailures në cached-shpërndarë **
/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 actionTokens në cached-shpërndarë **
/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 authenticationSessions në cached-shpërndarë **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

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

run-batch
stop-embedded-server

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

Linket dhe dokumentacioni shtesë

Artikulli Ă«shtĂ« pĂ«rkthyer dhe pĂ«rgatitur pĂ«r Habr nga punonjĂ«sit e qendrĂ«s mĂ«simore Slyrm — intensivĂ«, kurse video dhe trajnim korporatash nga specialistĂ« praktikues (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster