ProHoster > Օրագիր > Վարչակազմը > Աշխատում է Keycloak-ը HA ռեժիմով Kubernetes-ում

Աշխատում է Keycloak-ը HA ռեժիմով Kubernetes-ում

Աշխատում է Keycloak-ը HA ռեժիմով Kubernetes-ում

TL. DRԿլինեն Keycloak-ի նկարագրությունը, բաց կոդով մուտքի վերահսկման համակարգ, ներքին կառուցվածքի վերլուծություն, կոնֆիգուրացիայի մանրամասներ:

Ներածություն և հիմնական գաղափարներ

Այս հոդվածում մենք կտեսնենք հիմնական գաղափարները, որոնք պետք է հիշել Kubernetes-ի վերևում Keycloak կլաստերը տեղակայելիս:

Եթե ​​ցանկանում եք ավելին իմանալ Keycloak-ի մասին, տես հոդվածի վերջում գտնվող հղումները: Որպեսզի ավելի խորասուզվեք գործնականում, կարող եք սովորել մեր պահոցը մոդուլով, որն իրականացնում է այս հոդվածի հիմնական գաղափարները (գործարկման ուղեցույցը կա, այս հոդվածը կտրամադրի սարքի և պարամետրերի ակնարկ, մոտ. թարգմանիչ).

Keycloak-ը Java-ով գրված համապարփակ համակարգ է և կառուցված հավելվածի սերվերի վրա Wildfly. Մի խոսքով, դա թույլտվության շրջանակ է, որը հավելվածի օգտատերերին տալիս է ֆեդերացիա և SSO (մեկ գրանցում) հնարավորություններ:

Հրավիրում ենք կարդալ պաշտոնական կայքը կամ Վիքիպեդիա մանրամասն հասկանալու համար։

Keycloak-ի գործարկում

Keycloak-ը գործարկելու համար պահանջում է տվյալների երկու մշտական ​​աղբյուր.

  • Տվյալների բազա, որն օգտագործվում է հաստատված տվյալների պահպանման համար, ինչպիսիք են օգտատիրոջ տվյալները
  • Տվյալների ցանցի քեշը, որն օգտագործվում է տվյալների բազայից տվյալների քեշավորման համար, ինչպես նաև որոշ կարճատև և հաճախ փոփոխվող մետատվյալներ պահելու համար, ինչպիսիք են օգտագործողի նիստերը: Իրականացվել է Infinispan, որը սովորաբար զգալիորեն ավելի արագ է, քան տվյալների բազան։ Բայց ամեն դեպքում, Infinispan-ում պահպանված տվյալները ժամանակավոր են, և դրանք որևէ տեղ պահելու կարիք չկա, երբ կլաստերը վերագործարկվի:

Keycloak-ն աշխատում է չորս տարբեր ռեժիմներով.

  • սովորական - մեկ և միայն մեկ գործընթաց, որը կազմաձևված է ֆայլի միջոցով standalone.xml
  • Կանոնավոր կլաստեր (բարձր հասանելիության տարբերակ) - բոլոր գործընթացները պետք է օգտագործեն նույն կոնֆիգուրացիան, որը պետք է համաժամեցվի ձեռքով: Կարգավորումները պահվում են ֆայլում standalone-ha.xml, բացի այդ, դուք պետք է ընդհանուր մուտք գործեք տվյալների բազա և բեռի հավասարակշռող սարք:
  • Դոմենի կլաստեր — Կլաստերը նորմալ ռեժիմով սկսելը արագ դառնում է սովորական և ձանձրալի խնդիր, քանի որ կլաստերը մեծանում է, քանի որ ամեն անգամ, երբ կոնֆիգուրացիան փոխվում է, բոլոր փոփոխությունները պետք է կատարվեն յուրաքանչյուր կլաստերի հանգույցում: Դոմենի շահագործման ռեժիմը լուծում է այս խնդիրը՝ կարգավորելով ընդհանուր պահեստային տեղակայումը և հրապարակելով կազմաձևումը: Այս կարգավորումները պահվում են ֆայլում domain.xml
  • Կրկնօրինակում տվյալների կենտրոնների միջև — եթե ցանկանում եք գործարկել Keycloak-ը մի քանի տվյալների կենտրոնների կլաստերում, առավել հաճախ՝ տարբեր աշխարհագրական վայրերում: Այս տարբերակում յուրաքանչյուր տվյալների կենտրոն կունենա Keycloak սերվերների իր կլաստերը:

Այս հոդվածում մենք մանրամասնորեն կքննարկենք երկրորդ տարբերակը, այսինքն կանոնավոր կլաստեր, և մենք նաև մի փոքր կանդրադառնանք տվյալների կենտրոնների միջև կրկնօրինակման թեմային, քանի որ իմաստ ունի այս երկու տարբերակները գործարկել Kubernetes-ում: Բարեբախտաբար, Kubernetes-ում խնդիր չկա մի քանի պատիճների (Keycloak հանգույցների) կարգավորումների համաժամացման հետ կապված, այնպես որ. տիրույթի կլաստեր Դա անելն այնքան էլ դժվար չի լինի։

Նաև խնդրում ենք նկատի ունենալ, որ բառը կլաստեր Հոդվածի մնացած մասի համար կկիրառվի բացառապես Keycloak հանգույցների մի խումբ, որոնք աշխատում են միասին, կարիք չկա անդրադառնալ Kubernetes կլաստերին:

Կանոնավոր Keycloak կլաստեր

Keycloak-ն այս ռեժիմում գործարկելու համար ձեզ հարկավոր է.

  • կարգավորել արտաքին ընդհանուր տվյալների բազան
  • տեղադրել բեռի հավասարակշռող սարք
  • ունենալ ներքին ցանց՝ IP multicast աջակցությամբ

Մենք չենք քննարկի արտաքին տվյալների բազա ստեղծելու հարցը, քանի որ դա այս հոդվածի նպատակը չէ: Ենթադրենք, որ ինչ-որ տեղ կա աշխատանքային տվյալների բազա, և մենք դրա հետ կապի կետ ունենք: Մենք պարզապես կավելացնենք այս տվյալները շրջակա միջավայրի փոփոխականներին:

Ավելի լավ հասկանալու համար, թե ինչպես է Keycloak-ը աշխատում failover (HA) կլաստերում, կարևոր է իմանալ, թե որքանով է ամեն ինչ կախված Wildfly-ի կլաստերավորման հնարավորություններից:

Wildfly-ն օգտագործում է մի քանի ենթահամակարգեր, որոնցից ոմանք օգտագործվում են որպես բեռի հավասարակշռող, որոշները՝ սխալների հանդուրժողականության համար: Բեռի հավասարակշռիչը ապահովում է հավելվածի հասանելիությունը, երբ կլաստերի հանգույցը գերբեռնված է, իսկ սխալների հանդուրժողականությունը ապահովում է հավելվածի հասանելիությունը նույնիսկ եթե որոշ կլաստերային հանգույցներ ձախողվում են: Այս ենթահամակարգերից մի քանիսը.

  • mod_clusterԱշխատում է Apache-ի հետ համատեղ՝ որպես HTTP բեռի հավասարակշռող, կախված է TCP multicast-ից՝ լռելյայն հոսթեր գտնելու համար: Կարող է փոխարինվել արտաքին հավասարակշռողով։

  • infinispanԲաշխված քեշ՝ օգտագործելով JGroups ալիքները որպես տրանսպորտային շերտ: Բացի այդ, այն կարող է օգտագործել HotRod արձանագրությունը արտաքին Infinispan կլաստերի հետ շփվելու համար՝ քեշի բովանդակությունը համաժամեցնելու համար:

  • jgroupsՏրամադրում է խմբային հաղորդակցման աջակցություն JGroups ալիքների վրա հիմնված բարձր հասանելի ծառայությունների համար: Անվանված խողովակները թույլ են տալիս կլաստերի կիրառման օրինակները միացնել խմբերի, որպեսզի հաղորդակցությունն ունենա այնպիսի հատկություններ, ինչպիսիք են հուսալիությունը, կարգուկանոնը և խափանումների նկատմամբ զգայունությունը:

Load Balancer

Կուբերնետես կլաստերում որպես ներթափանցման վերահսկիչ հավասարակշռող տեղադրելիս կարևոր է հիշել հետևյալը.

