ProHoster > Blogs > Administrācija > Palaiž Keycloak HA režīmā Kubernetes

Palaiž Keycloak HA režīmā Kubernetes

Palaiž Keycloak HA režīmā Kubernetes

TL; DR: bÅ«s Keycloak, atvērtā koda piekļuves kontroles sistēmas apraksts, iekŔējās struktÅ«ras analÄ«ze, konfigurācijas detaļas.

Ievads un galvenās idejas

Å ajā rakstā mēs redzēsim pamata idejas, kas jāpatur prātā, izvietojot Keycloak kopu Kubernetes augÅ”pusē.

Ja vēlaties uzzināt vairāk par Keycloak, skatiet saites raksta beigās. Lai vairāk iedziļinātos praksē, varat mācÄ«ties mÅ«su krātuve ar moduli, kas Ä«steno Ŕī raksta galvenās idejas (tur ir palaiÅ”anas rokasgrāmata, Å”ajā rakstā tiks sniegts pārskats par ierÄ«ci un iestatÄ«jumiem, apm. tulkotājs).

Keycloak ir visaptveroÅ”a sistēma, kas rakstÄ«ta Java valodā un ir izveidota uz lietojumprogrammu servera Savvaļas muÅ”a. ÄŖsāk sakot, tā ir autorizācijas sistēma, kas nodroÅ”ina lietojumprogrammu lietotāju federācijas un SSO (vienreizējās pierakstÄ«Å”anās) iespējas.

Aicinām izlasīt oficiālo mājas lapa vai Wikipedia detalizētai izpratnei.

Keycloak palaiŔana

Lai palaistu Keycloak, ir nepiecieŔami divi pastāvīgi datu avoti:

  • Datubāze, ko izmanto, lai saglabātu noteiktus datus, piemēram, lietotāja informāciju
  • Datagrid cache, ko izmanto datu keÅ”atmiņai no datu bāzes, kā arÄ« dažu Ä«slaicÄ«gu un bieži mainÄ«gu metadatu, piemēram, lietotāju sesiju, glabāŔanai. ÄŖstenots Infinispan, kas parasti ir ievērojami ātrāks nekā datu bāze. Bet jebkurā gadÄ«jumā Infinispan saglabātie dati ir Ä«slaicÄ«gi - un tie nav nekur jāsaglabā, kad klasteris tiek restartēts.

Keycloak darbojas četros dažādos režīmos:

  • Normāls - viens un tikai viens process, kas konfigurēts, izmantojot failu standalone.xml
  • Regulāra klastera (augstas pieejamÄ«bas opcija) - visiem procesiem ir jāizmanto viena un tā pati konfigurācija, kas jāsinhronizē manuāli. IestatÄ«jumi tiek saglabāti failā standalone-ha.xml, turklāt jums ir jānodroÅ”ina kopÄ«ga piekļuve datu bāzei un slodzes lÄ«dzsvarotājs.
  • Domēnu klasteris ā€” klastera palaiÅ”ana normālā režīmā ātri kļūst par ikdieniŔķu un garlaicÄ«gu uzdevumu, klasterim augot, jo ikreiz, kad mainās konfigurācija, visas izmaiņas ir jāveic katrā klastera mezglā. Domēna darbÄ«bas režīms atrisina Å”o problēmu, iestatot kādu koplietojamu krātuves vietu un publicējot konfigurāciju. Å ie iestatÄ«jumi tiek saglabāti failā domēns.xml
  • Replikācija starp datu centriem ā€” ja vēlaties palaist Keycloak vairāku datu centru klasterÄ«, visbiežāk dažādās Ä£eogrāfiskās vietās. Izmantojot Å”o opciju, katram datu centram bÅ«s savs Keycloak serveru klasteris.

Å ajā rakstā mēs detalizēti apsvērsim otro iespēju, tas ir regulārs klasteris, un mēs arÄ« nedaudz skarsim tēmu par replikāciju starp datu centriem, jo ā€‹ā€‹ir lietderÄ«gi palaist Ŕīs divas opcijas Kubernetes. Par laimi, Kubernetes nav problēmu ar vairāku podiņu (Keycloak mezglu) iestatÄ«jumu sinhronizÄ“Å”anu, tāpēc domēnu klasteris To izdarÄ«t nebÅ«s ļoti grÅ«ti.

