Keycloak-ის გაშვება HA რეჟიმში Kubernetes-ზე

TL; DR: იქნება Keycloak-ის აღწერა, ღია კოდის წვდომის კონტროლის სისტემა, შიდა სტრუქტურის ანალიზი, კონფიგურაციის დეტალები.

შესავალი და ძირითადი იდეები

ამ სტატიაში ჩვენ ვიხილავთ ძირითად იდეებს, რომლებიც უნდა გვახსოვდეს Kubernetes-ის თავზე Keycloak კლასტერის განლაგებისას.

თუ გსურთ გაიგოთ მეტი Keycloak-ის შესახებ, იხილეთ ბმულები სტატიის ბოლოს. იმისათვის, რომ უფრო მეტად ჩაეფლო პრაქტიკაში, შეგიძლია ისწავლო ჩვენი საცავი მოდულით, რომელიც ახორციელებს ამ სტატიის მთავარ იდეებს (გაშვების სახელმძღვანელო იქ არის, ეს სტატია მოგაწვდით მოწყობილობისა და პარამეტრების მიმოხილვას, დაახლ. მთარგმნელი).

Keycloak არის ჯავაში დაწერილი ყოვლისმომცველი სისტემა და აგებულია აპლიკაციის სერვერზე გარეული ბუდე. მოკლედ, ეს არის ავტორიზაციის ჩარჩო, რომელიც აძლევს აპლიკაციის მომხმარებლებს ფედერაციის და SSO (ერთჯერადი შესვლის) შესაძლებლობებს.

გეპატიჟებით წაიკითხოთ ოფიციალური ნახვა ან ვიკიპედია დეტალური გაგებისთვის.

Keycloak-ის გაშვება

Keycloak საჭიროებს მონაცემთა ორ მუდმივ წყაროს გასაშვებად:

• მონაცემთა ბაზა, რომელიც გამოიყენება დადგენილი მონაცემების შესანახად, როგორიცაა მომხმარებლის ინფორმაცია
• მონაცემთა ბადის ქეში, რომელიც გამოიყენება მონაცემთა ბაზიდან მონაცემების შესანახად, ასევე ხანმოკლე და ხშირად ცვალებადი მეტამონაცემების შესანახად, როგორიცაა მომხმარებლის სესიები. განხორციელდა Infinispan, რომელიც ჩვეულებრივ საგრძნობლად უფრო სწრაფია ვიდრე მონაცემთა ბაზა. მაგრამ ნებისმიერ შემთხვევაში, Infinispan-ში შენახული მონაცემები ეფემერულია - და არ არის საჭირო სადმე შენახვა, როდესაც კლასტერი გადაიტვირთება.

Keycloak მუშაობს ოთხ სხვადასხვა რეჟიმში:

• ჩვეულებრივი - ერთი და მხოლოდ ერთი პროცესი, კონფიგურირებული ფაილის საშუალებით დამოუკიდებელი.xml
• რეგულარული კლასტერი (მაღალი ხელმისაწვდომობის ვარიანტი) - ყველა პროცესმა უნდა გამოიყენოს იგივე კონფიგურაცია, რომელიც უნდა იყოს სინქრონიზებული ხელით. პარამეტრები ინახება ფაილში standalone-ha.xml, გარდა ამისა, თქვენ უნდა გქონდეთ საერთო წვდომა მონაცემთა ბაზაზე და დატვირთვის ბალანსერი.
• დომენის კლასტერი — კლასტერის ნორმალურ რეჟიმში დაწყება სწრაფად ხდება რუტინული და მოსაწყენი ამოცანა, რადგან კლასტერი იზრდება, რადგან ყოველ ჯერზე, როცა კონფიგურაცია იცვლება, ყველა ცვლილება უნდა განხორციელდეს თითოეულ კლასტერულ კვანძზე. დომენის მუშაობის რეჟიმი ამ საკითხს წყვეტს საზიარო მეხსიერების მდებარეობის დაყენებით და კონფიგურაციის გამოქვეყნებით. ეს პარამეტრები ინახება ფაილში domain.xml
• რეპლიკაცია მონაცემთა ცენტრებს შორის — თუ გსურთ Keycloak-ის გაშვება რამდენიმე მონაცემთა ცენტრის კლასტერში, ყველაზე ხშირად სხვადასხვა გეოგრაფიულ ადგილას. ამ პარამეტრში, თითოეულ მონაცემთა ცენტრს ექნება Keycloak სერვერების საკუთარი კლასტერი.

ამ სტატიაში დეტალურად განვიხილავთ მეორე ვარიანტს, ანუ რეგულარული კლასტერიდა ჩვენ ასევე ცოტათი შევეხებით მონაცემთა ცენტრებს შორის რეპლიკაციის თემას, რადგან აზრი აქვს ამ ორი ვარიანტის გაშვებას Kubernetes-ში. საბედნიეროდ, Kubernetes-ში არ არის პრობლემა რამდენიმე პოდის (Keycloak კვანძების) პარამეტრების სინქრონიზაციისთვის. დომენის კლასტერი ამის გაკეთება არ იქნება ძალიან რთული.

ასევე გთხოვთ გაითვალისწინოთ, რომ სიტყვა მტევანი სტატიის დანარჩენი ნაწილისთვის გამოიყენება მხოლოდ Keycloak კვანძების ჯგუფზე, რომლებიც მუშაობენ ერთად, არ არის საჭირო Kubernetes კლასტერზე მითითება.

