🥇Exekutatu Keycloak HA moduan Kubernetes

TL; DR: Keycloak-en deskribapena izango da, kode irekiko sarbidea kontrolatzeko sistema, barne gailuaren azterketa, konfigurazio xehetasunak.

Sarrera eta ideia nagusiak

Artikulu honetan, Keycloak kluster bat Kubernetesen gainean zabaltzean kontuan izan beharreko ideia nagusiak ikusiko ditugu.

Keycloak-i buruz gehiago jakin nahi baduzu, irakurri artikulu amaierako estekak. Praktikan sakonago murgiltzeko, ikas dezakezu gure biltegia artikulu honen ideia nagusiak ezartzen dituen modulu batekin (abiarazte-gida hor dago, artikulu honetan gailuaren eta ezarpenen ikuspegi orokorra izango da, gutxi gorabehera. itzultzailea).

Keycloak Javan idatzitako eta aplikazio zerbitzari baten gainean eraikitako sistema konplexu bat da. Basatia. Laburbilduz, aplikazio-erabiltzaileen federazioa eta SSO (single sign-on) gaitasuna ematen duen baimen-esparru bat da.

Ofiziala irakurtzera gonbidatzen zaituztegu web edo Wikipedia zehatz-mehatz ulertzeko.

Hasi Keycloak

Keycloak-ek bi datu-iturri iraunkor behar ditu exekutatzeko:

Datu iraunkorrak gordetzeko erabiltzen den datu-basea, hala nola erabiltzaileei buruzko informazioa
Datagrid cachea, datu-baseko datuak gordetzeko erabiltzen dena, baita iraupen laburreko eta maiz aldatzen diren metadatu batzuk gordetzeko ere, hala nola erabiltzaileen saioak. Askatuta Infinispan, datu-basea baino nabarmen azkarragoa izan ohi dena. Baina, nolanahi ere, Infinispan-en gordetako datuak iragankorrak dira, eta ez dute zertan nonbait gorde behar klusterra berrabiarazten denean.

Keycloak lau modu desberdinetan funtzionatzen du:

arrunt - prozesu bat eta bakarra, fitxategi baten bidez konfiguratua standalone.xml
ohiko kluster (oso erabilgarri dagoen aukera) - Prozesu guztiek konfigurazio bera erabili behar dute, eskuz sinkronizatu behar dena. Ezarpenak fitxategi batean gordetzen dira standalone-ha.xml, gainera, datu-baserako sarbide partekatua eta karga-orekatzailea egin behar dituzu.
Domeinu-klusterra - Klusterra modu normalean abiaraztea azkar errutina eta aspergarria bihurtzen da clusterra hazten den heinean, izan ere, konfigurazioa aldatzen den bakoitzean, aldaketa guztiak klusterreko nodo bakoitzean egin behar dira. Domeinuaren funtzionamendu moduak arazo hau konpontzen du partekatutako biltegiratze batzuk konfiguratuz eta konfigurazioa argitaratuz. Ezarpen hauek fitxategi batean gordetzen dira domeinua.xml
Datu-zentroen arteko erreplikazioa - Keycloak hainbat datu-zentrotako multzo batean exekutatu nahi baduzu, gehienetan kokapen geografiko desberdinetan. Aukera honetan, datu-zentro bakoitzak bere Keycloak zerbitzarien multzoa izango du.

Artikulu honetan, bigarren aukera sakonago aztertuko dugu, hau da. kluster normala, baita datu-zentroen arteko erreplikazioaren gaiari ukitu txiki bat ere, zentzuzkoa baita Kubernetesen bi aukera hauek exekutatzeko. Zorionez, Kubernetes-ek ez du arazorik eduki hainbat poden ezarpenak (Keycloak nodoak) sinkronizatzeko. domeinu-kluster ez da oso zaila izango.

Kontuan izan ere hitza cluster artikuluaren amaiera arte elkarrekin lan egiten duten Keycloak nodo talde bati bakarrik aplikatuko zaio, ez dago Kubernetes kluster bati erreferentzia egin beharrik.

Keycloak Cluster arrunta

Keycloak modu honetan exekutatzeko, behar duzu:

konfiguratu kanpoko datu-base partekatua
instalatu karga-orekatzailea
IP multicast euskarria duen barne-sare bat edukitzea

Ez dugu kanpoko datu-basearen konfigurazioa aztertuko, ez baita artikulu honen helburua. Demagun nonbait funtzionatzen duen datu-base bat dagoela eta horrekin konexio puntu bat dugula. Datu hauek ingurune-aldagaietan gehituko ditugu, besterik gabe.

