ProHoster > وبلاگ > اداره > Keycloak را در حالت HA در Kubernetes اجرا کنید

Keycloak را در حالت HA در Kubernetes اجرا کنید

Keycloak را در حالت HA در Kubernetes اجرا کنید

TL؛ DR: توضیحاتی در مورد Keycloak، یک سیستم کنترل دسترسی منبع باز، تجزیه و تحلیل دستگاه داخلی، جزئیات پیکربندی وجود خواهد داشت.

مقدمه و ایده های اصلی

در این مقاله، ایده های اصلی را که باید هنگام استقرار یک خوشه Keycloak در بالای Kubernetes در نظر داشته باشید، خواهیم دید.

اگر می خواهید در مورد Keycloak بیشتر بدانید، لطفاً به لینک های انتهای مقاله مراجعه کنید. برای اینکه خود را عمیق تر در تمرین غرق کنید، می توانید مطالعه کنید مخزن ما با ماژولی که ایده های اصلی این مقاله را پیاده سازی می کند (راهنمای راه اندازی وجود دارد، در این مقاله یک نمای کلی از دستگاه و تنظیمات وجود دارد، تقریبا مترجم).

Keycloak یک سیستم پیچیده است که به زبان جاوا نوشته شده و بر روی یک سرور برنامه ساخته شده است. مگس وحش. به طور خلاصه، این یک چارچوب مجوز است که به کاربران برنامه امکان فدراسیون و SSO (یک ورود) را می دهد.

شما را به خواندن رسمی دعوت می کنیم سایت اینترنتی یا ویکیپدیا برای درک دقیق

Keycloak را راه اندازی کنید

Keycloak برای اجرا به دو منبع داده پایدار نیاز دارد:

  • پایگاه داده ای که برای ذخیره داده های پایدار مانند اطلاعات کاربران استفاده می شود
  • کش دیتاگرید که برای کش کردن داده ها از پایگاه داده و همچنین برای ذخیره برخی متادیتاهای کوتاه مدت و اغلب تغییر یافته مانند جلسات کاربر استفاده می شود. منتشر شد Infinispan، که معمولاً به طور قابل توجهی سریعتر از پایگاه داده است. اما در هر صورت، داده های ذخیره شده در Infinispan زودگذر است - و نیازی به ذخیره شدن در جایی هنگام راه اندازی مجدد خوشه نیست.

Keycloak در چهار حالت مختلف کار می کند:

  • عادی - یک و تنها یک فرآیند، از طریق یک فایل پیکربندی شده است standalone.xml
  • خوشه منظم (گزینه بسیار در دسترس) - همه فرآیندها باید از یک پیکربندی استفاده کنند که باید به صورت دستی همگام شوند. تنظیمات در یک فایل ذخیره می شود standalone-ha.xmlعلاوه بر این، شما باید یک دسترسی مشترک به پایگاه داده و یک بار متعادل کننده داشته باشید.
  • خوشه دامنه - راه اندازی کلاستر در حالت عادی به سرعت به یک کار معمولی و خسته کننده تبدیل می شود، زیرا هر بار که پیکربندی را تغییر می دهید، باید تمام تغییرات را در هر گره از خوشه ایجاد کنید. حالت عملکرد دامنه این مشکل را با راه اندازی مقداری ذخیره سازی مشترک و انتشار پیکربندی حل می کند. این تنظیمات در یک فایل ذخیره می شوند domain.xml
  • تکرار بین مراکز داده - در صورتی که می خواهید Keycloak را در یک خوشه از چندین مرکز داده، اغلب در مکان های جغرافیایی مختلف اجرا کنید. در این گزینه، هر مرکز داده خوشه ای از سرورهای Keycloak خود را خواهد داشت.

در این مقاله نگاهی دقیق تر به گزینه دوم خواهیم داشت. خوشه نرمالو همچنین کمی به موضوع تکرار بین مراکز داده اشاره می کنیم، زیرا اجرای این دو گزینه در Kubernetes منطقی است. خوشبختانه Kubernetes با همگام سازی تنظیمات چند پاد (گره های Keycloak) مشکلی ندارد، بنابراین خوشه دامنه انجام آن خیلی سخت نخواهد بود.

همچنین لطفا توجه داشته باشید که کلمه خوشه تا پایان مقاله فقط برای گروهی از گره های Keycloak که با هم کار می کنند اعمال می شود، نیازی به مراجعه به خوشه Kubernetes نیست.

خوشه کلیدی منظم

برای اجرای Keycloak در این حالت، شما نیاز دارید:

  • یک پایگاه داده مشترک خارجی راه اندازی کنید
  • نصب بار متعادل کننده
  • یک شبکه داخلی با پشتیبانی از ip multicast داشته باشید

ما پیکربندی پایگاه داده خارجی را تجزیه و تحلیل نخواهیم کرد، زیرا هدف این مقاله نیست. بیایید فرض کنیم جایی یک پایگاه داده کار می کند - و ما یک نقطه اتصال به آن داریم. ما به سادگی این داده ها را به متغیرهای محیط اضافه می کنیم.

برای درک بهتر نحوه عملکرد Keycloak در یک خوشه failover (HA)، مهم است که بدانیم چقدر به توانایی های خوشه بندی Wildfly بستگی دارد.

Wildfly از چندین زیرسیستم استفاده می کند، برخی از آنها به عنوان متعادل کننده بار استفاده می شود، برخی برای failover استفاده می شود. متعادل کننده بار از در دسترس بودن برنامه زمانی که گره خوشه بیش از حد بارگذاری می شود اطمینان حاصل می کند، و Failover در دسترس بودن برنامه را حتی اگر برخی از گره های خوشه ای از کار بیفتند، تضمین می کند. برخی از این زیرسیستم ها عبارتند از:

  • 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 Multicast

اگر از Weavenet به‌عنوان CNI خود استفاده می‌کنید، چندپخشی فوراً کار می‌کند - و گره‌های Keycloak شما به محض راه‌اندازی و اجرا یکدیگر را می‌بینند.

اگر در خوشه Kubernetes خود پشتیبانی از IP Multicast ندارید، می توانید 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 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 برای ردیابی داده های خطای ورود، مانند تعداد دفعاتی که کاربر رمز عبور نادرست وارد کرده است، استفاده می شود. تکثیر این کش به عهده مدیر است. اما برای یک محاسبه دقیق، ارزش فعال کردن تکرار بین مراکز داده را دارد. اما از طرف دیگر، اگر این داده ها را تکرار نکنید، می توانید عملکرد را بهبود ببخشید و اگر این سوال پیش بیاید، ممکن است Replication فعال نشود.

هنگام راه اندازی یک خوشه 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 برای گره های Keycloak برای کار با HotRod: remote.cache.host, remote.cache.port و نام سرویس jboss.site.name.

پیوندها و اسناد اضافی

مقاله توسط کارمندان برای هابر ترجمه و تهیه شده است مرکز آموزش اسلرم - دوره های فشرده، دوره های ویدیویی و آموزش شرکتی از متخصصان (Kubernetes، DevOps، Docker، Ansible، Ceph، SRE)

منبع: www.habr.com

اضافه کردن نظر