Kubernetes дээр Keycloak-г HA горимд ажиллуулж байна

Kubernetes дээр Keycloak-г HA горимд ажиллуулж байна

TL, DR: нээлттэй эхийн хандалтын хяналтын систем болох Keycloak-ийн тайлбар, дотоод бүтцийн дүн шинжилгээ, тохиргооны дэлгэрэнгүй мэдээлэл байх болно.

Танилцуулга ба гол санаанууд

Энэ нийтлэлд бид Kubernetes дээр Keycloak кластер байрлуулахдаа анхаарах ёстой үндсэн санаануудыг харах болно.

Хэрэв та Keycloak-ийн талаар илүү ихийг мэдэхийг хүсвэл нийтлэлийн төгсгөлд байгаа холбоосыг үзнэ үү. Практикт илүү гүнзгий орохын тулд та суралцах боломжтой манай агуулах Энэ нийтлэлийн гол санааг хэрэгжүүлдэг модультай (эхлүүлэх гарын авлага тэнд байгаа, энэ нийтлэл нь төхөөрөмж болон тохиргооны тоймыг өгөх болно, ойролцоогоор. орчуулагч).

Keycloak нь Java хэл дээр бичигдсэн, програмын сервер дээр бүтээгдсэн цогц систем юм Зэрлэг шувуу. Товчхондоо, энэ нь програмын хэрэглэгчдийн холбоо болон SSO (дангаар нэвтрэх) боломжийг олгодог зөвшөөрлийн хүрээ юм.

Албан ёсны мэдээллийг уншихыг урьж байна вэбсайт буюу Википедиа дэлгэрэнгүй ойлгохын тулд.

Keycloak эхлүүлж байна

Keycloak-ийг ажиллуулахын тулд хоёр байнгын мэдээллийн эх сурвалж шаардлагатай:

  • Хэрэглэгчийн мэдээлэл гэх мэт тогтсон өгөгдлийг хадгалахад ашигладаг мэдээллийн сан
  • Өгөгдлийн сангаас өгөгдлийг кэш хийх, мөн хэрэглэгчийн сесс зэрэг богино хугацааны, байнга өөрчлөгддөг мета өгөгдлийг хадгалахад ашигладаг Datagrid кэш. Хэрэгжүүлсэн Инфиниспан, энэ нь ихэвчлэн мэдээллийн сангаас хамаагүй хурдан байдаг. Гэхдээ ямар ч тохиолдолд Infinispan-д хадгалагдсан өгөгдөл нь түр зуурынх бөгөөд кластерыг дахин эхлүүлэх үед хаана ч хадгалагдах шаардлагагүй болно.

Keycloak нь дөрвөн өөр горимд ажилладаг:

  • энгийн - файлаар тохируулагдсан цорын ганц процесс standalone.xml
  • Тогтмол кластер (өндөр боломжтой сонголт) - бүх процессууд ижил тохиргоог ашиглах ёстой бөгөөд үүнийг гараар синхрончлох ёстой. Тохиргоог файлд хадгална бие даасан-ha.xml, үүнээс гадна та мэдээллийн бааз болон ачааллын тэнцвэржүүлэгч рүү хуваалцсан хандалт хийх хэрэгтэй.
  • Домэйн кластер - Кластерыг хэвийн горимд эхлүүлэх нь кластер томрох тусам энгийн бөгөөд уйтгартай ажил болж хувирдаг, учир нь тохиргоо өөрчлөгдөх бүрт кластерын зангилаа бүр дээр бүх өөрчлөлтийг хийх ёстой. Домэйн үйлдлийн горим нь хуваалцсан хадгалах байршлыг тохируулах, тохиргоог нийтлэх замаар энэ асуудлыг шийддэг. Эдгээр тохиргоонууд нь файлд хадгалагддаг домэйн.xml
  • Дата төвүүдийн хооронд хуулбарлах — хэрэв та Keycloak-ийг хэд хэдэн дата төвийн кластерт, ихэнхдээ газарзүйн өөр өөр байршилд ажиллуулахыг хүсвэл. Энэ сонголтоор дата төв бүр Keycloak серверүүдийн өөрийн гэсэн кластертай байх болно.

Энэ нийтлэлд бид хоёр дахь сонголтыг, өөрөөр хэлбэл, нарийвчлан авч үзэх болно тогтмол кластер, мөн эдгээр хоёр сонголтыг Kubernetes дээр ажиллуулах нь утга учиртай тул бид дата төвүүдийн хооронд хуулбарлах сэдвийн талаар бага зэрэг хөндөх болно. Аз болоход, Kubernetes-д хэд хэдэн pods (Keycloak nodes) тохиргоог синхрончлоход ямар ч асуудал байхгүй. домэйн кластер Үүнийг хийхэд тийм ч хэцүү биш байх болно.