Keycloak-ek failover (HA) kluster batean nola funtzionatzen duen hobeto ulertzeko, garrantzitsua da jakitea zenbaterainokoa den Wildfly-ren clustering gaitasunen arabera.

Wildfly-k hainbat azpisistema erabiltzen ditu, horietako batzuk karga-orekatzaile gisa erabiltzen dira, beste batzuk hutsegiteko erabiltzen dira. Karga-orekatzaileak aplikazioaren erabilgarritasuna bermatzen du kluster-nodoa gainkargatuta dagoenean, eta hutsegiteak aplikazioaren erabilgarritasuna bermatzen du, nahiz eta kluster-nodo batzuk huts egin. Azpisistema horietako batzuk hauek dira:

mod_cluster: Apacherekin batera funtzionatzen du HTTP karga-orekatzaile gisa, TCP multicast-aren araberakoa da ostalariaren aurkikuntza lehenetsia. Kanpoko orekagailu batekin ordezkatu daiteke.
infinispan: banatutako cachea JGroups kanalak erabiliz garraio geruza gisa. Aukeran, HotRod protokoloa erabil dezake kanpoko Infinispan kluster batekin komunikatzeko, cachearen edukia sinkronizatzeko.
jgroups: JGroups kanaletan oinarritutako erabilgarritasun handiko zerbitzuetarako talde-elkarterako laguntza eskaintzen du. Izeneko kanalizazioek kluster bateko aplikazio-instantziak taldeetan konektatzeko aukera ematen dute, konexioak fidagarritasuna, ordenatasuna eta hutsegite-sentsibilitatea bezalako propietateak izan ditzan.

karga orekatzeko

Kubernetes kluster batean orekatzailea sarrera-kontrolatzaile gisa instalatzean, garrantzitsua da ondoko gauza hauek kontuan izatea:

Keycloak-en lanak esan nahi du autentifikazio-zerbitzariarekin HTTP bidez konektatzen den bezeroaren urruneko helbidea bezeroaren ordenagailuaren benetako IP helbidea dela. Balancer eta sarrera ezarpenek behar bezala ezarri behar dituzte HTTP goiburuak X-Forwarded-For и X-Forwarded-Proto, eta gorde jatorrizko izenburua HOST. azken bertsioa ingress-nginx (> 0.22.0) lehenespenez desgaitzen du

Bandaren aktibazioa proxy-address-forwarding ingurune-aldagai bat ezarriz PROXY_ADDRESS_FORWARDING в true Keycloak-ek proxy baten atzean exekutatzen ari dela ulertzen du.

Gaitu ere egin behar duzu saio itsaskorrak sarreran. Keycloak-ek Infinispan-en banatutako cachea erabiltzen du uneko autentifikazio-saioarekin eta erabiltzaile-saioarekin lotutako datuak gordetzeko. Cacheak jabe bakarra dira lehenespenez, hau da, saio jakin hori kluster-nodo batzuetan gordetzen da eta beste nodo batzuek urrunetik eskatu behar dute saio horretarako sarbidea behar badute.

Zehazki, dokumentazioaren aurka, cookie-izenarekin saio bat eranstea ez zitzaigun funtzionatu AUTH_SESSION_ID. Keycloak-ek birbideraketa egin du, beraz, beste cookie-izen bat aukeratzea gomendatzen dugu saio itsaskorrako.

Keycloak-ek lehen erantzun zuen ostalariaren izena ere eransten du AUTH_SESSION_ID, eta eskuragarritasun handiko bertsioko nodo bakoitzak datu-base bera erabiltzen duenez, horietako bakoitzak izan behar du transakzioak kudeatzeko nodoen ID bereizi eta bakarra. sartzea gomendatzen da JAVA_OPTS parametroak jboss.node.name и jboss.tx.node.id nodo bakoitzerako bakarra; adibidez, podaren izena ezar dezakezu. Podaren izena jartzen baduzu - ez ahaztu jboss aldagaien 23 karaktere-muga, beraz hobe StatefulSet erabiltzea, ez Deployment.

Beste rake bat: pod bat ezabatzen edo berrabiarazten bada, bere cachea galduko da. Hori kontuan izanda, merezi du cache guztien jabe kopurua gutxienez bi ezartzea, beraz, cachearen kopia bat egongo da. Irtenbidea korrika egitea da Wildfly-ren gidoia poda abiaraztean, direktorioan jarriz /opt/jboss/startup-scripts edukiontzian:

Gidoiaren edukia

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

