🥇Pagpapatakbo ng Keycloak sa HA mode sa Kubernetes

Tl; DR: magkakaroon ng paglalarawan ng Keycloak, isang open source access control system, pagsusuri ng panloob na istraktura, mga detalye ng pagsasaayos.

Panimula at Pangunahing Ideya

Sa artikulong ito, makikita natin ang mga pangunahing ideya na dapat tandaan kapag nagde-deploy ng Keycloak cluster sa itaas ng Kubernetes.

Kung gusto mong malaman ang higit pa tungkol sa Keycloak, sumangguni sa mga link sa dulo ng artikulo. Upang maging mas immersed sa pagsasanay, maaari kang mag-aral ang aming imbakan na may module na nagpapatupad ng mga pangunahing ideya ng artikulong ito (naroon ang gabay sa paglulunsad, ang artikulong ito ay magbibigay ng pangkalahatang-ideya ng device at mga setting, tinatayang tagasalin).

Ang Keycloak ay isang komprehensibong sistema na nakasulat sa Java at binuo sa ibabaw ng isang application server Langaw. Sa madaling salita, isa itong balangkas para sa awtorisasyon na nagbibigay sa mga user ng application ng federation at SSO (single sign-on) na mga kakayahan.

Inaanyayahan ka naming basahin ang opisyal website o Wikipedia para sa detalyadong pag-unawa.

Inilunsad ang Keycloak

Ang Keycloak ay nangangailangan ng dalawang patuloy na pinagmumulan ng data upang tumakbo:

Isang database na ginagamit upang mag-imbak ng naitatag na data, gaya ng impormasyon ng user
Datagrid cache, na ginagamit sa pag-cache ng data mula sa database, pati na rin sa pag-imbak ng ilang panandalian at madalas na pagbabago ng metadata, gaya ng mga session ng user. Ipinatupad Infinispan, na kadalasang mas mabilis kaysa sa database. Ngunit sa anumang kaso, ang data na na-save sa Infinispan ay panandalian - at hindi ito kailangang i-save kahit saan kapag ang cluster ay na-restart.

Gumagana ang keycloak sa apat na magkakaibang mga mode:

Normal - isa at isang proseso lamang, na na-configure sa pamamagitan ng isang file standalone.xml
Regular na kumpol (mataas na pagpipilian sa kakayahang magamit) - lahat ng mga proseso ay dapat gumamit ng parehong configuration, na dapat na i-synchronize nang manu-mano. Ang mga setting ay naka-imbak sa isang file standalone-ha.xml, bilang karagdagan kailangan mong gumawa ng nakabahaging access sa database at isang load balancer.
cluster ng domain — Ang pagsisimula ng cluster sa normal na mode ay mabilis na nagiging isang routine at nakakainip na gawain habang lumalaki ang cluster, dahil sa tuwing nagbabago ang configuration, dapat gawin ang lahat ng pagbabago sa bawat cluster node. Niresolba ng domain mode of operation ang isyung ito sa pamamagitan ng pag-set up ng ilang nakabahaging lokasyon ng storage at pag-publish ng configuration. Ang mga setting na ito ay naka-imbak sa file domain.xml
Pagtitiklop sa pagitan ng mga sentro ng data — kung gusto mong patakbuhin ang Keycloak sa isang kumpol ng ilang mga data center, kadalasan sa iba't ibang heograpikal na lokasyon. Sa opsyong ito, ang bawat data center ay magkakaroon ng sarili nitong kumpol ng mga server ng Keycloak.

Sa artikulong ito ay isasaalang-alang namin nang detalyado ang pangalawang pagpipilian, iyon ay regular na kumpol, at hihipo din kami ng kaunti sa paksa ng pagtitiklop sa pagitan ng mga data center, dahil makatuwirang patakbuhin ang dalawang opsyong ito sa Kubernetes. Sa kabutihang palad, sa Kubernetes walang problema sa pag-synchronize ng mga setting ng ilang pods (Keycloak node), kaya cluster ng domain Hindi ito magiging napakahirap gawin.

Pakitandaan din na ang salita kumpol para sa natitirang bahagi ng artikulo ay malalapat lamang sa isang pangkat ng mga Keycloak node na nagtutulungan, hindi na kailangang sumangguni sa isang Kubernetes cluster.

Regular na Keycloak cluster

Upang patakbuhin ang Keycloak sa mode na ito kailangan mo:

i-configure ang panlabas na nakabahaging database
i-install ang load balancer
magkaroon ng panloob na network na may suporta sa IP multicast

Hindi namin tatalakayin ang pag-set up ng isang panlabas na database, dahil hindi ito ang layunin ng artikulong ito. Ipagpalagay natin na mayroong gumaganang database sa isang lugar - at mayroon tayong punto ng koneksyon dito. Idaragdag lang namin ang data na ito sa mga variable ng kapaligiran.