Мөн энэ үгийг анхаарна уу бөөгнөрөл Нийтлэлийн үлдсэн хэсэг нь зөвхөн хамтран ажилладаг Keycloak зангилааны бүлэгт хамаарах тул Kubernetes кластерт хандах шаардлагагүй.

Энгийн Keycloak кластер

Keycloak-г энэ горимд ажиллуулахын тулд танд хэрэгтэй:

  • гадаад хуваалцсан мэдээллийн санг тохируулах
  • ачаалал тэнцвэржүүлэгч суурилуулах
  • IP multicast дэмжлэгтэй дотоод сүлжээтэй байх

Энэ нийтлэлийн зорилго биш тул бид гадны мэдээллийн сан байгуулах талаар хэлэлцэхгүй. Хаа нэгтээ ажиллаж байгаа мэдээллийн сан байгаа гэж бодъё - бид үүнтэй холбогдох цэгтэй. Бид зүгээр л энэ өгөгдлийг орчны хувьсагчдад нэмэх болно.

Keycloak нь бүтэлгүйтлийн (HA) кластерт хэрхэн ажилладагийг илүү сайн ойлгохын тулд Wildfly-ийн кластер хийх чадвараас хэр их хамааралтайг мэдэх нь чухал юм.

Wildfly хэд хэдэн дэд системийг ашигладаг бөгөөд тэдгээрийн заримыг нь ачааллын тэнцвэржүүлэгч, заримыг нь алдааг тэсвэрлэхэд ашигладаг. Ачаалал тэнцвэржүүлэгч нь кластерийн зангилаа хэт ачаалалтай үед програмын бэлэн байдлыг баталгаажуулдаг ба алдааны хүлцэл нь зарим кластерийн зангилаа бүтэлгүйтсэн ч програмын бэлэн байдлыг баталгаажуулдаг. Эдгээр дэд системүүдийн зарим нь:

  • mod_cluster: HTTP ачааллын тэнцвэржүүлэгчийн хувьд Apache-тэй хамт ажилладаг бөгөөд анхдагчаар хостуудыг олохын тулд TCP multicast-аас хамаардаг. Гадны тэнцвэржүүлэгчээр сольж болно.

  • infinispan: JGroups сувгуудыг тээврийн давхарга болгон ашигладаг тархсан кэш. Нэмж дурдахад энэ нь кэшийн агуулгыг синхрончлохын тулд гадаад Infinispan кластертай холбогдохын тулд HotRod протоколыг ашиглаж болно.

  • jgroups: JGroups сувгууд дээр суурилсан өндөр хүртээмжтэй үйлчилгээнд бүлгийн харилцааны дэмжлэг үзүүлдэг. Нэрлэсэн хоолойнууд нь кластер дахь хэрэглээний тохиолдлуудыг бүлгүүдэд холбох боломжийг олгодог бөгөөд ингэснээр харилцаа холбоо нь найдвартай, эмх цэгцтэй байдал, алдаа дутагдалд мэдрэмтгий байх зэрэг шинж чанартай байдаг.

Ачаалал тэнцвэржүүлэгч

Kubernetes кластерт тэнцвэржүүлэгчийг оролт хянагч болгон суулгахдаа дараах зүйлсийг анхаарах нь чухал.

Keycloak нь HTTP-ээр дамжуулан баталгаажуулалтын сервертэй холбогдож буй үйлчлүүлэгчийн алсын хаяг нь клиент компьютерийн жинхэнэ IP хаяг гэж үздэг. Тэнцвэржүүлэгч болон нэвтрэх тохиргоо нь HTTP толгойг зөв тохируулах ёстой X-Forwarded-For и X-Forwarded-Proto, мөн анхны гарчгийг хадгалах HOST. Хамгийн сүүлийн үеийн хувилбар ingress-nginx (>0.22.0) анхдагчаар үүнийг идэвхгүй болгодог

Далбааг идэвхжүүлж байна proxy-address-forwarding орчны хувьсагчийг тохируулах замаар PROXY_ADDRESS_FORWARDING в true Keycloak нь проксины ард ажиллаж байгаа гэсэн ойлголтыг өгдөг.

