Kubernetes-də HA rejimində Keycloak-ı işə salın

TL; DR: Keycloak-ın təsviri, açıq mənbəli girişə nəzarət sistemi, daxili cihazın təhlili, konfiqurasiya təfərrüatları olacaq.

Giriş və əsas fikirlər

Bu yazıda Kubernetes-in üstündə Keycloak klasterini yerləşdirərkən yadda saxlamalı olduğumuz əsas fikirləri görəcəyik.

Keycloak haqqında daha çox bilmək istəyirsinizsə, məqalənin sonundakı linklərə müraciət edin. Özünüzü praktikaya daha dərindən batırmaq üçün öyrənə bilərsiniz anbarımız bu məqalənin əsas ideyalarını həyata keçirən bir modul ilə (başlatma təlimatı var, bu məqalədə cihaz və parametrlərə ümumi baxış olacaq, təqribən. tərcüməçi).

Keycloak Java-da yazılmış və proqram serverinin üstündə qurulmuş mürəkkəb sistemdir. Vəhşi ağcaqanad. Qısacası, bu, tətbiq istifadəçilərinə federasiya və SSO (tək giriş) imkanı verən avtorizasiya çərçivəsidir.

Sizi rəsmi oxumağa dəvət edirik website və ya Vikipediya ətraflı başa düşmək üçün.

Keycloak-ı işə salın

Keycloak işləmək üçün iki davamlı məlumat mənbəyinə ehtiyac duyur:

• İstifadəçilər haqqında məlumatlar kimi davamlı məlumatları saxlamaq üçün istifadə edilən verilənlər bazası
• Datagrid keşi verilənlər bazasından verilənlərin keşlənməsi, həmçinin istifadəçi seansları kimi bəzi qısamüddətli və tez-tez dəyişdirilən metaməlumatların saxlanması üçün istifadə olunur. Buraxıldı Sonsuzluq, bu adətən verilənlər bazasından əhəmiyyətli dərəcədə sürətlidir. Ancaq istənilən halda, Infinispan-da saxlanılan məlumatlar efemerdir - və klaster yenidən işə salındıqda onu haradasa saxlamaq lazım deyil.

Keycloak dörd müxtəlif rejimdə işləyir:

• adi - fayl vasitəsilə konfiqurasiya edilmiş bir və yalnız bir proses standalone.xml
• müntəzəm klaster (yüksək mövcud seçim) - Bütün proseslər əl ilə sinxronlaşdırılmalı olan eyni konfiqurasiyadan istifadə etməlidir. Parametrlər faylda saxlanılır bağımsız-ha.xml, əlavə olaraq, verilənlər bazasına və yük balanslaşdırıcısına ortaq giriş əldə etməlisiniz.
• Domen klasteri - klasterin normal rejimdə işə salınması klaster böyüdükcə tez bir zamanda rutin və darıxdırıcı bir işə çevrilir, çünki konfiqurasiyanı hər dəfə dəyişdirəndə klasterin hər nodeunda bütün dəyişiklikləri etməlisiniz. Domen iş rejimi bəzi paylaşılan yaddaş qurmaq və konfiqurasiyanı dərc etməklə bu problemi həll edir. Bu parametrlər faylda saxlanılır domain.xml
• Məlumat mərkəzləri arasında təkrarlama - Keycloak-ı bir neçə məlumat mərkəzinin çoxluğunda, çox vaxt müxtəlif coğrafi yerlərdə işə salmaq istəsəniz. Bu seçimdə hər bir məlumat mərkəzinin Keycloak serverlərinin öz klasteri olacaq.

Bu yazıda biz ikinci variantı daha yaxından nəzərdən keçirəcəyik, yəni. müntəzəm klaster, həmçinin məlumat mərkəzləri arasında replikasiya mövzusuna bir az toxunun, çünki bu iki variantı Kubernetes-də işə salmağın mənası var. Xoşbəxtlikdən Kubernetes-in çoxsaylı podların (Keycloak qovşaqlarının) parametrlərinin sinxronizasiyası ilə bağlı problemi yoxdur. domen klasteri etmək çox da çətin olmayacaq.

