🥇Kubernetes жүйесінде HA режимінде Keycloak іске қосылуда

TL; DR: Keycloak сипаттамасы, ашық бастапқы қолжетімділікті басқару жүйесі, ішкі құрылымның талдауы, конфигурация мәліметтері болады.

Кіріспе және негізгі идеялар

Бұл мақалада біз Kubernetes үстіне Keycloak кластерін орналастыру кезінде есте сақтау керек негізгі идеяларды көреміз.

Егер сіз Keycloak туралы көбірек білгіңіз келсе, мақаланың соңындағы сілтемелерді қараңыз. Практикаға көбірек ену үшін оқуға болады біздің қойма осы мақаланың негізгі идеяларын жүзеге асыратын модульмен (іске қосу нұсқаулығы бар, бұл мақалада құрылғы мен параметрлерге шолу жасалады, шамамен. аудармашы).

Keycloak — Java тілінде жазылған және қолданба серверінің үстіне салынған кешенді жүйе Жабайы шыбын. Қысқаша айтқанда, бұл қолданба пайдаланушыларына федерация және SSO (бір рет кіру) мүмкіндіктерін беретін авторизация жүйесі.

Сізді ресми ақпаратты оқуға шақырамыз веб-сайт немесе Wikipedia егжей-тегжейлі түсіну үшін.

Keycloak іске қосылуда

Keycloak іске қосу үшін екі тұрақты деректер көзін қажет етеді:

Пайдаланушы ақпараты сияқты белгіленген деректерді сақтау үшін пайдаланылатын дерекқор
Деректер базасынан деректерді кэштеу үшін, сондай-ақ пайдаланушы сеанстары сияқты кейбір қысқа мерзімді және жиі өзгеретін метадеректерді сақтау үшін пайдаланылатын Datagrid кэші. Орындалды Инфиниспан, бұл әдетте дерекқорға қарағанда айтарлықтай жылдамырақ. Бірақ кез келген жағдайда Infinispan ішінде сақталған деректер эфемерлі болып табылады және кластер қайта іске қосылған кезде оны еш жерде сақтау қажет емес.

Keycloak төрт түрлі режимде жұмыс істейді:

әдеттегі - файл арқылы конфигурацияланған бір ғана процесс standalone.xml
Тұрақты кластер (жоғары қолжетімділік опциясы) - барлық процестер бірдей конфигурацияны пайдалануы керек, ол қолмен синхрондалу керек. Параметрлер файлда сақталады standalone-ha.xml, сонымен қатар дерекқорға және жүктеме теңестірушіге ортақ қатынас жасау керек.
Домен кластері — кластерді қалыпты режимде іске қосу кластер өскен сайын кәдімгі және қызықсыз тапсырмаға айналады, өйткені конфигурация өзгерген сайын барлық өзгерістер әрбір кластер түйінінде жасалуы керек. Домен жұмыс режимі бұл мәселені кейбір ортақ сақтау орнын орнату және конфигурацияны жариялау арқылы шешеді. Бұл параметрлер файлда сақталады domain.xml
Деректер орталықтары арасындағы репликация — егер сіз Keycloak бағдарламасын бірнеше деректер орталықтарының кластерінде, көбінесе әртүрлі географиялық орындарда іске қосқыңыз келсе. Бұл опцияда әрбір деректер орталығында Keycloak серверлерінің жеке кластері болады.

Бұл мақалада біз екінші нұсқаны егжей-тегжейлі қарастырамыз, яғни тұрақты кластер, және біз деректер орталықтары арасындағы репликация тақырыбына да тоқталамыз, өйткені Kubernetes-те осы екі опцияны іске қосу мағынасы бар. Бақытымызға орай, Kubernetes-те бірнеше қосқыштардың (Keycloak түйіндері) параметрлерін синхрондау проблемасы жоқ, сондықтан домен кластері Мұны істеу өте қиын болмайды.

Бұл сөзді де ескеріңіз кластер мақаланың қалған бөлігі тек бірге жұмыс істейтін Keycloak түйіндер тобына қатысты болады, Kubernetes кластеріне сілтеме жасаудың қажеті жоқ.

Тұрақты Keycloak кластері

Keycloak-ті осы режимде іске қосу үшін сізге қажет:

сыртқы ортақ дерекқорды конфигурациялау
жүктеме балансын орнатыңыз
IP мультикаст қолдауы бар ішкі желі бар

Біз сыртқы дерекқорды орнатуды талқыламаймыз, себебі бұл мақаланың мақсаты емес. Бір жерде жұмыс істейтін деректер базасы бар деп есептейік - және бізде оған қосылу нүктесі бар. Біз бұл деректерді орта айнымалыларына жай ғана қосамыз.

Keycloak ауыстырып-қосу (HA) кластерінде қалай жұмыс істейтінін жақсырақ түсіну үшін оның барлығы Wildfly кластерлеу мүмкіндіктеріне қаншалықты тәуелді екенін білу маңызды.

Wildfly бірнеше ішкі жүйелерді пайдаланады, олардың кейбіреулері жүктемені теңестіру үшін, кейбіреулері ақауларға төзімділік үшін пайдаланылады. Жүктеме теңестіруші кластер түйіні шамадан тыс жүктелген кезде қолданбаның қолжетімділігін қамтамасыз етеді және қатеге төзімділік кейбір кластер түйіндері сәтсіз болса да қолданбаның қолжетімділігін қамтамасыз етеді. Осы ішкі жүйелердің кейбірі:

mod_cluster: HTTP жүктеме теңестірушісі ретінде Apache-мен бірге жұмыс істейді, әдепкі бойынша хосттарды табу үшін TCP мультикастына байланысты. Сыртқы балансизатормен ауыстыруға болады.
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 кэшін пайдаланады. Кэштер әдепкі бойынша бір иеленушімен жұмыс істейді, басқаша айтқанда, сол нақты сеанс кластердегі кейбір түйінде сақталады және басқа түйіндер сол сеансқа кіру қажет болса, оны қашықтан сұрауы керек.

Атап айтқанда, құжаттамаға қарамастан, cookie атауы бар сеансты тіркеу біз үшін жұмыс істемеді AUTH_SESSION_ID. Keycloak бағдарламасында қайта бағыттау циклі бар, сондықтан жабысқақ сеанс үшін басқа cookie атын таңдауды ұсынамыз.

Keycloak сонымен қатар бірінші жауап берген түйіннің атын қосады AUTH_SESSION_ID, және жоғары қолжетімді нұсқадағы әрбір түйін бірдей дерекқорды пайдаланатындықтан, олардың әрқайсысы болуы керек транзакцияларды басқаруға арналған жеке және бірегей түйін идентификаторы. қою ұсынылады JAVA_OPTS параметрлері jboss.node.name и jboss.tx.node.id әрбір түйін үшін бірегей - сіз, мысалы, подкасттың атын қоюға болады. Егер сіз подкаст атауын қойсаңыз, jboss айнымалылары үшін 23 таңбалық шектеу туралы ұмытпаңыз, сондықтан Deployment емес, StatefulSet пайдаланған дұрыс.

Басқа рейк - егер подвод жойылса немесе қайта іске қосылса, оның кэш жоғалады. Осыны ескере отырып, кэштің көшірмесі қалатындай етіп, барлық кэштер үшін кэш иелерінің санын кемінде екіге орнатқан жөн. Шешім - жүгіру 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 мультикастты қолдауы бар жеке желі

Weavenet-ті CNI ретінде пайдалансаңыз, мультикаст дереу жұмыс істейді - және Keycloak түйіндері іске қосылғаннан кейін бір-бірін көреді.

Kubernetes кластерінде IP мультикаст қолдауы болмаса, 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.

️ Егер сіз мультикастты пайдалансаңыз және бір Kubernetes кластерінде екі немесе одан да көп Keycloak кластерін іске қоссаңыз (аттар кеңістігінде біреуін айтайық) production, екінші - staging) - бір Keycloak кластерінің түйіндері басқа кластерге қосыла алады. Айнымалы мәндерді орнату арқылы әрбір кластер үшін бірегей мультикаст мекенжайын пайдалануды ұмытпаңызjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Деректер орталықтары арасындағы репликация

Қосылу мүмкіндігі

Keycloak Keycloak түйіндерінен тұратын Keycloack кластерлері орналасқан әрбір деректер орталығы үшін бірнеше бөлек Infinispan кэш кластерлерін пайдаланады. Бірақ әртүрлі деректер орталықтарындағы Keycloak түйіндері арасында ешқандай айырмашылық жоқ.

Keycloak түйіндері деректер орталықтары арасындағы байланыс үшін сыртқы Java деректер торын (Infinispan серверлері) пайдаланады. Байланыс хаттама бойынша жұмыс істейді Infinispan HotRod.

Infinispan кэштері төлсипатпен конфигурациялануы керек remoteStore, деректерді қашықтан сақтауға болатындай (басқа деректер орталығында, шамамен. аудармашы) кэштер. JDG серверлерінің арасында жеке infinispan кластерлері бар, осылайша деректер JDG1 сайтында сақталады. site1 сайтында JDG2-ге көшіріледі site2.

Соңында, қабылдаушы JDG сервері HotRod протоколының ерекшелігі болып табылатын клиенттік қосылымдар арқылы өзінің кластері туралы Keycloak серверлеріне хабарлайды. Пернетақта түйіндері қосулы site2 олардың Infinispan кэштерін жаңартады және арнайы пайдаланушы сеансы қосылған Keycloak түйіндерінде де қолжетімді болады site2.

Кейбір кэштер үшін сақтық көшірме жасамауға және Infinispan сервері арқылы деректерді толығымен жазуға жол бермеуге болады. Мұны істеу үшін параметрді жою керек remote-store арнайы Infinispan кэші (файлда standalone-ha.xml), содан кейін кейбір нақты replicated-cache енді Infinispan сервер жағында қажет болмайды.

Кэштерді орнату

Keycloak-те кэштердің екі түрі бар:

Жергілікті. Ол мәліметтер қорының жанында орналасады және мәліметтер базасына жүктемені азайтуға, сонымен қатар жауап берудің кешігуін азайтуға қызмет етеді. Кэштің бұл түрі аймақты, клиенттерді, рөлдерді және пайдаланушы метадеректерін сақтайды. Кэштің бұл түрі, тіпті кэш Keycloak кластерінің бөлігі болса да, қайталанбайды. Кэштегі жазба өзгерсе, өзгерту туралы хабарлама кластердегі қалған серверлерге жіберіледі, содан кейін жазба кэштен шығарылады. Сипаттаманы қараңыз work Процедураның толығырақ сипаттамасын төменде қараңыз.
Қайталанған. Пайдаланушы сеанстарын, желіден тыс таңбалауыштарды өңдейді, сонымен қатар құпия сөзді фишингтік әрекеттерді және басқа шабуылдарды анықтау үшін кіру қателерін бақылайды. Бұл кэштерде сақталған деректер уақытша, тек жедел жадта сақталады, бірақ оларды кластер бойынша көшіруге болады.

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

Kubernetes жүйесінде HA режимінде Keycloak іске қосылуда