Та бас идэвхжүүлэх хэрэгтэй наалттай сессүүд ороход. Keycloak нь одоогийн баталгаажуулалтын сесс болон хэрэглэгчийн сесстэй холбоотой өгөгдлийг хадгалахын тулд тархсан Infinispan кэшийг ашигладаг. Кэш нь анхдагч байдлаар нэг эзэмшигчтэй ажилладаг, өөрөөр хэлбэл тухайн сесс нь кластерын зарим зангилаа дээр хадгалагддаг бөгөөд бусад зангилаанууд тухайн сессэд хандах шаардлагатай бол алсаас асуух ёстой.

Тодруулбал, баримт бичгийн эсрэгээр күүки нэртэй сессийг хавсаргах нь бидэнд тохирохгүй байсан AUTH_SESSION_ID. Keycloak нь дахин чиглүүлэх гогцоотой тул наалттай сессийн өөр күүки нэрийг сонгохыг зөвлөж байна.

Keycloak нь мөн хамгийн түрүүнд хариу өгсөн зангилааны нэрийг хавсаргадаг AUTH_SESSION_ID, мөн өндөр боломжтой хувилбарын зангилаа бүр ижил мэдээллийн санг ашигладаг тул тус бүр нь байх ёстой гүйлгээг удирдах тусдаа бөгөөд өвөрмөц зангилааны танигч. оруулахыг зөвлөж байна JAVA_OPTS параметрүүд jboss.node.name и jboss.tx.node.id зангилаа бүрийн хувьд өвөрмөц - та жишээ нь, хонхорцог нэрийг тавьж болно. Хэрэв та pod нэр тавьсан бол jboss хувьсагчийн 23 тэмдэгтийн хязгаарыг бүү март, тиймээс Deployment гэхээсээ StatefulSet ашиглах нь дээр.

Өөр нэг тармуур - хэрэв pod устгагдсан эсвэл дахин ачаалагдсан бол түүний кэш алдагдана. Үүнийг анхаарч үзвэл кэшийн хуулбар үлдэхийн тулд бүх кэшийн кэш эзэмшигчийн тоог дор хаяж хоёр болгож тохируулах нь зүйтэй. Үүний шийдэл нь гүйх явдал юм Wildfly-д зориулсан скрипт pod-ыг эхлүүлэхдээ лавлахад байрлуулна /opt/jboss/startup-scripts саванд:

Скриптийн агуулга

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

дараа нь орчны хувьсагчийн утгыг тохируулна CACHE_OWNERS шаардлагатай руу.

IP multicast дэмжлэгтэй хувийн сүлжээ

Хэрэв та Weavenet-ийг CNI болгон ашигладаг бол олон дамжуулалт шууд ажиллах бөгөөд таны Keycloak зангилаанууд ажиллаж эхэлмэгц бие биенээ харах болно.

Хэрэв таны Kubernetes кластерт IP multicast дэмжлэг байхгүй бол та JGroups-ийг бусад протоколуудтай ажиллахаар тохируулж, зангилаа олох боломжтой.

Эхний сонголт бол ашиглах явдал юм KUBE_DNSашигладаг headless service Keycloak зангилаа олохын тулд та JGroups-т зангилаа олоход ашиглагдах үйлчилгээний нэрийг л дамжуулна уу.

Өөр нэг сонголт бол энэ аргыг ашиглах явдал юм KUBE_PING, зангилаа хайхын тулд API-тай ажилладаг (та тохируулах хэрэгтэй serviceAccount эрхтэй list и get, дараа нь үүнтэй ажиллахын тулд pods-г тохируулна уу serviceAccount).

JGroups зангилаа олох арга нь орчны хувьсагчдыг тохируулах замаар тохируулагддаг JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. нь KUBE_PING та асууж хонхорцог сонгох хэрэгтэй namespace и labels.

️ Хэрэв та multicast ашиглаж, нэг Kubernetes кластерт хоёр ба түүнээс дээш Keycloak кластер ажиллуулж байгаа бол (нэрийн зайд нэгийг хэлье) production, Хоёрдугаарт - staging) - нэг Keycloak кластерын зангилаа өөр кластерт нэгдэж болно. Хувьсагчдыг тохируулах замаар кластер бүрт өвөрмөц олон дамжуулалтын хаяг ашиглахаа мартуузайjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Дата төвүүдийн хооронд хуулбарлах

Kubernetes дээр Keycloak-г HA горимд ажиллуулж байна

Холболт