Upang mas maunawaan kung paano gumagana ang Keycloak sa isang failover (HA) cluster, mahalagang malaman kung gaano ito nakadepende sa mga kakayahan ng clustering ng Wildfly.

Gumagamit ang Wildfly ng ilang subsystem, ang ilan sa mga ito ay ginagamit bilang load balancer, ang ilan ay para sa fault tolerance. Tinitiyak ng load balancer ang availability ng application kapag na-overload ang isang cluster node, at tinitiyak ng fault tolerance ang availability ng application kahit na nabigo ang ilang cluster node. Ilan sa mga subsystem na ito:

mod_cluster: Gumagana kasabay ng Apache bilang isang HTTP load balancer, depende sa TCP multicast upang mahanap ang mga host bilang default. Maaaring mapalitan ng isang panlabas na balanse.
infinispan: Isang distributed cache gamit ang mga JGroups channel bilang transport layer. Bukod pa rito, maaari nitong gamitin ang HotRod protocol upang makipag-ugnayan sa isang panlabas na cluster ng Infinispan upang i-synchronize ang mga nilalaman ng cache.
jgroups: Nagbibigay ng suporta sa komunikasyon ng grupo para sa mga serbisyong lubos na magagamit batay sa mga channel ng JGroups. Ang mga pinangalanang pipe ay nagbibigay-daan sa mga instance ng application sa isang cluster na makonekta sa mga grupo upang ang komunikasyon ay may mga katangian tulad ng pagiging maaasahan, kaayusan, at pagiging sensitibo sa mga pagkabigo.

Load Balancer

Kapag nag-i-install ng balancer bilang isang ingress controller sa isang Kubernetes cluster, mahalagang tandaan ang mga sumusunod na bagay:

Ipinapalagay ng Keycloak na ang malayong address ng kliyente na kumokonekta sa pamamagitan ng HTTP sa server ng pagpapatunay ay ang tunay na IP address ng computer ng kliyente. Ang mga setting ng balanse at pagpasok ay dapat magtakda nang tama ng mga header ng HTTP X-Forwarded-For и X-Forwarded-Proto, at i-save din ang orihinal na pamagat HOST. Pinakabagong bersyon ingress-nginx (>0.22.0) hindi pinapagana ito bilang default

Pag-activate ng bandila proxy-address-forwarding sa pamamagitan ng pagtatakda ng variable ng kapaligiran PROXY_ADDRESS_FORWARDING в true nagbibigay sa Keycloak ng pag-unawa na ito ay gumagana sa likod ng isang proxy.

Kailangan mo ring paganahin malagkit na mga sesyon sa pagpasok. Gumagamit ang Keycloak ng nakabahaging Infinispan cache upang mag-imbak ng data na nauugnay sa kasalukuyang session ng pagpapatotoo at session ng user. Gumagana ang mga cache sa isang may-ari bilang default, sa madaling salita, ang partikular na session na iyon ay naka-imbak sa ilang node sa cluster, at dapat itong i-query ng ibang mga node nang malayuan kung kailangan nila ng access sa session na iyon.

Sa partikular, salungat sa dokumentasyon, hindi gumana para sa amin ang pag-attach ng session na may pangalang cookie AUTH_SESSION_ID. May redirect loop ang Keycloak, kaya inirerekomenda namin ang pagpili ng ibang pangalan ng cookie para sa malagkit na session.

Ang Keycloak ay nakakabit din sa pangalan ng node na unang tumugon sa AUTH_SESSION_ID, at dahil ang bawat node sa pinaka available na bersyon ay gumagamit ng parehong database, bawat isa sa kanila dapat meron isang hiwalay at natatanging node identifier para sa pamamahala ng mga transaksyon. Inirerekomenda na ilagay sa JAVA_OPTS parameter jboss.node.name и jboss.tx.node.id natatangi para sa bawat node - maaari mong, halimbawa, ilagay ang pangalan ng pod. Kung maglalagay ka ng pod name, huwag kalimutan ang tungkol sa 23 na limitasyon ng character para sa mga variable ng jboss, kaya mas mabuting gumamit ng StatefulSet kaysa sa Deployment.

Isa pang rake - kung ang pod ay tinanggal o na-restart, ang cache nito ay nawala. Isinasaalang-alang ito, sulit na itakda ang bilang ng mga may-ari ng cache para sa lahat ng mga cache sa hindi bababa sa dalawa, upang ang isang kopya ng cache ay mananatili. Ang solusyon ay tumakbo script para sa Wildfly kapag sinimulan ang pod, inilalagay ito sa direktoryo /opt/jboss/startup-scripts sa lalagyan:

Mga Nilalaman ng Iskrip

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

pagkatapos ay itakda ang halaga ng variable ng kapaligiran CACHE_OWNERS sa kinakailangan.

Pribadong network na may suporta sa multicast ng IP

Kung gagamitin mo ang Weavenet bilang isang CNI, gagana kaagad ang multicast - at ang iyong mga Keycloak node ay magkikita-kita sa sandaling mailunsad ang mga ito.

Kung wala kang suporta sa ip multicast sa iyong Kubernetes cluster, maaari mong i-configure ang JGroups upang gumana sa iba pang mga protocol upang makahanap ng mga node.

Ang unang pagpipilian ay ang paggamit KUBE_DNSna gumagamit headless service para mahanap ang mga Keycloak node, ipapasa mo lang sa JGroups ang pangalan ng serbisyo na gagamitin para mahanap ang mga node.

Ang isa pang pagpipilian ay ang paggamit ng pamamaraan KUBE_PING, na gumagana sa API upang maghanap ng mga node (kailangan mong i-configure serviceAccount may karapatan list и get, at pagkatapos ay i-configure ang mga pod upang gumana dito serviceAccount).

Ang paraan ng paghahanap ng mga node ng JGroups ay na-configure sa pamamagitan ng pagtatakda ng mga variable ng kapaligiran JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Para sa KUBE_PING kailangan mong pumili ng mga pod sa pamamagitan ng pagtatanong namespace и labels.

️ Kung gumagamit ka ng multicast at nagpapatakbo ng dalawa o higit pang Keycloak cluster sa isang Kubernetes cluster (sabihin natin ang isa sa namespace production, ang ikalawa - staging) - ang mga node ng isang Keycloak cluster ay maaaring sumali sa isa pang cluster. Tiyaking gumamit ng natatanging multicast address para sa bawat cluster sa pamamagitan ng pagtatakda ng mga variablejboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Pagtitiklop sa pagitan ng mga sentro ng data

Связь

Gumagamit ang Keycloak ng maraming hiwalay na Infinispan cache cluster para sa bawat data center kung saan matatagpuan ang mga Keycloack cluster na binubuo ng mga Keycloak node. Ngunit walang pagkakaiba sa pagitan ng mga node ng Keycloak sa iba't ibang mga sentro ng data.

Gumagamit ang mga keycloak node ng panlabas na Java Data Grid (mga server ng Infinispan) para sa komunikasyon sa pagitan ng mga data center. Gumagana ang komunikasyon ayon sa protocol Infinispan HotRod.

Ang mga cache ng Infinispan ay dapat na i-configure gamit ang katangian remoteStore, upang ang data ay maiimbak nang malayuan (sa isa pang data center, tinatayang tagasalin) mga cache. Mayroong hiwalay na infinispan cluster sa mga JDG server, upang ang data na nakaimbak sa JDG1 sa site site1 ay gagawing JDG2 sa site site2.

At sa wakas, inaabisuhan ng tumatanggap na JDG server ang mga Keycloak server ng cluster nito sa pamamagitan ng mga koneksyon ng kliyente, na isang tampok ng HotRod protocol. Naka-on ang mga node ng keycloak site2 i-update ang kanilang mga Infinispan cache at ang partikular na session ng user ay magiging available din sa mga Keycloak node sa site2.

Para sa ilang mga cache, posible ring hindi gumawa ng mga backup at maiwasan ang pagsusulat ng data sa pamamagitan ng Infinispan server nang buo. Upang gawin ito kailangan mong alisin ang setting remote-store tiyak na Infinispan cache (sa file standalone-ha.xml), pagkatapos ay ilang partikular replicated-cache hindi na rin kakailanganin sa panig ng server ng Infinispan.

Pagse-set up ng mga cache

Mayroong dalawang uri ng mga cache sa Keycloak:

Lokal. Ito ay matatagpuan sa tabi ng database at nagsisilbing bawasan ang pagkarga sa database, pati na rin upang bawasan ang latency ng pagtugon. Ang ganitong uri ng cache ay nag-iimbak ng realm, mga kliyente, mga tungkulin, at metadata ng user. Ang ganitong uri ng cache ay hindi ginagaya, kahit na ang cache ay bahagi ng isang Keycloak cluster. Kung ang isang entry sa cache ay nagbago, isang mensahe tungkol sa pagbabago ay ipapadala sa natitirang mga server sa cluster, pagkatapos kung saan ang entry ay hindi kasama sa cache. Tingnan ang paglalarawan work Tingnan sa ibaba para sa isang mas detalyadong paglalarawan ng pamamaraan.
Kinulit. Pinoproseso ang mga session ng user, mga offline na token, at sinusubaybayan din ang mga error sa pag-log in upang makita ang mga pagtatangka sa phishing ng password at iba pang mga pag-atake. Ang data na nakaimbak sa mga cache na ito ay pansamantala, na nakaimbak lamang sa RAM, ngunit maaaring kopyahin sa buong cluster.