LÅ«dzu, ņemiet vērā arÄ« to, ka vārds klasteris pārējā raksta daļa attieksies tikai uz Keycloak mezglu grupu, kas darbojas kopā, nav nepiecieÅ”ams atsaukties uz Kubernetes kopu.

Regulāra Keycloak klasteris

Lai palaistu Keycloak Ŕajā režīmā, jums ir nepiecieŔams:

  • konfigurēt ārējo koplietojamo datu bāzi
  • uzstādiet slodzes balansētāju
  • ir iekŔējais tÄ«kls ar IP multiraides atbalstu

Mēs neapspriedÄ«sim ārējās datu bāzes izveidi, jo tas nav Ŕī raksta mērÄ·is. Pieņemsim, ka kaut kur darbojas datu bāze ā€“ un mums ir pieslēguma punkts ar to. Mēs vienkārÅ”i pievienosim Å”os datus vides mainÄ«gajiem.

Lai labāk izprastu, kā Keycloak darbojas kļūmjpārlēces (HA) klasterī, ir svarīgi zināt, cik lielā mērā tas viss ir atkarīgs no Wildfly klasterizācijas iespējām.

Wildfly izmanto vairākas apakÅ”sistēmas, dažas no tām tiek izmantotas kā slodzes lÄ«dzsvarotājs, dažas - kļūdu pielaidei. Slodzes lÄ«dzsvarotājs nodroÅ”ina lietojumprogrammu pieejamÄ«bu, kad klastera mezgls ir pārslogots, un kļūdu tolerance nodroÅ”ina lietojumprogrammu pieejamÄ«bu pat tad, ja daži klastera mezgli neizdodas. Dažas no Ŕīm apakÅ”sistēmām:

  • mod_cluster: darbojas kopā ar Apache kā HTTP slodzes balansētāju, ir atkarÄ«gs no TCP multiraides, lai pēc noklusējuma atrastu saimniekdatorus. Var aizstāt ar ārējo balansētāju.

  • infinispan: izplatÄ«ta keÅ”atmiņa, kas kā transporta slāni izmanto JGroups kanālus. Turklāt tas var izmantot HotRod protokolu, lai sazinātos ar ārēju Infinispan klasteru, lai sinhronizētu keÅ”atmiņas saturu.

  • jgroups: nodroÅ”ina grupu saziņas atbalstu ļoti pieejamiem pakalpojumiem, kuru pamatā ir JGroups kanāli. Nosauktās caurules ļauj lietojumprogrammu gadÄ«jumus klasterÄ« savienot grupās, lai komunikācijai bÅ«tu tādas Ä«paŔības kā uzticamÄ«ba, sakārtotÄ«ba un jutÄ«gums pret kļūmēm.

Slodzes balansētājs

Instalējot balansētāju kā ieejas kontrolleri Kubernetes klasterī, ir svarīgi paturēt prātā tālāk norādīto.

Keycloak pieņem, ka klienta attālā adrese, kas savieno autentifikācijas serveri, izmantojot HTTP, ir klienta datora reālā IP adrese. Balansētāja un ieejas iestatÄ«jumiem ir pareizi jāiestata HTTP galvenes X-Forwarded-For Šø X-Forwarded-Protoun saglabājiet arÄ« sākotnējo nosaukumu HOST. Jaunākā versija ingress-nginx (>0.22.0) pēc noklusējuma to atspējo

Karoga aktivizÄ“Å”ana proxy-address-forwarding iestatot vides mainÄ«go PROXY_ADDRESS_FORWARDING Š² true ļauj Keycloak saprast, ka tas darbojas aiz starpniekservera.