Keycloak нь Keycloak зангилаанаас бүрдсэн Keycloack кластерууд байрладаг өгөгдлийн төв бүрт олон тусдаа Infinispan кэш кластеруудыг ашигладаг. Гэхдээ өөр өөр өгөгдлийн төвүүдийн Keycloak зангилааны хооронд ямар ч ялгаа байхгүй.

Keycloak зангилаа нь дата төвүүдийн хооронд харилцахын тулд гадаад Java Data Grid (Infinispan серверүүд) ашигладаг. Харилцаа холбоо нь протоколын дагуу ажилладаг Infinispan HotRod.

Infinispan кэш нь атрибутаар тохируулагдсан байх ёстой remoteStore, ингэснээр өгөгдлийг алсаас хадгалах боломжтой (өөр мэдээллийн төвд, ойролцоогоор. орчуулагч) кэш. JDG серверүүдийн дунд тусдаа хязгааргүй кластерууд байдаг бөгөөд ингэснээр өгөгдөл нь JDG1 дээр хадгалагддаг. site1 газар дээр нь JDG2 дээр хуулбарлах болно site2.

Эцэст нь хүлээн авагч JDG сервер нь HotRod протоколын онцлог шинж чанар болох клиент холболтоор дамжуулан өөрийн кластерын тухай Keycloak серверүүдэд мэдэгддэг. Keycloak зангилаа асаалттай site2 Тэдний Infinispan кэшийг шинэчлэх ба тухайн хэрэглэгчийн сессийг Keycloak зангилаанууд дээр ашиглах боломжтой болно site2.

Зарим кэшийн хувьд нөөцлөлт хийхгүй байх, Infinispan серверээр дамжуулан өгөгдөл бичихээс зайлсхийх боломжтой. Үүнийг хийхийн тулд та тохиргоог арилгах хэрэгтэй remote-store тодорхой Infinispan кэш (файл дотор бие даасан-ha.xml), үүний дараа тодорхой replicated-cache Infinispan серверийн тал дээр цаашид шаардлагагүй болно.

Кэшүүдийг тохируулж байна

Keycloak-д хоёр төрлийн кэш байдаг:

  • Орон нутгийн. Энэ нь мэдээллийн сангийн хажууд байрладаг бөгөөд мэдээллийн баазын ачааллыг багасгахаас гадна хариу үйлдлийн хоцролтыг багасгах үйлчилгээтэй. Энэ төрлийн кэш нь хүрээ, үйлчлүүлэгчид, үүрэг, хэрэглэгчийн мета өгөгдлийг хадгалдаг. Кэш нь Keycloak кластерын хэсэг байсан ч энэ төрлийн кэшийг хуулбарлахгүй. Хэрэв кэш дэх оруулга өөрчлөгдсөн бол өөрчлөлтийн тухай мессежийг кластер дахь үлдсэн серверүүд рүү илгээж, дараа нь оруулгыг кэшээс хасна. Тайлбарыг үзнэ үү work Процедурын дэлгэрэнгүй тайлбарыг доороос үзнэ үү.

  • Хуулбарласан. Хэрэглэгчийн сесс, офлайн токенуудыг боловсруулж, нууц үгээр фишинг хийх оролдлого болон бусад халдлагыг илрүүлэхийн тулд нэвтрэх алдааг хянадаг. Эдгээр кэшэд хадгалагдсан өгөгдөл нь түр зуурынх бөгөөд зөвхөн RAM-д хадгалагддаг боловч кластер даяар хуулбарлах боломжтой.

Infinispan кэш

Чуулган - Keycloak дахь ойлголт, тусдаа кэш гэж нэрлэдэг authenticationSessions, нь тодорхой хэрэглэгчдийн өгөгдлийг хадгалахад ашиглагддаг. Эдгээр кэшийн хүсэлтийг ихэвчлэн програмууд биш харин хөтөч болон Keycloak серверүүд шаарддаг. Эндээс наалттай сессээс хамаарал гарч ирдэг бөгөөд Идэвхтэй-Идэвхтэй горимд байсан ч ийм кэшийг өөрсдөө хуулбарлах шаардлагагүй болно.

Үйлдлийн токенууд. Жишээлбэл, хэрэглэгч шуудангаар асинхроноор ямар нэгэн зүйл хийх шаардлагатай үед ихэвчлэн янз бүрийн хувилбаруудад ашиглагддаг өөр нэг ойлголт. Жишээлбэл, процедурын явцад forget password кэш actionTokens холбогдох токенуудын мета өгөгдлийг хянахад ашигладаг - жишээлбэл, жетоныг аль хэдийн ашигласан бөгөөд дахин идэвхжүүлэх боломжгүй. Энэ төрлийн кэшийг ихэвчлэн мэдээллийн төвүүдийн хооронд хуулбарлах шаардлагатай байдаг.