ondoren, ezarri ingurune-aldagaiaren balioa CACHE_OWNERS eskatutakoari.

Sare pribatua ip multicast laguntzarekin

Weavenet zure CNI gisa erabiltzen ari bazara, multicast-ek berehala funtzionatuko du eta zure Keycloak nodoek elkar ikusiko dute martxan jarri bezain pronto.

Zure Kubernetes klusterrean ip multicast laguntzarik ez baduzu, JGroups konfigura dezakezu nodoak aurkitzeko beste protokolo batzuekin lan egiteko.

Lehenengo aukera erabiltzea da KUBE_DNSerabiltzen duena headless service Keycloak nodoak aurkitzeko, JGroups nodoak aurkitzeko erabiliko den zerbitzuaren izena pasatu besterik ez duzu.

Beste aukera bat metodoa erabiltzea da KUBE_PING, nodoak aurkitzeko APIarekin lan egiten duena (konfiguratu behar duzu serviceAccount eskubideekin list и get, eta, ondoren, konfiguratu lekak honekin lan egiteko serviceAccount).

JGroups-en nodoak nola bilatzen diren ingurune-aldagaiak ezarriz konfiguratzen da JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. For KUBE_PING lekak aukeratu behar dituzu galdetuz namespace и labels.

️ Multicast erabiltzen baduzu eta bi Keycloak kluster edo gehiago exekutatzen badituzu Kubernetes kluster berean (demagun bat izen-espazioan production, bigarren - staging) - Keycloak kluster bateko nodoak beste kluster batean sartu daitezke. Ziurtatu multicast helbide esklusibo bat erabiltzen duzula kluster bakoitzeko aldagaiak ezarrizjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Datu-zentroen arteko erreplikazioa

Связь

Keycloak-ek Infinispan Cache Cluster bereizi bat erabiltzen du Keycloak nodoez osatutako Keycloack klusterrak ostatatzen dituen datu-zentro bakoitzeko. Baina, aldi berean, ez dago alderik datu-zentro desberdinetako Keycloak nodoen artean.

Keycloak nodoek kanpoko Java Data Grid (Infinispan zerbitzariak) erabiltzen dute datu-zentroen artean komunikatzeko. Komunikazioa protokoloaren arabera funtzionatzen du Infinispan HotRod.

Infinispan cacheak atributuarekin konfiguratu behar dira remoteStore, datuak urruneko batean gorde ahal izateko (beste datu-zentro batean, gutxi gorabehera. itzultzailea) cacheak. JDG zerbitzarien artean infinispan kluster bereiziak daude, beraz, JDG1-en datuak gunean gordetzen dira site1 JDG2 gunean errepikatuko da site2.

Azkenik, hartzaileak JDG zerbitzariak Keycloak zerbitzariei jakinarazten die bere klusterraren berri, bezeroen konexioen bidez, hau da, HotRod protokoloaren ezaugarri bat. Keycloak nodoak aktibatuta site2 eguneratu beren Infinispan cacheak eta erabiltzailearen saio jakina eskuragarri egongo da Keycloak nodoetan site2.

Posible da, halaber, zenbait cache babeskopiak ez egitea eta Infinispan zerbitzariaren bidez datuak idazteari erabat uko egitea. Horretarako, ezarpena kendu behar duzu remote-store Infinispan cache espezifikoa (fitxategian standalone-ha.xml), ondoren zehatz batzuk replicated-cache Infinispan zerbitzariaren aldean ere ez da beharrezkoa izango.

Cacheak konfiguratzea

Keycloak-en bi cache mota daude:

Tokikoa. Oinarriaren ondoan dago, datu-basearen karga murrizteko balio du, baita erantzunen latentzia murrizteko ere. Cache mota honek erreinua, bezeroak, rolak eta erabiltzailearen metadatuak gordetzen ditu. Cache mota hau ez da errepikatzen cache hau Keycloak kluster baten parte bada ere. Cacheko sarreraren bat aldatzen bada, aldaketa-mezu bat bidaltzen da klusterreko gainerako zerbitzarietara, eta ondoren, sarrera cachetik kanpo geratzen da. ikusi deskribapena work jarraian, prozeduraren deskribapen zehatzagoa lortzeko.
Errepikagarria. Erabiltzaileen saioak, lineaz kanpoko tokenak prozesatzen ditu eta saioa hasteko hutsegiteak kontrolatzen ditu pasahitzaren phishing saiakerak eta beste eraso batzuk detektatzeko. Cache horietan gordetako datuak aldi baterakoak dira, RAMan soilik gordetzen dira, baina klusterrean erreplika daitezke.