Jums arÄ« jāiespējo lipÄ«gās sesijas iekļūŔanā. Keycloak izmanto izplatÄ«to Infinispan keÅ”atmiņu, lai saglabātu datus, kas saistÄ«ti ar paÅ”reizējo autentifikācijas sesiju un lietotāja sesiju. KeÅ”atmiņas pēc noklusējuma darbojas ar vienu Ä«paÅ”nieku, citiem vārdiem sakot, konkrētā sesija tiek glabāta kādā klastera mezglā, un citiem mezgliem tas ir jāveic attālināti, ja tiem ir nepiecieÅ”ama piekļuve Å”ai sesijai.

PrecÄ«zāk, pretēji dokumentācijā norādÄ«tajam, mums nederēja sesijas pievienoÅ”ana ar sÄ«kfaila nosaukumu AUTH_SESSION_ID. Keycloak ir novirzÄ«Å”anas cilpa, tāpēc iesakām izvēlēties citu sÄ«kfaila nosaukumu lipÄ«gajai sesijai.

Keycloak pievieno arÄ« tā mezgla nosaukumu, kas atbildēja pirmais AUTH_SESSION_ID, un tā kā katrs ļoti pieejamās versijas mezgls izmanto vienu un to paÅ”u datu bāzi, katrs no tiem jābÅ«t atseviŔķs un unikāls mezgla identifikators darÄ«jumu pārvaldÄ«bai. Ieteicams ielikt JAVA_OPTS parametri jboss.node.name Šø jboss.tx.node.id katram mezglam unikāls - varat, piemēram, ievietot poda nosaukumu. Ja ievietojat aplikuma nosaukumu, neaizmirstiet par 23 rakstzÄ«mju ierobežojumu jboss mainÄ«gajiem, tāpēc labāk ir izmantot StatefulSet, nevis izvietoÅ”anu.

Vēl viens grābeklis - ja pods tiek izdzēsts vai restartēts, tā keÅ”atmiņa tiek zaudēta. Ņemot to vērā, ir vērts iestatÄ«t keÅ”atmiņas Ä«paÅ”nieku skaitu visām keÅ”atmiņām vismaz uz diviem, lai saglabātos keÅ”atmiņas kopija. Risinājums ir skriet Wildfly scenārijs startējot podi, ievietojot to direktorijā /opt/jboss/startup-scripts konteinerā:

Skripta saturs

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

pēc tam iestatiet vides mainÄ«gā vērtÄ«bu CACHE_OWNERS uz nepiecieÅ”amo.

Privāts tīkls ar IP multiraides atbalstu

Ja izmantojat Weavenet kā CNI, multiraide darbosies nekavējoties ā€” un jÅ«su Keycloak mezgli redzēs viens otru, tiklÄ«dz tie tiks palaisti.

Ja jūsu Kubernetes klasterī nav IP multiraides atbalsta, varat konfigurēt JGroups darbam ar citiem protokoliem, lai atrastu mezglus.

Pirmā iespēja ir izmantot KUBE_DNSkas izmanto headless service lai atrastu Keycloak mezglus, vienkārÅ”i nododiet JGroups tā pakalpojuma nosaukumu, kas tiks izmantots mezglu atraÅ”anai.

Vēl viena iespēja ir izmantot metodi KUBE_PING, kas darbojas ar API, lai meklētu mezglus (jums ir jākonfigurē serviceAccount ar tiesÄ«bām list Šø get, un pēc tam konfigurējiet apvidus darbam ar Å”o serviceAccount).

Veids, kādā JGroups atrod mezglus, ir konfigurēts, iestatot vides mainÄ«gos JGROUPS_DISCOVERY_PROTOCOL Šø JGROUPS_DISCOVERY_PROPERTIES. Par KUBE_PING jums ir jāizvēlas pākstis, jautājot namespace Šø labels.

ļø Ja izmantojat multiraidi un vienā Kubernetes klasterÄ« darbināt divus vai vairākus Keycloak klasterus (teiksim, vienu nosaukumvietā production, otrais - staging) ā€” viena Keycloak klastera mezgli var pievienoties citam klasterim. Noteikti izmantojiet unikālu multiraides adresi katram klasterim, iestatot mainÄ«gosjboss.default.multicast.address Šø jboss.modcluster.multicast.address Š² JAVA_OPTS.

Replikācija starp datu centriem

Palaiž Keycloak HA režīmā Kubernetes

Saite