Хадгалагдсан өгөгдлийг кэшлэх, хөгшрүүлэх өгөгдлийн сангийн ачааллыг хөнгөвчлөх чиглэлээр ажилладаг. Энэ төрлийн кэш нь гүйцэтгэлийг сайжруулдаг боловч тодорхой асуудал үүсгэдэг. Хэрэв нэг Keycloak сервер өгөгдлийг шинэчлэх юм бол бусад серверүүд нь кэш дэх өгөгдлийг шинэчлэхийн тулд мэдэгдэх ёстой. Keycloak нь орон нутгийн кэшийг ашигладаг realms, users и authorization мэдээллийн сангаас өгөгдлийг кэш хийх зориулалттай.

Мөн тусдаа кэш байдаг work, энэ нь бүх мэдээллийн төвүүдэд хуулбарлагддаг. Энэ нь өөрөө өгөгдлийн сангаас ямар ч өгөгдөл хадгалахгүй, харин мэдээллийн төвүүдийн хоорондох кластерийн зангилаа руу өгөгдлийн хөгшрөлтийн тухай мессеж илгээх үйлчилгээ үзүүлдэг. Өөрөөр хэлбэл, өгөгдөл шинэчлэгдсэн даруйд Keycloak зангилаа нь өөрийн дата төвийн бусад зангилаа болон бусад дата төвийн зангилаа руу мессеж илгээдэг. Ийм мессежийг хүлээн авсны дараа зангилаа бүр өөрийн орон нутгийн кэш дэх харгалзах өгөгдлийг арилгадаг.

Хэрэглэгчийн сессүүд. Нэр бүхий кэш sessions, clientSessions, offlineSessions и offlineClientSessions, нь ихэвчлэн өгөгдлийн төвүүдийн хооронд хуулбарлагддаг бөгөөд хэрэглэгч хөтөч дээр идэвхтэй байх үед идэвхтэй байгаа хэрэглэгчийн сешнүүдийн талаарх өгөгдлийг хадгалахад үйлчилдэг. Эдгээр кэш нь эцсийн хэрэглэгчдийн HTTP хүсэлтийг боловсруулах программтай ажилладаг тул тэдгээр нь наалдамхай сессүүдтэй холбоотой бөгөөд мэдээллийн төвүүдийн хооронд хуулбарлах ёстой.

Харгис хүчний хамгаалалт. Кэш loginFailures Хэрэглэгч хэдэн удаа нууц үгээ буруу оруулсан гэх мэт нэвтрэх алдааны өгөгдлийг хянахад ашигладаг. Энэ кэшийг хуулбарлах нь администраторын үүрэг юм. Гэхдээ үнэн зөв тооцоолохын тулд мэдээллийн төвүүдийн хоорондох хуулбарыг идэвхжүүлэх нь зүйтэй. Гэхдээ нөгөө талаас, хэрэв та энэ өгөгдлийг хуулбарлахгүй бол та гүйцэтгэлийг сайжруулах болно, хэрэв энэ асуудал гарвал хуулбарлах ажиллагаа идэвхжихгүй байж магадгүй юм.

Infinispan кластерийг гаргахдаа тохиргооны файлд кэшийн тодорхойлолтыг нэмэх шаардлагатай.

<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 кластерийг эхлүүлэхийн өмнө Infinispan кластерийг тохируулж, эхлүүлэх ёстой

Дараа нь та тохируулах хэрэгтэй remoteStore Keycloak кэшүүдэд зориулсан. Үүнийг хийхийн тулд хувьсагчийг тохируулахад ашигладаг өмнөхтэй адил скрипт хийхэд хангалттай. CACHE_OWNERS, та үүнийг файлд хадгалж, директорт оруулах хэрэгтэй /opt/jboss/startup-scripts:

Скриптийн агуулга

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

Суулгахаа бүү мартаарай JAVA_OPTS HotRod-г ажиллуулахын тулд Keycloak зангилааны хувьд: remote.cache.host, remote.cache.port болон үйлчилгээний нэр jboss.site.name.

Холбоос болон нэмэлт баримт бичиг

Уг нийтлэлийг ажилчид орчуулан Хабр сэтгүүлд зориулан бэлтгэсэн Slurm сургалтын төв - дадлагажигч мэргэжилтнүүдийн эрчимжүүлсэн курс, видео курс, корпорацийн сургалт (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх