قم بتشغيل Keycloak في وضع HA على Kubernetes

قم بتشغيل Keycloak في وضع HA على Kubernetes

TL؛ DR: سيكون هناك وصف Keycloak ، وهو نظام تحكم في الوصول مفتوح المصدر ، وتحليل للجهاز الداخلي ، وتفاصيل التكوين.

المقدمة والأفكار الرئيسية

في هذه المقالة ، سنرى الأفكار الرئيسية التي يجب وضعها في الاعتبار عند نشر مجموعة Keycloak أعلى Kubernetes.

إذا كنت تريد معرفة المزيد عن Keycloak ، فيرجى الرجوع إلى الروابط الموجودة في نهاية المقالة. من أجل الانغماس بشكل أعمق في الممارسة ، يمكنك الدراسة مستودعنا مع وحدة تنفذ الأفكار الرئيسية لهذه المقالة (دليل التشغيل موجود ، في هذه المقالة سيكون هناك نظرة عامة على الجهاز والإعدادات ، تقريبا. مترجم).

Keycloak هو نظام معقد مكتوب بلغة Java ومبني على خادم التطبيق. ذبابة البرية. باختصار ، إنه إطار تفويض يمنح مستخدمي التطبيق إمكانية اتحاد وتسجيل الدخول الأحادي (SSO).

ندعوك لقراءة المسؤول موقع أو ويكيبيديا لفهم مفصل.

ابدأ Keycloak

يحتاج Keycloak إلى مصدري بيانات دائمين للتشغيل:

  • قاعدة بيانات تُستخدم لتخزين البيانات الدائمة ، مثل معلومات حول المستخدمين
  • ذاكرة التخزين المؤقت Datagrid ، والتي تُستخدم لتخزين البيانات من قاعدة البيانات مؤقتًا ، وكذلك لتخزين بعض البيانات الوصفية قصيرة العمر والتي يتم تغييرها بشكل متكرر ، مثل جلسات المستخدم. مطلق سراحه إنفينيسبان، والتي عادة ما تكون أسرع بكثير من قاعدة البيانات. ولكن على أي حال ، فإن البيانات المحفوظة في Infinispan سريعة الزوال - ولا يلزم حفظها في مكان ما عند إعادة تشغيل الكتلة.

يعمل Keycloak في أربعة أوضاع مختلفة:

  • عادي - عملية واحدة فقط ، يتم تكوينها من خلال ملف مستقل. xml
  • الكتلة العادية (خيار متاح للغاية) - يجب أن تستخدم جميع العمليات نفس التكوين ، والذي يجب مزامنته يدويًا. يتم تخزين الإعدادات في ملف مستقل ha.xml، بالإضافة إلى ذلك ، تحتاج إلى إجراء وصول مشترك إلى قاعدة البيانات وموازن التحميل.
  • كتلة المجال - يصبح بدء الكتلة في الوضع العادي بسرعة مهمة روتينية ومملة مع نمو الكتلة ، لأنه في كل مرة يتم فيها تغيير التكوين ، يجب إجراء جميع التغييرات على كل عقدة في الكتلة. يعمل وضع المجال للعملية على حل هذه المشكلة عن طريق إعداد بعض التخزين المشترك ونشر التكوين. يتم تخزين هذه الإعدادات في ملف domain.xml
  • النسخ المتماثل بين مراكز البيانات - في حالة رغبتك في تشغيل Keycloak في مجموعة من عدة مراكز بيانات ، غالبًا في مواقع جغرافية مختلفة. في هذا الخيار ، سيكون لكل مركز بيانات مجموعته الخاصة من خوادم Keycloak.

في هذه المقالة سوف نلقي نظرة فاحصة على الخيار الثاني ، أي الكتلة العادية، بالإضافة إلى القليل من اللمس حول موضوع النسخ المتماثل بين مراكز البيانات ، لأنه من المنطقي تشغيل هذين الخيارين في Kubernetes. لحسن الحظ ، لا تواجه Kubernetes مشكلة في مزامنة إعدادات البودات المتعددة (عقد Keycloak) ، لذلك كتلة المجال لن يكون من الصعب جدا القيام به.

كما يرجى ملاحظة أن الكلمة تَجَمَّع حتى نهاية المقالة ستنطبق فقط على مجموعة من عقد Keycloak تعمل معًا ، ليست هناك حاجة للإشارة إلى مجموعة Kubernetes.

مجموعة Keycloak العادية

لتشغيل Keycloak في هذا الوضع ، تحتاج إلى:

  • إنشاء قاعدة بيانات خارجية مشتركة
  • تثبيت موازن التحميل
  • لديك شبكة داخلية مع دعم البث المتعدد عبر بروتوكول الإنترنت

لن نقوم بتحليل تكوين قاعدة البيانات الخارجية ، لأنه ليس الغرض من هذه المقالة. لنفترض أنه توجد في مكان ما قاعدة بيانات عاملة - ولدينا نقطة اتصال بها. سنقوم ببساطة بإضافة هذه البيانات إلى متغيرات البيئة.

لفهم كيفية عمل Keycloak بشكل أفضل في مجموعة تجاوز الفشل (HA) ، من المهم معرفة مدى اعتماد كل ذلك على قدرات Wildfly العنقودية.

يستخدم Wildfly عدة أنظمة فرعية ، بعضها يستخدم كموازن تحميل ، وبعضها يستخدم لتجاوز الفشل. يضمن موازن التحميل توفر التطبيق عند تحميل عقدة نظام المجموعة بشكل زائد ، ويضمن تجاوز الفشل توفر التطبيق حتى في حالة فشل بعض عقد المجموعة. بعض هذه الأنظمة الفرعية هي:

  • mod_cluster: يعمل جنبًا إلى جنب مع Apache كموازن تحميل HTTP ، ويعتمد على الإرسال المتعدد لـ TCP لاكتشاف المضيف الافتراضي. يمكن استبداله بميزان خارجي.

  • infinispan: ذاكرة التخزين المؤقت الموزعة باستخدام قنوات JGroups كطبقة نقل. اختياريًا ، يمكنه استخدام بروتوكول HotRod للتواصل مع مجموعة Infinispan خارجية لمزامنة محتويات ذاكرة التخزين المؤقت.

  • 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 فريد لكل عقدة - على سبيل المثال ، يمكنك تعيين اسم الكبسولة. إذا وضعت اسم الكبسولة - لا تنسَ الحد الأقصى لعدد الأحرف البالغ 23 حرفًا لمتغيرات jboss ، لذلك من الأفضل استخدام 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 الخاص بك ، فسيعمل البث المتعدد على الفور - وسوف ترى عقد 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.

️ إذا كنت تستخدم الإرسال المتعدد وقمت بتشغيل مجموعتين أو أكثر من مجموعات Keycloak في نفس مجموعة Kubernetes (دعنا نقول واحدة في مساحة الاسم production، ثانية - staging) - يمكن للعقد من مجموعة Keycloak الانضمام إلى مجموعة أخرى. تأكد من استخدام عنوان الإرسال المتعدد الفريد لكل مجموعة عن طريق تعيين المتغيراتjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

النسخ المتماثل بين مراكز البيانات

قم بتشغيل Keycloak في وضع HA على Kubernetes

رابط

يستخدم Keycloak عدة مجموعات منفصلة لذاكرة التخزين المؤقت Infinispan لكل مركز بيانات يستضيف مجموعات Keycloack المكونة من عقد Keycloak. ولكن في الوقت نفسه ، لا يوجد فرق بين عقد Keycloak في مراكز البيانات المختلفة.

تستخدم عقد Keycloak شبكة بيانات جافا خارجية (خوادم Infinispan) للتواصل بين مراكز البيانات. يعمل الاتصال وفقًا للبروتوكول إنفينيسبان هوت رود.

يجب تكوين ذاكرة التخزين المؤقت Infinispan باستخدام السمة remoteStore، بحيث يمكن تخزين البيانات في مكان بعيد (في مركز بيانات آخر ، تقريبا. مترجم) مخابئ. توجد مجموعات منفصلة من مجموعات Infinispan بين خوادم JDG ، لذلك يتم تخزين البيانات على JDG1 في الموقع site1 سيتم نسخها إلى JDG2 في الموقع site2.

أخيرًا ، يقوم خادم JDG المستلم بإخطار خوادم Keycloak الخاصة بالعنقود عبر اتصالات العميل ، وهي إحدى ميزات بروتوكول HotRod. تم تشغيل عقد Keycloak site2 تحديث ذاكرة التخزين المؤقت Infinispan الخاصة بهم وتصبح جلسة المستخدم الخاصة متاحة على عقد Keycloak الموجودة على site2.

من الممكن أيضًا عدم إجراء نسخ احتياطي لبعض ذاكرات التخزين المؤقت ورفض تمامًا كتابة البيانات من خلال خادم Infinispan. للقيام بذلك ، تحتاج إلى إزالة الإعداد remote-store ذاكرة التخزين المؤقت Infinispan المحددة (في ملف مستقل 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" />

يجب تكوين مجموعة 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.

روابط ووثائق إضافية

تمت ترجمة المقال وإعداده لحبر من قبل موظفين مركز تدريب سلورم - دورات مكثفة عبر الفيديو وتدريب الشركات من الممارسين (Kubernetes و DevOps و Docker و Ansible و Ceph و SRE)

المصدر: www.habr.com

إضافة تعليق