Bu sözü də qeyd edin çoxluq məqalənin sonuna qədər yalnız birlikdə işləyən Keycloak qovşaqları qrupuna aid olacaq, Kubernetes çoxluğuna istinad etməyə ehtiyac yoxdur.

Adi Keycloak Cluster

Keycloak-ı bu rejimdə işə salmaq üçün sizə lazımdır:

• xarici paylaşılan verilənlər bazası qurun
• yük balanslaşdırıcısını quraşdırın
• ip multicast dəstəyi ilə daxili şəbəkə var

Xarici verilənlər bazasının konfiqurasiyasını təhlil etməyəcəyik, çünki bu məqalənin məqsədi bu deyil. Tutaq ki, haradasa işləyən verilənlər bazası var - və bizim onunla əlaqə nöqtəmiz var. Biz sadəcə olaraq bu məlumatları mühit dəyişənlərinə əlavə edəcəyik.

Keycloak-ın uğursuzluq (HA) klasterində necə işlədiyini daha yaxşı başa düşmək üçün bunların hamısının Wildfly-nin qruplaşma bacarıqlarından nə dərəcədə asılı olduğunu bilmək vacibdir.

Wildfly bir neçə alt sistemdən istifadə edir, onlardan bəziləri yük balanslaşdırıcısı kimi, bəziləri isə uğursuzluq üçün istifadə olunur. Yük balanslaşdırıcısı klaster qovşağı həddən artıq yükləndikdə proqramın mövcudluğunu təmin edir və bəzi klaster qovşaqları uğursuz olsa belə, uğursuzluq tətbiqin mövcudluğunu təmin edir. Bu alt sistemlərdən bəziləri bunlardır:

• mod_cluster: HTTP yük balanslaşdırıcısı kimi Apache ilə birlikdə işləyir, standart host kəşfi üçün TCP multicast-dan asılıdır. Xarici balanslaşdırıcı ilə əvəz edilə bilər.

• infinispan: nəqliyyat təbəqəsi kimi JGroups kanallarından istifadə edərək paylanmış keş. İsteğe bağlı olaraq, keşin məzmununu sinxronlaşdırmaq üçün xarici Infinispan klasteri ilə əlaqə saxlamaq üçün HotRod protokolundan istifadə edə bilər.

• jgroups: JGroups kanallarına əsaslanan yüksək əlçatan xidmətlər üçün qrup birliyinə dəstək verir. Adlandırılmış borular klasterdəki tətbiq nümunələrinin qruplara qoşulmasına imkan verir ki, əlaqə etibarlılıq, nizamlılıq və uğursuzluq həssaslığı kimi xüsusiyyətlərə malik olsun.

yük balanslaşdırıcısı

Kubernetes klasterində giriş nəzarətçisi kimi balanslaşdırıcı quraşdırarkən aşağıdakıları yadda saxlamaq vacibdir:

Keycloak-ın işi o deməkdir ki, HTTP vasitəsilə autentifikasiya serverinə qoşulan müştərinin uzaq ünvanı müştəri kompüterinin həqiqi IP ünvanıdır. Balanslaşdırıcı və giriş parametrləri HTTP başlıqlarını düzgün təyin etməlidir X-Forwarded-For и X-Forwarded-Proto, və orijinal başlığı saxlayın HOST. son versiya ingress-nginx (> 0.22.0) onu defolt olaraq söndürür

Bayraq aktivləşdirilməsi proxy-address-forwarding mühit dəyişəni təyin etməklə PROXY_ADDRESS_FORWARDING в true Keycloak-a bir proxy arxasında işlədiyini başa düşür.

