🥇Keycloak paleidimas HA režimu Kubernetes

Lt; DR: bus atviro kodo prieigos kontrolės sistemos Keycloak aprašymas, vidinės struktūros analizė, konfigūracijos detalės.

Įvadas ir pagrindinės idėjos

Šiame straipsnyje apžvelgsime pagrindines idėjas, kurių reikia nepamiršti diegiant „Keycloak“ klasterį „Kubernetes“ viršuje.

Jei norite sužinoti daugiau apie „Keycloak“, žr. nuorodas straipsnio pabaigoje. Norėdami labiau pasinerti į praktiką, galite mokytis mūsų saugykla su moduliu, kuris įgyvendina pagrindines šio straipsnio idėjas (paleidimo vadovas yra, šiame straipsnyje bus pateikta įrenginio ir nustatymų apžvalga, apytiksliai vertėjas).

„Keycloak“ yra išsami sistema, parašyta „Java“ ir sukurta programų serverio viršuje Laukinė muselė. Trumpai tariant, tai yra autorizacijos sistema, suteikianti programų naudotojų susiejimo ir SSO (vienkartinio prisijungimo) galimybes.

Kviečiame perskaityti oficialų Interneto svetainė arba Vikipedija detalesniam supratimui.

„Keycloak“ paleidimas

Norint paleisti „Keycloak“, reikia dviejų nuolatinių duomenų šaltinių:

Duomenų bazė, naudojama nustatytiems duomenims, pvz., vartotojo informacijai, saugoti
Datagrid talpykla, kuri naudojama duomenims iš duomenų bazės talpinti, taip pat kai kuriems trumpalaikiams ir dažnai besikeičiantiems metaduomenims, pvz., vartotojų seansams, saugoti. Įgyvendinta Infinispan, kuris paprastai yra žymiai greitesnis nei duomenų bazė. Bet bet kuriuo atveju „Infinispan“ išsaugoti duomenys yra trumpalaikiai – ir jų niekur nereikia išsaugoti, kai klasteris paleidžiamas iš naujo.

Keycloak veikia keturiais skirtingais režimais:

Normalus - vienas ir vienintelis procesas, sukonfigūruotas naudojant failą standalone.xml
Įprastas klasteris (aukšto pasiekiamumo parinktis) – visi procesai turi naudoti tą pačią konfigūraciją, kuri turi būti sinchronizuojama rankiniu būdu. Nustatymai saugomi faile standalone-ha.xml, be to, turite sudaryti bendrą prieigą prie duomenų bazės ir apkrovos balansavimo priemonės.
Domenų klasteris — klasterio paleidimas įprastu režimu greitai tampa įprasta ir nuobodžia užduotimi, nes klasteris auga kiekvieną kartą, kai keičiasi konfigūracija, visi pakeitimai turi būti atlikti kiekviename klasterio mazge. Domeno veikimo režimas išsprendžia šią problemą nustatydamas bendrinamą saugojimo vietą ir paskelbdamas konfigūraciją. Šie nustatymai saugomi faile domenas.xml
Replikacija tarp duomenų centrų — jei norite paleisti Keycloak kelių duomenų centrų grupėje, dažniausiai skirtingose geografinėse vietose. Pasirinkus šią parinktį, kiekvienas duomenų centras turės savo Keycloak serverių grupę.

Šiame straipsnyje mes išsamiai apsvarstysime antrąjį variantą, tai yra reguliarus klasteris, taip pat šiek tiek paliesime replikacijos tarp duomenų centrų temą, nes prasminga šias dvi parinktis paleisti Kubernetes. Laimei, „Kubernetes“ nėra problemų sinchronizuoti kelių blokų (Keycloak mazgų) nustatymus, todėl domenų klasteris Tai padaryti nebus labai sunku.

Taip pat atkreipkite dėmesį, kad žodis klasteris Likusi straipsnio dalis bus taikoma tik kartu veikiančių „Keycloak“ mazgų grupei, nereikia nurodyti „Kubernetes“ klasterio.

Įprasta „Keycloak“ grupė

Norėdami paleisti Keycloak šiuo režimu, jums reikia:

konfigūruoti išorinę bendrinamą duomenų bazę
įdiekite apkrovos balansavimo įrenginį
turėti vidinį tinklą su IP multicast palaikymu

Nekalbėsime apie išorinės duomenų bazės sukūrimą, nes tai nėra šio straipsnio tikslas. Tarkime, kad kažkur yra veikianti duomenų bazė – ir mes turime prie jos prisijungimo tašką. Šiuos duomenis tiesiog pridėsime prie aplinkos kintamųjų.