რეგულარული Keycloak კლასტერი

Keycloak ამ რეჟიმში გასაშვებად გჭირდებათ:

• გარე საერთო მონაცემთა ბაზის კონფიგურაცია
• დააინსტალირეთ დატვირთვის ბალანსერი
• აქვს შიდა ქსელი IP multicast მხარდაჭერით

ჩვენ არ განვიხილავთ გარე მონაცემთა ბაზის შექმნას, რადგან ეს არ არის ამ სტატიის მიზანი. დავუშვათ, რომ სადღაც არის სამუშაო მონაცემთა ბაზა - და ჩვენ გვაქვს მასთან კავშირის წერტილი. ჩვენ უბრალოდ დავამატებთ ამ მონაცემებს გარემოს ცვლადებს.

უკეთ რომ გავიგოთ, როგორ მუშაობს Keycloak ფაილვერის (HA) კლასტერში, მნიშვნელოვანია ვიცოდეთ, რამდენად არის ეს ყველაფერი დამოკიდებული Wildfly-ის კლასტერირების შესაძლებლობებზე.

Wildfly იყენებს რამდენიმე ქვესისტემას, ზოგი მათგანი გამოიყენება როგორც დატვირთვის დამაბალანსებელი, ზოგიც შეცდომების ტოლერანტობისთვის. დატვირთვის ბალანსერი უზრუნველყოფს აპლიკაციის ხელმისაწვდომობას, როდესაც კლასტერული კვანძი გადატვირთულია, ხოლო შეცდომის ტოლერანტობა უზრუნველყოფს აპლიკაციის ხელმისაწვდომობას მაშინაც კი, თუ ზოგიერთი კლასტერული კვანძი ვერ ხერხდება. ზოგიერთი ამ ქვესისტემადან:

• mod_cluster: მუშაობს Apache-თან ერთად, როგორც HTTP დატვირთვის ბალანსერი, დამოკიდებულია TCP multicast-ზე, რათა მოიძიოს ჰოსტები ნაგულისხმევად. შეიძლება შეიცვალოს გარე ბალანსერით.

• infinispan: განაწილებული ქეში JGroups არხების გამოყენებით სატრანსპორტო ფენად. გარდა ამისა, მას შეუძლია გამოიყენოს HotRod პროტოკოლი გარე Infinispan კლასტერთან კომუნიკაციისთვის ქეშის შინაარსის სინქრონიზაციისთვის.

• jgroups: უზრუნველყოფს ჯგუფური კომუნიკაციის მხარდაჭერას JGroups არხებზე დაფუძნებული მაღალ ხელმისაწვდომი სერვისებისთვის. დასახელებული მილები საშუალებას აძლევს კლასტერში აპლიკაციის შემთხვევებს დაკავშირდეს ჯგუფებად, რათა კომუნიკაციას ჰქონდეს ისეთი თვისებები, როგორიცაა საიმედოობა, მოწესრიგება და მგრძნობელობა წარუმატებლობის მიმართ.

დატვირთვის ბალანსერი

კუბერნეტის კლასტერში ბალანსერის, როგორც შეღწევის კონტროლერის დაყენებისას, მნიშვნელოვანია გახსოვდეთ შემდეგი:

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 სიმბოლოს ლიმიტი, ამიტომ უმჯობესია გამოიყენოთ 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 მულტიკასტის მხარდაჭერით

თუ იყენებთ 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 თქვენ უნდა აირჩიოთ pods კითხვით namespace и labels.

️ თუ იყენებთ multicast და აწარმოებთ ორ ან მეტ Keycloak კლასტერს ერთ Kubernetes კლასტერში (ვთქვათ ერთი სახელთა სივრცეში production, მეორე - staging) - ერთი Keycloak კლასტერის კვანძებს შეუძლიათ შეუერთდნენ მეორე კლასტერს. დარწმუნდით, რომ გამოიყენეთ უნიკალური მულტიკასტის მისამართი თითოეული კლასტერისთვის ცვლადების დაყენებითjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

რეპლიკაცია მონაცემთა ცენტრებს შორის

ლინკები

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 სერვერებისთვის და არა აპლიკაციებისთვის. აქ ჩნდება დამოკიდებულება წებოვან სესიებზე და თავად ასეთი ქეშები არ საჭიროებს გამეორებას, თუნდაც აქტიური-აქტიური რეჟიმის შემთხვევაში.

მოქმედების ნიშნები. კიდევ ერთი კონცეფცია, რომელიც ჩვეულებრივ გამოიყენება სხვადასხვა სცენარებისთვის, როდესაც, მაგალითად, მომხმარებელმა უნდა გააკეთოს რაიმე ასინქრონულად ფოსტით. მაგალითად, პროცედურის დროს 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.

ბმულები და დამატებითი დოკუმენტაცია

• 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

სტატია თანამშრომლებმა თარგმნეს და მოამზადეს ჰაბრისთვის Slurm სასწავლო ცენტრი - ინტენსიური კურსები, ვიდეო კურსები და კორპორატიული ტრენინგი პრაქტიკოსი სპეციალისტებისგან (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

წყარო: www.habr.com