Siz də aktivləşdirməlisiniz yapışqan seanslar girişdə. Keycloak cari autentifikasiya sessiyası və istifadəçi sessiyası ilə əlaqəli məlumatları saxlamaq üçün Infinispan-ın paylanmış keşindən istifadə edir. Keşlər defolt olaraq tək sahibdir, başqa sözlə, həmin seans bəzi klaster qovşağında saxlanılır və digər qovşaqlar həmin seansa daxil olmaq üçün uzaqdan tələb etməlidirlər.

Konkret olaraq, sənədlərin əksinə olaraq, kuki adı ilə sessiya əlavə etmək bizim üçün işləmədi AUTH_SESSION_ID. Keycloak yönləndirməni fırladıb, ona görə də yapışqan sessiya üçün fərqli kuki adı seçməyi tövsiyə edirik.

Keycloak həmçinin ilk cavab verən ev sahibinin adını da əlavə edir AUTH_SESSION_ID, və yüksək əlçatan versiyada hər bir node eyni verilənlər bazasından istifadə etdiyi üçün onların hər biri olmalıdır əməliyyatları idarə etmək üçün ayrıca və unikal node ID. daxil etmək tövsiyə olunur JAVA_OPTS parametrləri jboss.node.name и jboss.tx.node.id hər bir node üçün unikal - məsələn, podun adını təyin edə bilərsiniz. Podun adını qoysanız - jboss dəyişənləri üçün 23 simvol limitini unutma, ona görə də Deployment deyil, StatefulSet istifadə etmək daha yaxşıdır.

Daha bir rake - bir pod silinirsə və ya yenidən işə salınırsa, onun önbelleği itirilir. Bunu nəzərə alaraq, bütün keşlər üçün önbellek sahiblərinin sayını ən azı ikiyə təyin etməyə dəyər, buna görə də önbelleğin bir nüsxəsi olacaq. Həll yolu qaçmaqdır Wildfly üçün skript podu işə saldıqda onu kataloqa yerləşdirin /opt/jboss/startup-scripts konteynerdə:

Skript məzmunu

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

sonra mühit dəyişəninin dəyərini təyin edin CACHE_OWNERS tələb olunana.

IP multicast dəstəyi ilə şəxsi şəbəkə

Əgər Weavenet-dən CNI olaraq istifadə edirsinizsə, multicast dərhal işləyəcək - və Keycloak qovşaqlarınız işə düşən kimi bir-birini görəcək.

Kubernetes klasterinizdə ip multicast dəstəyiniz yoxdursa, qovşaqları tapmaq üçün JGroups-u digər protokollarla işləmək üçün konfiqurasiya edə bilərsiniz.

Birinci seçim istifadə etməkdir KUBE_DNSistifadə edən headless service Keycloak qovşaqlarını tapmaq üçün siz sadəcə JGroups-a qovşaqları tapmaq üçün istifadə olunacaq xidmətin adını ötürürsünüz.

Başqa bir seçim metoddan istifadə etməkdir KUBE_PINGqovşaqları tapmaq üçün API ilə işləyir (konfiqurasiya etməlisiniz serviceAccount hüquqları ilə list и get, sonra podları bununla işləmək üçün konfiqurasiya edin serviceAccount).

JGroups üçün qovşaqların necə axtarıldığı mühit dəyişənlərini təyin etməklə konfiqurasiya edilir JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Qədər KUBE_PING soruşaraq podları seçmək lazımdır namespace и labels.

️ Əgər siz multicast istifadə edirsinizsə və eyni Kubernetes klasterində iki və ya daha çox Keycloak klasterini işlədirsinizsə (bir ad məkanında deyək). production, ikinci - staging) - bir Keycloak klasterindən qovşaqlar digər klasterə qoşula bilər. Dəyişənləri təyin etməklə hər klaster üçün unikal multicast ünvanından istifadə etdiyinizə əmin olunjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Məlumat mərkəzləri arasında təkrarlama

Əlaqə