Norint geriau suprasti, kaip „Keycloak“ veikia perjungimo (HA) klasteryje, svarbu žinoti, kiek viskas priklauso nuo „Wildfly“ grupavimo galimybių.

„Wildfly“ naudoja keletą posistemių, kai kurios iš jų naudojamos kaip apkrovos balansavimo priemonė, kai kurios – kaip gedimų tolerancija. Apkrovos balansavimo priemonė užtikrina programos prieinamumą, kai klasterio mazgas yra perkrautas, o atsparumas gedimams užtikrina programos pasiekiamumą, net jei kai kurie klasterio mazgai sugenda. Kai kurios iš šių posistemių:

mod_cluster: Veikia kartu su Apache kaip HTTP apkrovos balansavimo priemonė, priklauso nuo TCP daugialypės siuntimo, kad pagal numatytuosius nustatymus būtų galima rasti pagrindinius kompiuterius. Galima pakeisti išoriniu balansuotoju.
infinispan: paskirstyta talpykla, naudojanti JGroups kanalus kaip transportavimo sluoksnį. Be to, jis gali naudoti HotRod protokolą bendrauti su išorine Infinispan grupe ir sinchronizuoti talpyklos turinį.
jgroups: Teikia grupinio ryšio palaikymą labai prieinamoms paslaugoms, pagrįstoms JGroups kanalais. Vardiniai vamzdžiai leidžia grupės taikomąsias programas sujungti į grupes, kad ryšys turėtų tokias savybes kaip patikimumas, tvarkingumas ir jautrumas gedimams.

Apkrovos balansavimo priemonė

Diegiant balansytuvą kaip įėjimo valdiklį Kubernetes klasteryje, svarbu nepamiršti šių dalykų:

„Keycloak“ daro prielaidą, kad nuotolinis kliento, prisijungiančio per HTTP prie autentifikavimo serverio, adresas yra tikrasis kliento kompiuterio IP adresas. Balansavimo ir įėjimo nustatymai turėtų teisingai nustatyti HTTP antraštes X-Forwarded-For и X-Forwarded-Proto, taip pat išsaugokite originalų pavadinimą HOST. Naujausia versija ingress-nginx (>0.22.0) išjungia tai pagal numatytuosius nustatymus

Vėliavos aktyvinimas proxy-address-forwarding nustatydami aplinkos kintamąjį PROXY_ADDRESS_FORWARDING в true leidžia „Keycloak“ suprasti, kad ji veikia už tarpinio serverio.

Taip pat reikia įjungti lipnios sesijos patekus. „Keycloak“ naudoja paskirstytą „Infinispan“ talpyklą, kad saugotų duomenis, susijusius su dabartine autentifikavimo sesija ir vartotojo sesija. Talpyklos pagal numatytuosius nustatymus veikia su vienu savininku, kitaip tariant, ta konkreti sesija yra saugoma tam tikrame klasterio mazge, o kiti mazgai turi nuotoliniu būdu užklausti, jei jiems reikia prieigos prie tos sesijos.

Tiksliau, priešingai nei nurodyta dokumentacijoje, seanso pridėjimas su pavadinimo slapuku mums nepasiteisino AUTH_SESSION_ID. „Keycloak“ turi peradresavimo kilpą, todėl rekomenduojame pasirinkti kitą slapuko pavadinimą, skirtą priklijuoti seansui.

„Keycloak“ taip pat prideda mazgo, į kurį atsakė pirmasis, pavadinimą AUTH_SESSION_ID, ir kadangi kiekvienas labai prieinamos versijos mazgas naudoja tą pačią duomenų bazę, kiekvienas iš jų turėtum turėti atskiras ir unikalus mazgo identifikatorius, skirtas operacijoms valdyti. Rekomenduojama įdėti JAVA_OPTS parametrai jboss.node.name и jboss.tx.node.id unikalus kiekvienam mazgui – galite, pavyzdžiui, nurodyti ankšties pavadinimą. Jei įdedate pod pavadinimą, nepamirškite apie 23 simbolių apribojimą jboss kintamiesiems, todėl geriau naudoti StatefulSet, o ne diegimą.

Dar vienas grėblys – jei podas ištrintas arba paleidžiamas iš naujo, jo talpykla prarandama. Atsižvelgiant į tai, visų talpyklų talpyklos savininkų skaičių verta nustatyti bent iki dviejų, kad išliktų talpyklos kopija. Sprendimas yra bėgti „Wildfly“ scenarijus paleidžiant podą, įdėjus jį į katalogą /opt/jboss/startup-scripts konteineryje:

Scenarijaus turinys

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

tada nustatykite aplinkos kintamojo reikšmę CACHE_OWNERS į reikalingą.

Privatus tinklas su IP multicast palaikymu

Jei naudosite „Weavenet“ kaip CNI, daugialypė transliacija veiks iš karto – ir jūsų „Keycloak“ mazgai matys vienas kitą, kai tik bus paleisti.

Jei neturite IP multicast palaikymo savo Kubernetes klasteryje, galite sukonfigūruoti JGroups dirbti su kitais protokolais ir rasti mazgus.

Pirmasis variantas yra naudoti KUBE_DNSkuri naudoja headless service norėdami rasti „Keycloak“ mazgus, tiesiog perduodate JGroups paslaugos, kuri bus naudojama mazgams rasti, pavadinimą.

Kitas variantas yra naudoti metodą KUBE_PING, kuri veikia su API ieškant mazgų (reikia sukonfigūruoti serviceAccount su teisėmis list и get, tada sukonfigūruokite blokus, kad jie veiktų su tuo serviceAccount).

Tai, kaip JGroups randa mazgus, sukonfigūruojamas nustatant aplinkos kintamuosius JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Už KUBE_PING ankštis reikia pasirinkti klausiant namespace и labels.

️ Jei naudojate daugialypės terpės siuntimą ir paleidžiate dvi ar daugiau „Keycloak“ grupių viename „Kubernetes“ klasteryje (tarkime, vieną vardų erdvėje production, Antras - staging) – vienos Keycloak klasterio mazgai gali prisijungti prie kitos grupės. Nustatydami kintamuosius būtinai naudokite unikalų daugialypės terpės siuntimo adresą kiekvienai klasteriuijboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Replikacija tarp duomenų centrų

Связь

„Keycloak“ kiekviename duomenų centre, kuriame yra „Keycloak“ mazgų sudarytos „Keycloak“ grupės, naudoja kelias atskiras „Infinispan“ talpyklos grupes. Tačiau skirtinguose duomenų centruose „Keycloak“ mazgai nesiskiria.

„Keycloak“ mazgai naudoja išorinį „Java Data Grid“ („Infinispan“ serverius) ryšiui tarp duomenų centrų. Ryšys veikia pagal protokolą Infinispan HotRod.

Infinispan talpyklos turi būti sukonfigūruotos naudojant atributą remoteStore, kad duomenis būtų galima saugoti nuotoliniu būdu (kitame duomenų centre, apytiksliai vertėjas) talpyklos. Tarp JDG serverių yra atskiri infinispan klasteriai, todėl JDG1 vietoje saugomi duomenys site1 bus pakartotas į JDG2 vietoje site2.

Ir galiausiai, priimantis JDG serveris praneša Keycloak serveriams apie savo klasterį per kliento ryšius, o tai yra HotRod protokolo funkcija. Keycloak mazgai įjungti site2 atnaujinkite savo Infinispan talpyklas ir konkreti vartotojo sesija taps pasiekiama ir Keycloak mazguose site2.

Kai kurių talpyklų atveju taip pat galima nedaryti atsarginių kopijų ir visiškai nerašyti duomenų per „Infinispan“ serverį. Norėdami tai padaryti, turite pašalinti nustatymą remote-store specifinė Infinispan talpykla (faile standalone-ha.xml), po to kai kurie konkretūs replicated-cache taip pat nebereikės Infinispan serverio pusėje.

Talpyklų nustatymas

„Keycloak“ talpyklos yra dviejų tipų:

Vietinis. Jis yra šalia duomenų bazės ir padeda sumažinti duomenų bazės apkrovą, taip pat sumažinti atsakymo delsą. Šio tipo talpykla saugo sritį, klientus, vaidmenis ir vartotojo metaduomenis. Šio tipo talpykla nėra atkartojama, net jei talpykla yra „Keycloak“ klasterio dalis. Jei pasikeičia įrašas talpykloje, likusiems klasterio serveriams siunčiamas pranešimas apie pakeitimą, po kurio įrašas pašalinamas iš talpyklos. Žr. aprašymą work Žemiau rasite išsamesnį procedūros aprašymą.
Pakartotas. Apdoroja vartotojų seansus, neprisijungus naudojamus prieigos raktus ir taip pat stebi prisijungimo klaidas, kad aptiktų slaptažodžių sukčiavimo bandymus ir kitas atakas. Šiose talpyklose saugomi duomenys yra laikini, saugomi tik RAM, bet gali būti atkartojami visame klasteryje.