Keycloak izmanto vairākas atseviŔķas Infinispan keÅ”atmiņas kopas katram datu centram, kurā atrodas Keycloak klasteri, kas sastāv no Keycloak mezgliem. Bet nav atŔķirÄ«bas starp Keycloak mezgliem dažādos datu centros.

Keycloak mezgli saziņai starp datu centriem izmanto ārējo Java Data Grid (Infinispan serverus). Sakari darbojas saskaņā ar protokolu Infinispan HotRod.

Infinispan keÅ”atmiņas ir jākonfigurē ar atribÅ«tu remoteStore, lai datus varētu glabāt attālināti (citā datu centrā, apm. tulkotājs) keÅ”atmiņas. Starp JDG serveriem ir atseviŔķas infinispan kopas, lai dati tiktu saglabāti JDG1 uz vietas. site1 tiks replicēts uz JDG2 uz vietas site2.

Visbeidzot, saņemoÅ”ais JDG serveris informē Keycloak serverus par savu klasteru, izmantojot klienta savienojumus, kas ir HotRod protokola funkcija. Keycloak mezgli ieslēgti site2 atjauniniet savas Infinispan keÅ”atmiņas, un konkrētā lietotāja sesija kļūst pieejama arÄ« Keycloak mezglos site2.

Dažām keÅ”atmiņām ir iespējams arÄ« neveidot dublējumus un pilnÄ«bā izvairÄ«ties no datu rakstÄ«Å”anas caur Infinispan serveri. Lai to izdarÄ«tu, iestatÄ«jums ir jānoņem remote-store specifiska Infinispan keÅ”atmiņa (failā standalone-ha.xml), pēc tam daži konkrēti replicated-cache arÄ« vairs nebÅ«s vajadzÄ«gs Infinispan servera pusē.

KeÅ”atmiņu iestatÄ«Å”ana

Keycloak ir divu veidu keÅ”atmiņas:

  • Vietējais. Tas atrodas blakus datu bāzei un kalpo, lai samazinātu datu bāzes slodzi, kā arÄ« samazinātu atbildes latentumu. Šāda veida keÅ”atmiņā tiek saglabāti domēni, klienti, lomas un lietotāja metadati. Šāda veida keÅ”atmiņa netiek replicēta, pat ja keÅ”atmiņa ir daļa no Keycloak klastera. Ja mainās kāds ieraksts keÅ”atmiņā, ziņojums par izmaiņām tiek nosÅ«tÄ«ts uz atlikuÅ”ajiem klastera serveriem, pēc tam ieraksts tiek izslēgts no keÅ”atmiņas. SkatÄ«t aprakstu work SÄ«kāku procedÅ«ras aprakstu skatiet tālāk.

  • Replicēts. Apstrādā lietotāju sesijas, bezsaistes pilnvaras, kā arÄ« uzrauga pieteikÅ”anās kļūdas, lai noteiktu paroles pikŔķerÄ“Å”anas mēģinājumus un citus uzbrukumus. Å ajās keÅ”atmiņās glabātie dati ir Ä«slaicÄ«gi, glabāti tikai RAM, taču tos var replicēt visā klasterÄ«.

Infinispan keÅ”atmiņas

Sesijas - Keycloak koncepcija, tiek izsauktas atseviŔķas keÅ”atmiņas authenticationSessions, tiek izmantoti konkrētu lietotāju datu glabāŔanai. PieprasÄ«jumi no Ŕīm keÅ”atmiņām parasti ir nepiecieÅ”ami pārlÅ«kprogrammai un Keycloak serveriem, nevis lietojumprogrammām. Å eit parādās atkarÄ«ba no lipÄ«gajām sesijām, un Ŕādas keÅ”atmiņas paÅ”as nav jāreplicē pat Active-Active režīmā.

DarbÄ«bas marÄ·ieri. Vēl viens jēdziens, ko parasti izmanto dažādiem scenārijiem, kad, piemēram, lietotājam kaut kas jādara asinhroni pa pastu. Piemēram, procedÅ«ras laikā forget password keÅ”atmiņa actionTokens izmanto, lai izsekotu saistÄ«to marÄ·ieru metadatus ā€” piemēram, marÄ·ieris jau ir izmantots, un to nevar atkārtoti aktivizēt. Šāda veida keÅ”atmiņa parasti ir jāreplicē starp datu centriem.