Keycloak, Keycloak qovşaqlarından ibarət Keycloack klasterlərini yerləşdirən hər bir məlumat mərkəzi üçün çoxlu ayrıca Infinispan Keş Klasterlərindən istifadə edir. Ancaq eyni zamanda, müxtəlif məlumat mərkəzlərində Keycloak qovşaqları arasında heç bir fərq yoxdur.

Keycloak qovşaqları məlumat mərkəzləri arasında əlaqə yaratmaq üçün xarici Java Data Grid (Infinispan serverləri) istifadə edir. Rabitə protokola uyğun işləyir Infinispan HotRod.

Infinispan keşləri atributla konfiqurasiya edilməlidir remoteStore, məlumatların uzaqdan saxlanıla bilməsi üçün (başqa bir məlumat mərkəzində, təqribən. tərcüməçi) keşlər. JDG serverləri arasında ayrı-ayrı sonsuz klasterlər var, buna görə də məlumat saytda JDG1-də saxlanılır site1 yerində JDG2-yə təkrarlanacaq site2.

Nəhayət, qəbul edən JDG serveri HotRod protokolunun xüsusiyyəti olan müştəri əlaqələri vasitəsilə öz klasterinin Keycloak serverlərini xəbərdar edir. Keycloak qovşaqları aktivdir site2 onların Infinispan keşlərini yeniləyin və xüsusi istifadəçi sessiyası açıq olan Keycloak qovşaqlarında əlçatan olur site2.

Bəzi keşlərin ehtiyat nüsxəsini çıxarmaması və Infinispan serveri vasitəsilə məlumat yazmaqdan tamamilə imtina etməsi də mümkündür. Bunu etmək üçün parametri silmək lazımdır remote-store xüsusi Infinispan önbelleği (faylda bağımsız-ha.xml), bundan sonra bəzi xüsusi replicated-cache Infinispan serverinin tərəfində də artıq lazım olmayacaq.

Keşlərin qurulması

Keycloak-da iki növ keş var:

• yerli. O, bazanın yanında yerləşir, verilənlər bazasına yükü azaltmağa, həmçinin cavab gecikməsini azaltmağa xidmət edir. Bu tip keş səltənəti, müştəriləri, rolları və istifadəçi metadatasını saxlayır. Bu tip keş hətta Keycloak klasterinin bir hissəsi olsa belə təkrarlanmır. Keşdəki bəzi qeydlər dəyişərsə, klasterdəki qalan serverlərə dəyişiklik mesajı göndərilir, bundan sonra giriş keşdən çıxarılır. təsvirə baxın work prosedurun daha ətraflı təsviri üçün aşağıda.

• Təkrarlana bilən. İstifadəçi sessiyalarını, oflayn tokenləri emal edir və parol fişinq cəhdlərini və digər hücumları aşkar etmək üçün giriş xətalarına nəzarət edir. Bu keşlərdə saxlanılan məlumatlar müvəqqətidir, yalnız RAM-da saxlanılır, lakin çoxluqda təkrarlana bilər.

Infinispan Keşlər

İclaslar - Keycloak-da bir konsepsiya, ayrı-ayrı keşlər adlanır authenticationSessions, xüsusi istifadəçilərin məlumatlarını saxlamaq üçün istifadə olunur. Bu keşlərdən olan sorğular adətən proqramlar deyil, brauzer və Keycloak serverləri tərəfindən tələb olunur. Burada yapışqan seanslardan asılılıq özünü büruzə verir və belə keşlərin özlərini, hətta Aktiv-Aktiv rejimdə də təkrarlamaq lazım deyil.

Fəaliyyət nişanları. Başqa bir konsepsiya, adətən müxtəlif ssenarilər üçün istifadə olunur, məsələn, istifadəçi poçtla asinxron bir şey etməli olduqda. Məsələn, prosedur zamanı forget password önbellek actionTokens əlaqəli tokenlərin metadatasını izləmək üçün istifadə olunur - məsələn, token artıq istifadə olunub və onu yenidən aktivləşdirmək mümkün deyil. Bu tip keş adətən məlumat mərkəzləri arasında təkrarlanmalıdır.