Keycloak-ը ենթադրում է, որ HTTP-ի միջոցով վավերացման սերվերին միացող հաճախորդի հեռավոր հասցեն հաճախորդի համակարգչի իրական IP հասցեն է: Balancer-ի և ingress-ի կարգավորումները պետք է ճիշտ սահմանեն 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 նիշերի սահմանաչափի մասին, այնպես որ ավելի լավ է օգտագործել StatefulSet-ը, այլ ոչ թե Deployment:

Մեկ այլ փոցխ - եթե պատիճը ջնջվի կամ վերագործարկվի, դրա քեշը կորչում է: Հաշվի առնելով դա՝ արժե բոլոր քեշերի համար քեշի սեփականատերերի թիվը սահմանել առնվազն երկու, որպեսզի մնա քեշի պատճենը։ Լուծումը վազելն է սցենար Wildfly-ի համար պատիճը սկսելիս՝ տեղադրելով այն գրացուցակում /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, Multicast-ը անմիջապես կաշխատի, և ձեր Keycloak հանգույցները կտեսնեն միմյանց, հենց որ գործարկվեն:

Եթե ​​դուք չունեք ip multicast աջակցություն ձեր Kubernetes կլաստերում, կարող եք կարգավորել JGroups-ը, որպեսզի աշխատի այլ արձանագրությունների հետ՝ հանգույցներ գտնելու համար:

Առաջին տարբերակը օգտագործելն է KUBE_DNSորն օգտագործում է headless service Keycloak հանգույցները գտնելու համար դուք պարզապես փոխանցում եք JGroups ծառայության անունը, որը կօգտագործվի հանգույցները գտնելու համար:

Մեկ այլ տարբերակ է օգտագործել մեթոդը KUBE_PING, որն աշխատում է API-ի հետ՝ հանգույցներ որոնելու համար (դուք պետք է կազմաձևեք serviceAccount իրավունքներով list и get, և այնուհետև կարգավորեք պատիճները, որպեսզի աշխատեն դրա հետ serviceAccount).

JGroups-ը հանգույցներ գտնելու ձևը կազմաձևվում է շրջակա միջավայրի փոփոխականների սահմանմամբ JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES: Համար KUBE_PING դուք պետք է ընտրեք պատյաններ՝ հարցնելով namespace и labels.

️ Եթե դուք օգտագործում եք multicast և գործարկում եք երկու կամ ավելի Keycloak կլաստերներ մեկ Kubernetes կլաստերի մեջ (ասենք մեկը անվանատարածքում production, երկրորդ - staging) - Keycloak կլաստերի մեկ հանգույցները կարող են միանալ մեկ այլ կլաստերի: Համոզվեք, որ յուրաքանչյուր կլաստերի համար օգտագործեք եզակի բազմակի հեռարձակման հասցե՝ փոփոխականներ դնելովjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Կրկնօրինակում տվյալների կենտրոնների միջև

Աշխատում է Keycloak-ը HA ռեժիմով Kubernetes-ում

ՈՒղեցույց

Keycloak-ն օգտագործում է բազմաթիվ առանձին Infinispan քեշի կլաստերներ յուրաքանչյուր տվյալների կենտրոնի համար, որտեղ տեղակայված են Keycloak հանգույցներից կազմված Keycloack կլաստերները: Բայց տարբեր տվյալների կենտրոններում Keycloak հանգույցների միջև տարբերություն չկա:

Keycloak հանգույցներն օգտագործում են արտաքին Java Data Grid (Infinispan սերվերներ) տվյալների կենտրոնների միջև հաղորդակցության համար: Կապն աշխատում է ըստ արձանագրության Infinispan HotRod.

Infinispan քեշերը պետք է կազմաձևվեն հատկանիշով remoteStore, որպեսզի տվյալները հնարավոր լինի պահել հեռակա կարգով (այլ տվյալների կենտրոնում, մոտ. թարգմանիչ) պահոցներ. JDG սերվերների մեջ կան առանձին infinispan կլաստերներ, որպեսզի JDG1-ում պահվող տվյալները տեղում site1 Կայքում կկրկնօրինակվի JDG2-ին site2.

Եվ վերջապես, ստացող JDG սերվերը ծանուցում է Keycloak սերվերներին իր կլաստերի մասին՝ հաճախորդների կապերի միջոցով, ինչը HotRod արձանագրության առանձնահատկությունն է։ Keycloak հանգույցները միացված են site2 թարմացնել իրենց Infinispan քեշերը, և օգտագործողի կոնկրետ նիստը հասանելի է դառնում նաև Keycloak հանգույցների վրա site2.

Որոշ քեշերի համար հնարավոր է նաև կրկնօրինակումներ չանել և ամբողջությամբ խուսափել Infinispan սերվերի միջոցով տվյալներ գրելուց: Դա անելու համար դուք պետք է հեռացնեք կարգավորումը remote-store կոնկրետ Infinispan քեշ (ֆայլում standalone-ha.xml), որից հետո որոշ կոնկրետ replicated-cache Նաև այլևս կարիք չի լինի Infinispan սերվերի կողմից:

Քեշերի տեղադրում

Keycloak-ում երկու տեսակի քեշ կա.

  • Տեղական. Այն գտնվում է տվյալների բազայի կողքին և ծառայում է տվյալների բազայի ծանրաբեռնվածության նվազեցմանը, ինչպես նաև պատասխանների ուշացման նվազեցմանը։ Այս տեսակի քեշը պահպանում է տիրույթը, հաճախորդները, դերերը և օգտագործողի մետատվյալները: Այս տեսակի քեշը չի կրկնօրինակվում, նույնիսկ եթե քեշը Keycloak կլաստերի մի մասն է: Եթե ​​քեշում գրառումը փոխվում է, փոփոխության մասին հաղորդագրություն է ուղարկվում կլաստերի մնացած սերվերներին, որից հետո մուտքը բացառվում է քեշից: Տես նկարագրությունը work Ընթացակարգի ավելի մանրամասն նկարագրության համար տե՛ս ստորև:

  • Կրկնօրինակված: Մշակում է օգտատերերի նիստերը, անցանց նշանները, ինչպես նաև վերահսկում է մուտքի սխալները՝ գաղտնաբառի ֆիշինգի փորձերը և այլ հարձակումները հայտնաբերելու համար: Այս քեշերում պահվող տվյալները ժամանակավոր են, պահվում են միայն RAM-ում, բայց կարող են կրկնօրինակվել կլաստերի վրա:

Infinispan պահոցներ

Նիստեր - հայեցակարգ Keycloak-ում, որը կոչվում է առանձին քեշ authenticationSessions, օգտագործվում են հատուկ օգտվողների տվյալները պահելու համար: Այս քեշերից հարցումները սովորաբար անհրաժեշտ են զննարկիչին և Keycloak սերվերներին, այլ ոչ թե հավելվածներին: Հենց այստեղ է ի հայտ գալիս կախվածությունը կպչուն սեսիաներից, և այդպիսի քեշերը ինքնին կրկնօրինակման կարիք չունեն, նույնիսկ Active-Active ռեժիմի դեպքում:

Գործողությունների նշաններ. Մեկ այլ հայեցակարգ, որը սովորաբար օգտագործվում է տարբեր սցենարների համար, երբ, օրինակ, օգտվողը պետք է ինչ-որ բան ասինխրոն կերպով անի փոստով: Օրինակ, ընթացակարգի ընթացքում 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" />

Դուք պետք է կարգավորեք և գործարկեք Infinispan կլաստերը նախքան Keycloak կլաստերը սկսելը

Ապա դուք պետք է կարգավորեք 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 Keycloak հանգույցների համար HotRod-ը գործարկելու համար. remote.cache.host, remote.cache.port և ծառայության անվանումը jboss.site.name.

Հղումներ և լրացուցիչ փաստաթղթեր

Հոդվածը թարգմանվել և պատրաստվել է Հաբրի համար աշխատակիցների կողմից Slurm ուսումնական կենտրոն — ինտենսիվ դասընթացներ, վիդեո դասընթացներ և կորպորատիվ ուսուցում գործող մասնագետներից (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Source: www.habr.com

Добавить комментарий