Infinispan cacheak

Saioak - Keycloak-en kontzeptu bat, cache bereiziak, deitzen direnak authenticationSessions, erabiltzaile jakin batzuen datuak gordetzeko erabiltzen dira. Cache hauetako eskaerak arakatzaileak eta Keycloak zerbitzariak behar izaten ditu, ez aplikazioak. Hor agertzen da saio itsaskorrekiko menpekotasuna, eta horrelako cacheak ez dira errepikatu behar, nahiz eta Aktibo-Aktibo moduaren kasuan.

Ekintza-fitxak. Beste kontzeptu bat, normalean hainbat agertokitarako erabilia, adibidez, erabiltzaileak posta bidez zerbait asinkronoan egin behar duenean. Adibidez, prozeduran zehar forget password cachea actionTokens erlazionatutako token metadatuen jarraipena egiteko erabiltzen da; adibidez, tokena dagoeneko erabili da eta ezin da berriro aktibatu. Cache mota hau normalean datu-zentroen artean errepikatu behar da.

Biltegiratutako datuen cachean gordetzea eta iraungitzea datu-basetik karga kentzeko lan egiten du. Caching honek errendimendua hobetzen du, baina arazo nabari bat gehitzen du. Keycloak zerbitzari batek datuak eguneratzen baditu, gainerako zerbitzariei jakinarazi behar zaie, beren cacheak eguneratu ahal izateko. Keycloak-ek tokiko cacheak erabiltzen ditu realms, users и authorization datu-baseko datuak cachean gordetzeko.

Cache bereizi bat ere badago work, datu-zentro guztietan errepikatzen dena. Berak ez du datu-baseko daturik gordetzen, baina datu-zentroen arteko kluster-nodoetara datuak zahartzearen mezuak bidaltzeko balio du. Beste era batera esanda, datuak eguneratu bezain laster, Keycloak nodoak mezu bat bidaltzen die bere datu-zentroko beste nodo batzuei, baita beste datu-zentro batzuetako nodoei ere. Halako mezua jasotzean, nodo bakoitzak dagozkion datuak garbitzen ditu bere tokiko cacheetan.

Erabiltzaileen saioak. Cacheak izenekin sessions, clientSessions, offlineSessions и offlineClientSessions, datu-zentroen artean errepikatu ohi dira eta erabiltzailea nabigatzailean aktibo dagoen bitartean aktibo dauden erabiltzaile-saioei buruzko datuak gordetzeko balio dute. Cache hauek azken erabiltzaileen HTTP eskaerak kudeatzen dituzten aplikazioarekin lan egiten dute, beraz, saio itsaskorrekin lotuta daude eta datu-zentroen artean errepikatu behar dira.

indar gordinaren babesa. Cachea loginFailures saioa hasteko errore-datuen jarraipena egiteko erabiltzen da, hala nola, erabiltzaileak pasahitz okerra zenbat aldiz sartu duen. Cache hau erreplikatzea administratzailearen esku dago. Baina kalkulu zehatza lortzeko, merezi du datu-zentroen arteko erreplikazioa aktibatzea. Baina, bestalde, datu hauek errepikatzen ez badituzu, errendimendua hobetu ahal izango duzu, eta galdera hau sortzen bada, baliteke erreplikazioa ez aktibatzea.

Infinispan kluster bat zabaltzean, cachearen definizioak gehitu behar dituzu ezarpenen fitxategian:

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

Keycloak clusterra exekutatu aurretik Infinispan klusterra konfiguratu eta abiarazi behar duzu

Ondoren, ezarri behar duzu remoteStore Keycloak cacheetarako. Horretarako nahikoa da script bat, aurrekoaren antzera egiten dena, aldagaia ezartzeko erabiltzen dena CACHE_OWNERS, fitxategi batean gorde eta direktorio batean jarri behar duzu /opt/jboss/startup-scripts:

Gidoiaren edukia

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

Ez ahaztu instalatzea JAVA_OPTS Keycloak nodoek HotRod funtziona dezaten: remote.cache.host, remote.cache.port eta zerbitzuaren izena jboss.site.name.

Estekak eta dokumentazio osagarria

Artikulua Habrrentzat itzuli eta prestatu zuten langileek Slurm prestakuntza zentroa - intentsiboak, bideo-ikastaroak eta prestakuntza korporatiboa profesionalen eskutik (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Iturria: www.habr.com

Exekutatu Keycloak HA moduan Kubernetes-en