Saglabāto datu keÅ”atmiņa un novecoÅ”ana darbojas, lai atvieglotu datu bāzes slodzi. Šāda veida keÅ”atmiņa uzlabo veiktspēju, taču rada acÄ«mredzamu problēmu. Ja viens Keycloak serveris atjaunina datus, par to ir jābrÄ«dina citi serveri, lai tie varētu atjaunināt datus savās keÅ”atmiņās. Keycloak izmanto lokālās keÅ”atmiņas realms, users Šø authorization datu saglabāŔanai keÅ”atmiņā no datu bāzes.

Ir arÄ« atseviŔķa keÅ”atmiņa work, kas tiek replicēta visos datu centros. Tā pati neuzglabā nekādus datus no datu bāzes, bet kalpo, lai nosÅ«tÄ«tu ziņojumus par datu novecoÅ”anu klasteru mezgliem starp datu centriem. Citiem vārdiem sakot, tiklÄ«dz dati tiek atjaunināti, Keycloak mezgls nosÅ«ta ziņojumu citiem tā datu centra mezgliem, kā arÄ« mezgliem citos datu centros. Pēc Ŕāda ziņojuma saņemÅ”anas katrs mezgls izdzÄ“Å” atbilstoÅ”os datus savās lokālajās keÅ”atmiņās.

Lietotāju sesijas. KeÅ”atmiņas ar nosaukumiem sessions, clientSessions, offlineSessions Šø offlineClientSessions, parasti tiek replicēti starp datu centriem un kalpo datu glabāŔanai par lietotāju sesijām, kas ir aktÄ«vas, kamēr lietotājs ir aktÄ«vs pārlÅ«kprogrammā. Å Ä«s keÅ”atmiņas darbojas ar lietojumprogrammu, kas apstrādā HTTP pieprasÄ«jumus no galalietotājiem, tāpēc tās ir saistÄ«tas ar lipÄ«gām sesijām un ir jāreplicē starp datu centriem.

Brutāla spēka aizsardzÄ«ba. KeÅ”atmiņa loginFailures Izmanto, lai izsekotu pieteikÅ”anās kļūdu datus, piemēram, cik reizes lietotājs ievadÄ«jis nepareizu paroli. Å Ä«s keÅ”atmiņas pavairoÅ”ana ir administratora pienākums. Bet, lai veiktu precÄ«zu aprēķinu, ir vērts aktivizēt replikāciju starp datu centriem. Bet, no otras puses, ja jÅ«s nereplicēsit Å”os datus, jÅ«s uzlabosit veiktspēju, un, ja rodas Ŕī problēma, replikācija var netikt aktivizēta.

Izlaižot Infinispan klasteru, iestatÄ«jumu failam jāpievieno keÅ”atmiņas definÄ«cijas:

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

Pirms Keycloak klastera palaiÅ”anas jums ir jākonfigurē un jāstartē Infinispan klasteris

Pēc tam jums ir jākonfigurē remoteStore Keycloak keÅ”atmiņām. Lai to izdarÄ«tu, pietiek ar skriptu, kas tiek darÄ«ts lÄ«dzÄ«gi kā iepriekŔējais, kas tiek izmantots mainÄ«gā iestatÄ«Å”anai CACHE_OWNERS, jums tas ir jāsaglabā failā un jāievieto direktorijā /opt/jboss/startup-scripts:

Skripta saturs

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

Neaizmirstiet instalēt JAVA_OPTS lai Keycloak mezgli palaistu HotRod: remote.cache.host, remote.cache.port un pakalpojuma nosaukums jboss.site.name.

Saites un papildu dokumentācija

Rakstu tulkoja un sagatavoja Hābram darbinieki Slurm mācÄ«bu centrs ā€” intensÄ«vi kursi, video kursi un korporatÄ«vās apmācÄ«bas no praktizējoÅ”iem speciālistiem (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Avots: www.habr.com

Pievieno komentāru