TP; DR: Keycloak tavsifi, ochiq manbali kirishni boshqarish tizimi, ichki tuzilmani tahlil qilish, konfiguratsiya tafsilotlari bo'ladi.
Kirish va asosiy fikrlar
Ushbu maqolada biz Kubernetes tepasida Keycloak klasterini o'rnatishda yodda tutish kerak bo'lgan asosiy g'oyalarni ko'rib chiqamiz.
Agar siz Keycloak haqida ko'proq bilmoqchi bo'lsangiz, maqolaning oxiridagi havolalarga qarang. Amaliyotga ko'proq sho'ng'ish uchun siz o'rganishingiz mumkin ushbu maqolaning asosiy g'oyalarini amalga oshiradigan modul bilan (ishga tushirish qo'llanmasi mavjud, ushbu maqola qurilma va sozlamalar haqida umumiy ma'lumot beradi, taxminan. tarjimon).
Keycloak - bu Java-da yozilgan va dastur serveri ustiga qurilgan keng qamrovli tizim . Muxtasar qilib aytganda, bu dastur foydalanuvchilari federatsiyasi va SSO (bir martalik kirish) imkoniyatlarini beruvchi avtorizatsiya uchun asosdir.
Sizni rasmiy o'qishni taklif qilamiz yoki batafsil tushunish uchun.
Keycloak ishga tushirilmoqda
Keycloak ishlashi uchun ikkita doimiy ma'lumot manbasini talab qiladi:
- O'rnatilgan ma'lumotlarni, masalan, foydalanuvchi ma'lumotlarini saqlash uchun foydalaniladigan ma'lumotlar bazasi
- Datagrid keshi ma'lumotlar bazasidan ma'lumotlarni keshlash, shuningdek, foydalanuvchi seanslari kabi ba'zi qisqa muddatli va tez-tez o'zgaruvchan metama'lumotlarni saqlash uchun ishlatiladi. Amalga oshirildi , bu odatda ma'lumotlar bazasidan sezilarli darajada tezroq. Lekin har holda, Infinispan-da saqlangan ma'lumotlar vaqtinchalik - va klaster qayta ishga tushirilganda uni hech qanday joyda saqlash kerak emas.
Keycloak to'rt xil rejimda ishlaydi:
- oddiy - fayl orqali sozlangan bitta va faqat bitta jarayon standalone.xml
- Doimiy klaster (yuqori mavjudlik opsiyasi) - barcha jarayonlar qo'lda sinxronlashtirilishi kerak bo'lgan bir xil konfiguratsiyadan foydalanishi kerak. Sozlamalar faylda saqlanadi standalone-ha.xml, qo'shimcha ravishda siz ma'lumotlar bazasiga va yuk balanslagichiga umumiy kirishni amalga oshirishingiz kerak.
- Domen klasteri — klasterni normal rejimda ishga tushirish tezda odatiy va zerikarli vazifaga aylanadi, chunki klaster o'sishi bilan har safar konfiguratsiya o'zgarganda barcha o'zgarishlar har bir klaster tugunida amalga oshirilishi kerak. Domenning ishlash rejimi bu muammoni ba'zi umumiy saqlash joyini o'rnatish va konfiguratsiyani nashr qilish orqali hal qiladi. Ushbu sozlamalar faylda saqlanadi domain.xml
- Ma'lumotlar markazlari o'rtasida replikatsiya — agar siz Keycloak-ni bir nechta ma'lumotlar markazlari klasterida, ko'pincha turli geografik joylarda ishga tushirishni istasangiz. Ushbu parametrda har bir ma'lumot markazi Keycloak serverlarining o'z klasteriga ega bo'ladi.
Ushbu maqolada biz ikkinchi variantni batafsil ko'rib chiqamiz, ya'ni muntazam klaster, va biz ma'lumotlar markazlari o'rtasida replikatsiya mavzusiga ham biroz to'xtalib o'tamiz, chunki Kubernetes-da ushbu ikkita variantni ishga tushirish mantiqan. Yaxshiyamki, Kubernetes-da bir nechta pods (Keycloak tugunlari) sozlamalarini sinxronlashda muammo yo'q, shuning uchun domen klasteri Buni qilish juda qiyin bo'lmaydi.
Shuningdek, so'zni unutmang Klaster Maqolaning qolgan qismi faqat birgalikda ishlaydigan Keycloak tugunlari guruhiga taalluqlidir, Kubernetes klasteriga murojaat qilishning hojati yo'q.
Oddiy Keycloak klasteri
Keycloak-ni ushbu rejimda ishga tushirish uchun sizga kerak bo'ladi:
- tashqi umumiy ma'lumotlar bazasini sozlash
- yuk balansini o'rnating
- IP multicast qo'llab-quvvatlanadigan ichki tarmoqqa ega bo'lish
Biz tashqi ma'lumotlar bazasini yaratishni muhokama qilmaymiz, chunki bu maqolaning maqsadi emas. Faraz qilaylik, biror joyda ishlaydigan ma'lumotlar bazasi bor - va bizda unga ulanish nuqtasi bor. Biz shunchaki bu ma'lumotlarni muhit o'zgaruvchilariga qo'shamiz.
Keycloak muvaffaqiyatsiz (HA) klasterida qanday ishlashini yaxshiroq tushunish uchun bularning barchasi Wildflyning klasterlash imkoniyatlariga qanchalik bog'liqligini bilish muhimdir.
Wildfly bir nechta quyi tizimlardan foydalanadi, ularning ba'zilari yuk balansi sifatida ishlatiladi, ba'zilari xatolarga chidamlilik uchun. Yuk balanslagichi klaster tuguniga haddan tashqari yuklanganda dastur mavjudligini ta'minlaydi va xatoga chidamlilik ba'zi klaster tugunlari muvaffaqiyatsiz bo'lsa ham dastur mavjudligini ta'minlaydi. Ushbu quyi tizimlardan ba'zilari:
-
mod_cluster: HTTP yuk balansi sifatida Apache bilan birgalikda ishlaydi, sukut bo'yicha xostlarni topish uchun TCP multicast-ga bog'liq. Tashqi balanslagich bilan almashtirilishi mumkin. -
infinispan: JGroups kanallarini transport qatlami sifatida ishlatadigan taqsimlangan kesh. Bundan tashqari, u kesh tarkibini sinxronlashtirish uchun tashqi Infinispan klasteri bilan bog'lanish uchun HotRod protokolidan foydalanishi mumkin. -
jgroups: JGroups kanallari asosida yuqori darajada mavjud bo'lgan xizmatlar uchun guruh aloqasini qo'llab-quvvatlaydi. Nomlangan quvurlar klasterdagi dastur misollarini guruhlarga ulash imkonini beradi, shunda aloqa ishonchlilik, tartiblilik va nosozliklarga sezgirlik kabi xususiyatlarga ega bo'ladi.
Yuklash balansi
Kubernetes klasteriga kirish nazoratchisi sifatida balansizatorni o'rnatishda quyidagi narsalarni yodda tutish kerak:
Keycloak HTTP orqali autentifikatsiya serveriga ulanadigan mijozning masofaviy manzili mijoz kompyuterining haqiqiy IP manzili ekanligini taxmin qiladi. Balanslashtiruvchi va kirish sozlamalari HTTP sarlavhalarini to'g'ri o'rnatishi kerak X-Forwarded-For и X-Forwarded-Proto, shuningdek, asl sarlavhani saqlang HOST. Eng so'nggi versiya ingress-nginx (>0.22.0)
Bayroqni faollashtirish proxy-address-forwarding muhit o'zgaruvchisini o'rnatish orqali PROXY_ADDRESS_FORWARDING в true Keycloak proksi-server ortida ishlayotganini tushunishini beradi.
Siz ham yoqishingiz kerak yopishqoq seanslar kirishda. Keycloak joriy autentifikatsiya seansi va foydalanuvchi sessiyasi bilan bog‘liq ma’lumotlarni saqlash uchun taqsimlangan Infinispan keshidan foydalanadi. Keshlar sukut bo'yicha bitta egasi bilan ishlaydi, boshqacha qilib aytganda, ushbu seans klasterdagi ba'zi tugunlarda saqlanadi va boshqa tugunlar ushbu seansga kirishga muhtoj bo'lsa, uni masofadan turib so'rashi kerak.
Xususan, hujjatlardan farqli o'laroq, cookie nomi bilan sessiyani biriktirish biz uchun ishlamadi
AUTH_SESSION_ID. Keycloak-da qayta yo'naltirish tsikli mavjud, shuning uchun yopishqoq seans uchun boshqa cookie nomini tanlashni tavsiya qilamiz.
Keycloak birinchi javob bergan tugun nomini ham biriktiradi AUTH_SESSION_ID, va yuqori darajada mavjud versiyadagi har bir tugun bir xil ma'lumotlar bazasidan foydalanganligi sababli, ularning har biri tranzaktsiyalarni boshqarish uchun alohida va noyob tugun identifikatori. Qo'yish tavsiya etiladi JAVA_OPTS parametrlar jboss.node.name и jboss.tx.node.id har bir tugun uchun noyob - siz, masalan, pod nomini qo'yishingiz mumkin. Agar siz podkast nomini qo'ysangiz, jboss o'zgaruvchilari uchun 23 belgi chegarasi haqida unutmang, shuning uchun Deployment o'rniga StatefulSet dan foydalanish yaxshiroqdir.
Yana bir rake - agar pod o'chirilsa yoki qayta ishga tushirilsa, uning keshi yo'qoladi. Buni hisobga olgan holda, keshning nusxasi qolishi uchun barcha keshlar uchun kesh egalari sonini kamida ikkitaga belgilashga arziydi. Yechim yugurishdir podni ishga tushirganda, uni katalogga joylashtirish /opt/jboss/startup-scripts konteynerda:
Skript tarkibi
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-serverkeyin muhit o'zgaruvchisining qiymatini o'rnating CACHE_OWNERS talab qilinganiga.
IP multicast qo'llab-quvvatlanadigan xususiy tarmoq
Agar siz Weavenet-dan CNI sifatida foydalansangiz, multicast darhol ishlaydi - Keycloak tugunlaringiz ishga tushirilishi bilanoq bir-birini ko'radi.
Agar Kubernetes klasteringizda IP multicast-ni qo'llab-quvvatlamasangiz, JGroups-ni tugunlarni topish uchun boshqa protokollar bilan ishlash uchun sozlashingiz mumkin.
Birinchi variant - foydalanish KUBE_DNSqaysi foydalanadi headless service Keycloak tugunlarini topish uchun siz JGroups-ga tugunlarni topish uchun ishlatiladigan xizmat nomini berishingiz kifoya.
Yana bir variant - bu usuldan foydalanish KUBE_PING, tugunlarni qidirish uchun API bilan ishlaydi (siz sozlashingiz kerak serviceAccount huquqlar bilan list и get, va keyin bu bilan ishlash uchun podkastlarni sozlang serviceAccount).
JGroups tugunlarni topish usuli muhit o'zgaruvchilarini sozlash orqali sozlanadi JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. uchun KUBE_PING so'rash orqali podlarni tanlashingiz kerak namespace и labels.
️ Agar siz multicastdan foydalansangiz va bitta Kubernetes klasterida ikkita yoki undan ortiq Keycloak klasterlarini ishga tushirsangiz (aytaylik, bitta nom maydonida).
production, ikkinchisi -staging) - bitta Keycloak klasterining tugunlari boshqa klasterga qo'shilishi mumkin. O'zgaruvchilarni o'rnatish orqali har bir klaster uchun noyob multicast manzilidan foydalanganingizga ishonch hosil qilingjboss.default.multicast.addressиjboss.modcluster.multicast.addressвJAVA_OPTS.
Ma'lumotlar markazlari o'rtasida replikatsiya
Ulanish
Keycloak Keycloak tugunlaridan tashkil topgan Keycloack klasterlari joylashgan har bir maʼlumot markazi uchun bir nechta alohida Infinispan kesh klasterlaridan foydalanadi. Ammo turli ma'lumotlar markazlaridagi Keycloak tugunlari o'rtasida farq yo'q.
Keycloak tugunlari ma'lumotlar markazlari o'rtasidagi aloqa uchun tashqi Java Data Grid (Infinispan serverlari) dan foydalanadi. Aloqa protokolga muvofiq ishlaydi .
Infinispan keshlari atribut bilan sozlanishi kerak remoteStore, shuning uchun ma'lumotlar masofadan turib saqlanishi mumkin (boshqa ma'lumotlar markazida, taxminan. tarjimon) keshlar. JDG serverlari orasida alohida infinispan klasterlari mavjud bo'lib, ma'lumotlar JDG1 da saqlanadi. site1 saytida JDG2 ga takrorlanadi site2.
Va nihoyat, qabul qiluvchi JDG serveri HotRod protokolining xususiyati bo'lgan mijoz ulanishlari orqali o'z klasteri haqida Keycloak serverlarini xabardor qiladi. Keycloak tugunlari yoqilgan site2 ularning Infinispan keshlari yangilanadi va maxsus foydalanuvchi sessiyasi yoqilgan Keycloak tugunlarida ham mavjud bo'ladi site2.
Ba'zi keshlar uchun zaxira nusxalarini yaratmaslik va Infinispan serveri orqali ma'lumotlarni yozishdan butunlay qochish ham mumkin. Buning uchun siz sozlamani olib tashlashingiz kerak remote-store maxsus Infinispan keshi (faylda standalone-ha.xml), shundan keyin ba'zi bir aniq replicated-cache Infinispan server tomonida endi kerak bo'lmaydi.
Keshlarni sozlash
Keycloak-da ikkita kesh turi mavjud:
-
Mahalliy. U ma'lumotlar bazasi yonida joylashgan bo'lib, ma'lumotlar bazasiga yukni kamaytirishga, shuningdek, javoblarning kechikishini kamaytirishga xizmat qiladi. Ushbu turdagi kesh soha, mijozlar, rollar va foydalanuvchi metama'lumotlarini saqlaydi. Kesh Keycloak klasterining bir qismi bo'lsa ham, keshning bunday turi takrorlanmaydi. Agar keshdagi yozuv o'zgartirilsa, o'zgarish haqidagi xabar klasterdagi qolgan serverlarga yuboriladi, shundan so'ng yozuv keshdan chiqarib tashlanadi. Tavsifga qarang
workJarayonning batafsil tavsifi uchun quyida ko'ring. -
Replikatsiya qilingan. Foydalanuvchi seanslarini, oflayn tokenlarni qayta ishlaydi, shuningdek parolni fishingga urinishlar va boshqa hujumlarni aniqlash uchun kirish xatolarini nazorat qiladi. Ushbu keshlarda saqlangan ma'lumotlar vaqtinchalik, faqat operativ xotirada saqlanadi, lekin ularni klaster bo'ylab takrorlash mumkin.
Infinispan keshlari
Sessiyalar - Keycloak-dagi kontseptsiya, alohida keshlar deb ataladi authenticationSessions, ma'lum foydalanuvchilarning ma'lumotlarini saqlash uchun ishlatiladi. Ushbu keshlardan so'rovlar odatda ilovalar tomonidan emas, balki brauzer va Keycloak serverlari tomonidan talab qilinadi. Bu erda yopishqoq seanslarga bog'liqlik paydo bo'ladi va bunday keshlarning o'zini, hatto Active-Active rejimida ham takrorlash kerak emas.
Harakat belgilari. Boshqa kontseptsiya, odatda turli stsenariylar uchun ishlatiladi, masalan, foydalanuvchi pochta orqali asinxron tarzda biror narsa qilish kerak. Masalan, protsedura davomida forget password kesh actionTokens bog'langan tokenlarning metama'lumotlarini kuzatish uchun ishlatiladi - masalan, token allaqachon ishlatilgan va uni qayta faollashtirib bo'lmaydi. Ushbu turdagi kesh odatda ma'lumotlar markazlari o'rtasida takrorlanishi kerak.
Saqlangan ma'lumotlarni keshlash va eskirish ma'lumotlar bazasidagi yukni engillashtirish uchun ishlaydi. Bunday keshlash ishlashni yaxshilaydi, lekin aniq muammoni qo'shadi. Agar Keycloak serverlaridan biri ma'lumotlarni yangilasa, boshqa serverlar keshlardagi ma'lumotlarni yangilashlari uchun xabardor qilinishi kerak. Keycloak mahalliy keshlardan foydalanadi realms, users и authorization ma'lumotlar bazasidan ma'lumotlarni keshlash uchun.
Bundan tashqari, alohida kesh mavjud work, bu barcha ma'lumotlar markazlarida takrorlanadi. Uning o'zi ma'lumotlar bazasidan hech qanday ma'lumot saqlamaydi, lekin ma'lumotlar markazlari orasidagi klaster tugunlariga ma'lumotlarning qarishi haqida xabarlarni yuborish uchun xizmat qiladi. Boshqacha qilib aytganda, ma'lumotlar yangilanishi bilanoq, Keycloak tuguni o'zining ma'lumotlar markazidagi boshqa tugunlarga, shuningdek, boshqa ma'lumotlar markazlaridagi tugunlarga xabar yuboradi. Bunday xabarni olgandan so'ng, har bir tugun o'zining mahalliy keshlarida tegishli ma'lumotlarni tozalaydi.
Foydalanuvchi seanslari. Ismlar bilan keshlar sessions, clientSessions, offlineSessions и offlineClientSessions, odatda ma'lumotlar markazlari o'rtasida takrorlanadi va foydalanuvchi brauzerda faol bo'lgan vaqtda faol bo'lgan foydalanuvchi seanslari haqidagi ma'lumotlarni saqlash uchun xizmat qiladi. Ushbu keshlar oxirgi foydalanuvchilarning HTTP so'rovlarini qayta ishlash ilovalari bilan ishlaydi, shuning uchun ular yopishqoq seanslar bilan bog'lanadi va ma'lumotlar markazlari o'rtasida takrorlanishi kerak.
Qo'pol kuch himoyasi. Kesh loginFailures Kirish xatosi ma'lumotlarini kuzatish uchun foydalaniladi, masalan, foydalanuvchi necha marta noto'g'ri parol kiritgan. Ushbu keshni takrorlash administratorning javobgarligi. Ammo aniq hisoblash uchun ma'lumotlar markazlari o'rtasida replikatsiyani faollashtirishga arziydi. Ammo boshqa tomondan, agar siz ushbu ma'lumotlarni takrorlamasangiz, ishlashni yaxshilaysiz va agar bu muammo yuzaga kelsa, replikatsiya faollashtirilmasligi mumkin.
Infinispan klasterini chiqarayotganda sozlamalar fayliga kesh ta'riflarini qo'shishingiz kerak:
<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 ishga tushirishdan oldin Infinispan klasterini sozlashingiz va ishga tushirishingiz kerak
Keyin sozlashingiz kerak remoteStore Keycloak keshlari uchun. Buning uchun o'zgaruvchini o'rnatish uchun ishlatiladigan avvalgisiga o'xshash skript etarli. CACHE_OWNERS, siz uni faylga saqlashingiz va uni katalogga qo'yishingiz kerak /opt/jboss/startup-scripts:
Skript tarkibi
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-serverO'rnatishni unutmang JAVA_OPTS HotRodni ishga tushirish uchun Keycloak tugunlari uchun: remote.cache.host, remote.cache.port va xizmat nomi jboss.site.name.
Havolalar va qo'shimcha hujjatlar
Maqola xodimlar tomonidan tarjima qilingan va Habr uchun tayyorlangan — amaliyotchi mutaxassislardan intensiv kurslar, video kurslar va korporativ treninglar (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)
Manba: www.habr.com