Saxlanılan məlumatların keşləşdirilməsi və müddətinin başa çatması verilənlər bazasından yükü götürməyə çalışır. Bu keşləmə performansı yaxşılaşdırır, lakin açıq bir problem əlavə edir. Əgər bir Keycloak serveri məlumatları yeniləyirsə, qalan serverlərə məlumat verilməlidir ki, onlar öz keşlərini yeniləyə bilsinlər. Keycloak yerli keşlərdən istifadə edir realms, users и authorization verilənlər bazasından məlumatların keşləşdirilməsi üçün.

Ayrı bir önbellek də var work, bu, bütün məlumat mərkəzlərində təkrarlanır. O, özü verilənlər bazasından heç bir məlumat saxlamır, lakin məlumat mərkəzləri arasında klaster qovşaqlarına məlumatların köhnəlməsi mesajlarını göndərməyə xidmət edir. Başqa sözlə, məlumatlar yenilənən kimi Keycloak qovşağı öz məlumat mərkəzindəki digər qovşaqlara, eləcə də digər məlumat mərkəzlərindəki qovşaqlara mesaj göndərir. Belə bir mesajı aldıqdan sonra hər bir qovşaq yerli keşlərindəki müvafiq məlumatları təmizləyir.

İstifadəçi sessiyaları. Adları olan keşlər sessions, clientSessions, offlineSessions и offlineClientSessions, adətən məlumat mərkəzləri arasında təkrarlanır və istifadəçi brauzerdə aktiv olduqda aktiv olan istifadəçi sessiyaları haqqında məlumatların saxlanmasına xidmət edir. Bu keşlər son istifadəçilərin HTTP sorğularını idarə edən proqramla işləyir, ona görə də onlar yapışqan seanslarla əlaqələndirilir və məlumat mərkəzləri arasında təkrarlanmalıdır.

kobud güc qorunması. Gizli yer loginFailures istifadəçinin səhv parol daxil etmə sayı kimi giriş xətası məlumatlarını izləmək üçün istifadə olunur. Bu keşin təkrarlanması administratordan asılıdır. Ancaq dəqiq hesablama üçün məlumat mərkəzləri arasında replikasiyanı aktivləşdirməyə dəyər. Ancaq digər tərəfdən, bu məlumatları təkrarlamasanız, performansı yaxşılaşdıra biləcəksiniz və bu sual yaranarsa, replikasiya aktivləşdirilə bilməz.

Infinispan klasterini yayarkən, parametrlər faylına keş tərifləri əlavə etməlisiniz:

<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 klasterini işə salmazdan əvvəl Infinispan klasterini konfiqurasiya etməli və işə salmalısınız

Sonra təyin etməlisiniz remoteStore Keycloak keşləri üçün. Bunun üçün dəyişəni təyin etmək üçün istifadə edilən əvvəlkinə bənzər bir skript kifayətdir. CACHE_OWNERS, onu faylda saxlamaq və kataloqa yerləşdirmək lazımdır /opt/jboss/startup-scripts:

Skript məzmunu

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

Quraşdırmağı unutmayın JAVA_OPTS Keycloak qovşaqlarının HotRod-un işləməsi üçün: remote.cache.host, remote.cache.port və xidmət adı jboss.site.name.

Bağlantılar və əlavə sənədlər

• https://www.keycloak.org/docs/latest/server_installation/index.html
• https://docs.wildfly.org/17/High_Availability_Guide.html#cluster-configuration
• https://infinispan.org/docs/9.4.x/user_guide/user_guide.html
• https://hub.docker.com/r/jboss/keycloak
• https://hub.docker.com/r/jboss/infinispan

Yazı işçilər tərəfindən tərcümə edilərək Habr üçün hazırlanmışdır Slurm təlim mərkəzi — praktikantlardan intensiv, video kurslar və korporativ təlimlər (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Mənbə: www.habr.com