Mga cache ng Infinispan

Mga session - isang konsepto sa Keycloak, hiwalay na mga cache na tinatawag authenticationSessions, ay ginagamit upang mag-imbak ng data ng mga partikular na user. Ang mga kahilingan mula sa mga cache na ito ay karaniwang kailangan ng browser at Keycloak server, hindi ng mga application. Dito pumapasok ang pag-asa sa mga malagkit na session, at ang mga naturang cache mismo ay hindi kailangang kopyahin, kahit na sa kaso ng Active-Active mode.

Mga Token ng Aksyon. Isa pang konsepto, kadalasang ginagamit para sa iba't ibang mga sitwasyon kapag, halimbawa, ang user ay dapat gumawa ng isang bagay nang asynchronous sa pamamagitan ng koreo. Halimbawa, sa panahon ng pamamaraan forget password cache actionTokens ginagamit upang subaybayan ang metadata ng mga nauugnay na token - halimbawa, ang isang token ay nagamit na at hindi na muling maisaaktibo. Ang ganitong uri ng cache ay karaniwang kailangang kopyahin sa pagitan ng mga data center.

Pag-cache at pagtanda ng nakaimbak na data gumagana upang mapawi ang pagkarga sa database. Ang ganitong uri ng pag-cache ay nagpapabuti sa pagganap, ngunit nagdaragdag ng isang malinaw na problema. Kung ang isang Keycloak server ay nag-a-update ng data, ang iba pang mga server ay dapat na maabisuhan upang ma-update nila ang data sa kanilang mga cache. Gumagamit ang Keycloak ng mga lokal na cache realms, users и authorization para sa pag-cache ng data mula sa database.

Mayroon ding hiwalay na cache work, na ginagaya sa lahat ng data center. Ito mismo ay hindi nag-iimbak ng anumang data mula sa database, ngunit nagsisilbing magpadala ng mga mensahe tungkol sa pagtanda ng data sa mga cluster node sa pagitan ng mga data center. Sa madaling salita, sa sandaling ma-update ang data, ang Keycloak node ay nagpapadala ng mensahe sa iba pang mga node sa data center nito, pati na rin sa mga node sa iba pang mga data center. Pagkatapos matanggap ang ganoong mensahe, ki-clear ng bawat node ang kaukulang data sa mga lokal na cache nito.

Mga session ng user. Mga cache na may mga pangalan sessions, clientSessions, offlineSessions и offlineClientSessions, ay karaniwang kinokopya sa pagitan ng mga data center at nagsisilbing mag-imbak ng data tungkol sa mga session ng user na aktibo habang aktibo ang user sa browser. Gumagana ang mga cache na ito sa application na nagpoproseso ng mga kahilingan sa HTTP mula sa mga end user, kaya nauugnay ang mga ito sa mga malagkit na session at dapat na gayahin sa pagitan ng mga data center.

Proteksyon ng brute force. Cache loginFailures Ginagamit upang subaybayan ang data ng error sa pag-log in, gaya ng kung ilang beses nagpasok ang isang user ng maling password. Ang pagkopya ng cache na ito ay responsibilidad ng administrator. Ngunit para sa isang tumpak na pagkalkula, ito ay nagkakahalaga ng pag-activate ng pagtitiklop sa pagitan ng mga sentro ng data. Ngunit sa kabilang banda, kung hindi mo gagayahin ang data na ito, mapapabuti mo ang pagganap, at kung lumitaw ang isyung ito, maaaring hindi ma-activate ang pagtitiklop.

Kapag naglulunsad ng isang Infinispan cluster, kailangan mong magdagdag ng mga kahulugan ng cache sa file ng mga setting:

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

Dapat mong i-configure at simulan ang Infinispan cluster bago simulan ang Keycloak cluster

Pagkatapos ay kailangan mong i-configure remoteStore para sa mga cache ng Keycloak. Upang gawin ito, sapat na ang isang script, na ginagawa nang katulad ng nauna, na ginagamit upang itakda ang variable CACHE_OWNERS, kailangan mong i-save ito sa isang file at ilagay ito sa isang direktoryo /opt/jboss/startup-scripts:

Mga Nilalaman ng Iskrip

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

Huwag kalimutang i-install JAVA_OPTS para sa mga Keycloak node na magpatakbo ng HotRod: remote.cache.host, remote.cache.port at pangalan ng serbisyo jboss.site.name.

Mga link at karagdagang dokumentasyon

Ang artikulo ay isinalin at inihanda para sa Habr ng mga empleyado Slurm training center — masinsinang kurso, video course at corporate na pagsasanay mula sa mga nagsasanay na espesyalista (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Pinagmulan: www.habr.com

Patakbuhin ang Keycloak sa HA mode sa Kubernetes