Infinispan talpyklos

Seansai - Keycloak koncepcija, vadinama atskiromis talpyklomis authenticationSessions, naudojami konkrečių vartotojų duomenims saugoti. Užklausų iš šių talpyklų paprastai reikia naršyklei ir „Keycloak“ serveriams, o ne programoms. Čia atsiranda priklausomybė nuo prilipusių seansų ir tokių talpyklų nereikia atkartoti net ir aktyvaus aktyvaus režimo atveju.

Veiksmo žetonai. Kita sąvoka, dažniausiai naudojama įvairiems scenarijams, kai, pavyzdžiui, vartotojas turi ką nors daryti asinchroniškai paštu. Pavyzdžiui, procedūros metu forget password talpykla actionTokens naudojamas susijusių žetonų metaduomenims sekti – pavyzdžiui, prieigos raktas jau buvo panaudotas ir jo vėl suaktyvinti negalima. Šio tipo talpyklą paprastai reikia kopijuoti tarp duomenų centrų.

Saugomų duomenų kaupimas talpykloje ir senėjimas padeda sumažinti duomenų bazės apkrovą. Toks kaupimas talpykloje pagerina našumą, tačiau prideda akivaizdžią problemą. Jei vienas Keycloak serveris atnaujina duomenis, apie tai turi būti pranešta kitiems serveriams, kad jie galėtų atnaujinti duomenis savo talpyklose. „Keycloak“ naudoja vietines talpyklas realms, users и authorization duomenų kaupimui talpykloje iš duomenų bazės.

Taip pat yra atskira talpykla work, kuri atkartojama visuose duomenų centruose. Ji pati nesaugo jokių duomenų iš duomenų bazės, bet skirta siųsti pranešimus apie duomenų senėjimą į klasterio mazgus tarp duomenų centrų. Kitaip tariant, kai tik duomenys atnaujinami, Keycloak mazgas siunčia pranešimą kitiems savo duomenų centro mazgams, taip pat mazgams kituose duomenų centruose. Gavęs tokį pranešimą, kiekvienas mazgas išvalo atitinkamus duomenis savo vietinėse talpyklose.

Vartotojų sesijos. Talpyklos su pavadinimais sessions, clientSessions, offlineSessions и offlineClientSessions, paprastai yra dauginami duomenų centruose ir naudojami duomenims apie naudotojo seansus, kurie yra aktyvūs, kol vartotojas yra aktyvus naršyklėje, saugoti. Šios talpyklos veikia su programa, apdorojančia HTTP užklausas iš galutinių vartotojų, todėl jos yra susietos su fiksuotais seansais ir turi būti pakartojamos duomenų centruose.

Brutalios jėgos apsauga. Talpykla loginFailures Naudojama sekti prisijungimo klaidų duomenis, pvz., kiek kartų vartotojas įvedė neteisingą slaptažodį. Šios talpyklos replikavimas yra administratorius. Tačiau norint atlikti tikslų skaičiavimą, verta suaktyvinti replikaciją tarp duomenų centrų. Tačiau, kita vertus, jei nekopijuosite šių duomenų, pagerinsite našumą, o iškilus šiai problemai replikacija gali būti nesuaktyvinta.

Išleisdami „Infinispan“ klasterį, prie nustatymų failo turite pridėti talpyklos apibrėžimus:

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

Prieš paleisdami „Keycloak“ grupę, turite sukonfigūruoti ir paleisti „Infinispan“ grupę

Tada reikia sukonfigūruoti remoteStore „Keycloak“ talpykloms. Tam pakanka scenarijaus, kuris daromas panašiai kaip ir ankstesnis, kuris naudojamas kintamajam nustatyti CACHE_OWNERS, turite jį įrašyti į failą ir įdėti į katalogą /opt/jboss/startup-scripts:

Scenarijaus turinys

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

Nepamirškite įdiegti JAVA_OPTS „Keycloak“ mazgams paleisti „HotRod“: remote.cache.host, remote.cache.port ir paslaugos pavadinimas jboss.site.name.

Nuorodos ir papildomi dokumentai

Straipsnį Habr išvertė ir parengė darbuotojai Slurm mokymo centras - intensyvūs kursai, vaizdo kursai ir praktikuojančių specialistų mokymai (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Šaltinis: www.habr.com

„Keycloak“ paleidimas HA režimu „Kubernetes“.