🥇 Keycloak'ı Kubernetes'te HA modunda çalıştırma

TL; DR: Açık kaynak kodlu bir erişim kontrol sistemi olan Keycloak'ın tanımı, iç yapısının analizi, konfigürasyon detayları yer alacaktır.

Giriş ve Temel Fikirler

Bu yazıda Kubernetes üzerinde Keycloak kümesi dağıtırken akılda tutulması gereken temel fikirleri göreceğiz.

Keycloak hakkında daha fazla bilgi edinmek istiyorsanız yazının sonundaki bağlantılara bakın. Uygulamaya daha fazla dalmak için ders çalışabilirsiniz. depomuz Bu makalenin ana fikirlerini uygulayan bir modül ile (başlatma kılavuzu oradadır, bu makale cihaz ve ayarlara genel bir bakış sağlayacaktır, yakl. çevirmen).

Keycloak, Java ile yazılmış ve bir uygulama sunucusu üzerine kurulmuş kapsamlı bir sistemdir yaban sineği. Kısaca uygulama kullanıcılarına federasyon ve SSO (tek oturum açma) yetenekleri kazandıran bir yetkilendirme çerçevesidir.

Sizi resmi yazıyı okumaya davet ediyoruz web sitesi veya Vikipedi ayrıntılı anlayış için.

Keycloak'ı Başlatma

Keycloak'un çalışması için iki kalıcı veri kaynağı gerekir:

Kullanıcı bilgileri gibi yerleşik verileri depolamak için kullanılan bir veritabanı
Veritabanındaki verileri önbelleğe almak ve kullanıcı oturumları gibi bazı kısa ömürlü ve sıklıkla değişen meta verileri depolamak için kullanılan Datagrid önbelleği. Uygulandı sonsuzBu genellikle veritabanından önemli ölçüde daha hızlıdır. Ancak her durumda Infinispan'da kaydedilen veriler geçicidir ve küme yeniden başlatıldığında herhangi bir yere kaydedilmesine gerek yoktur.

Keycloak dört farklı modda çalışır:

sıradan - bir dosya aracılığıyla yapılandırılmış tek ve tek bir işlem bağımsız.xml
Düzenli küme (yüksek kullanılabilirlik seçeneği) - tüm işlemler, manuel olarak senkronize edilmesi gereken aynı yapılandırmayı kullanmalıdır. Ayarlar bir dosyada saklanır bağımsız-ha.xmlAyrıca veritabanına ve yük dengeleyiciye paylaşımlı erişim sağlamanız gerekir.
Etki alanı kümesi — bir kümeyi normal modda başlatmak, küme büyüdükçe hızla rutin ve sıkıcı bir görev haline gelir, çünkü konfigürasyon her değiştiğinde, tüm değişikliklerin her küme düğümünde yapılması gerekir. Etki alanı çalışma modu, bazı paylaşılan depolama konumları ayarlayarak ve yapılandırmayı yayınlayarak bu sorunu çözer. Bu ayarlar dosyada saklanır etki alanı.xml
Veri merkezleri arasında çoğaltma — Keycloak'ı çoğunlukla farklı coğrafi konumlarda bulunan birkaç veri merkezinden oluşan bir kümede çalıştırmak istiyorsanız. Bu seçenekte her veri merkezinin kendine ait Keycloak sunucuları kümesi olacaktır.

Bu yazıda ikinci seçeneği ayrıntılı olarak ele alacağız, yani düzenli kümeAyrıca veri merkezleri arasındaki replikasyon konusuna da biraz değineceğiz çünkü bu iki seçeneği Kubernetes'te çalıştırmak mantıklı olacaktır. Neyse ki Kubernetes'te birkaç bölmenin (Keycloak düğümleri) ayarlarının senkronize edilmesinde herhangi bir sorun yoktur, bu nedenle etki alanı kümesi Bunu yapmak çok zor olmayacak.

Ayrıca lütfen kelimenin küme makalenin geri kalanı yalnızca birlikte çalışan bir grup Keycloak düğümü için geçerli olacağından Kubernetes kümesine başvurmaya gerek yoktur.

Normal Keycloak kümesi

Keycloak'ı bu modda çalıştırmak için ihtiyacınız olan:

harici paylaşılan veritabanını yapılandırma
yük dengeleyiciyi yükle
IP çoklu yayın desteğine sahip dahili bir ağa sahip olun

Bu makalenin amacı bu olmadığından harici bir veritabanı kurmayı tartışmayacağız. Bir yerlerde çalışan bir veritabanı olduğunu ve ona bir bağlantı noktamız olduğunu varsayalım. Bu verileri basitçe ortam değişkenlerine ekleyeceğiz.

Keycloak'ın yük devretme (HA) kümesinde nasıl çalıştığını daha iyi anlamak için bunun Wildfly'ın kümeleme yeteneklerine ne kadar bağlı olduğunu bilmek önemlidir.

Wildfly birkaç alt sistem kullanır; bunlardan bazıları yük dengeleyici olarak kullanılır, bazıları ise hata toleransı için kullanılır. Yük dengeleyici, bir küme düğümü aşırı yüklendiğinde uygulamanın kullanılabilirliğini sağlar ve hata toleransı, bazı küme düğümleri arızalansa bile uygulamanın kullanılabilirliğini sağlar. Bu alt sistemlerden bazıları:

mod_cluster: HTTP yük dengeleyici olarak Apache ile birlikte çalışır, varsayılan olarak ana bilgisayarları bulmak için TCP çok noktaya yayına bağlıdır. Harici bir dengeleyici ile değiştirilebilir.
infinispan: Taşıma katmanı olarak JGroups kanallarını kullanan dağıtılmış bir önbellek. Ek olarak, önbellek içeriğini senkronize etmek amacıyla harici bir Infinispan kümesiyle iletişim kurmak için HotRod protokolünü kullanabilir.
jgroups: JGroups kanallarına dayalı olarak yüksek düzeyde kullanılabilir hizmetler için grup iletişim desteği sağlar. Adlandırılmış kanallar, iletişimin güvenilirlik, düzenlilik ve hatalara karşı duyarlılık gibi özelliklere sahip olması için bir kümedeki uygulama örneklerinin gruplara bağlanmasına olanak tanır.

Yük dengeleyici

Bir Kubernetes kümesine giriş denetleyicisi olarak bir dengeleyici kurarken aşağıdaki hususların akılda tutulması önemlidir:

Keycloak, HTTP aracılığıyla kimlik doğrulama sunucusuna bağlanan istemcinin uzak adresinin, istemci bilgisayarın gerçek IP adresi olduğunu varsayar. Dengeleyici ve giriş ayarları, HTTP başlıklarını doğru şekilde ayarlamalıdır X-Forwarded-For и X-Forwarded-Protove ayrıca orijinal başlığı kaydedin HOST. En son sürüm ingress-nginx (>0.22.0) bunu varsayılan olarak devre dışı bırakır

Bayrağın etkinleştirilmesi proxy-address-forwarding bir ortam değişkeni ayarlayarak PROXY_ADDRESS_FORWARDING в true Keycloak'a bir proxy arkasında çalıştığının anlaşılmasını sağlar.

Ayrıca etkinleştirmeniz gerekir yapışkan oturumlar girişte. Keycloak, geçerli kimlik doğrulama oturumu ve kullanıcı oturumuyla ilişkili verileri depolamak için dağıtılmış bir Infinispan önbelleği kullanır. Önbellekler varsayılan olarak tek bir sahiple çalışır; başka bir deyişle, söz konusu oturum kümedeki bazı düğümlerde depolanır ve diğer düğümler, o oturuma erişime ihtiyaç duyduklarında bunu uzaktan sorgulamak zorundadır.

Özellikle, belgelerin aksine, çerez adıyla bir oturum eklemek bizim için işe yaramadı AUTH_SESSION_ID. Keycloak'ın bir yönlendirme döngüsü vardır, dolayısıyla yapışkan oturum için farklı bir çerez adı seçmenizi öneririz.

Keycloak ayrıca ilk yanıt veren düğümün adını da ekler. AUTH_SESSION_IDve yüksek düzeyde kullanılabilir sürümdeki her düğüm aynı veritabanını kullandığından, her biri olmalı işlemleri yönetmek için ayrı ve benzersiz bir düğüm tanımlayıcısı. koymanız tavsiye edilir JAVA_OPTS Seçenekleri jboss.node.name и jboss.tx.node.id her düğüm için benzersizdir - örneğin bölmenin adını girebilirsiniz. Bir pod adı koyarsanız, jboss değişkenleri için 23 karakter sınırını unutmayın; bu nedenle Deployment yerine StatefulSet kullanmak daha iyidir.

Başka bir komisyon - bölme silinirse veya yeniden başlatılırsa önbelleği kaybolur. Bunu dikkate alarak, önbelleğin bir kopyasının kalması için tüm önbellekler için önbellek sahiplerinin sayısını en az ikiye ayarlamak faydalı olacaktır. Çözüm çalıştırmaktır Wildfly'ın senaryosu bölmeyi başlatırken dizine yerleştirme /opt/jboss/startup-scripts konteynerde:

Komut Dosyası İçeriği

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

daha sonra ortam değişkeninin değerini ayarlayın CACHE_OWNERS gerekenlere.

IP çoklu yayın desteğine sahip özel ağ

Weavenet'i bir CNI olarak kullanırsanız, çok noktaya yayın hemen çalışacaktır ve Keycloak düğümleriniz başlatılır başlatılmaz birbirlerini görecektir.

Kubernetes kümenizde ip çoklu yayın desteğiniz yoksa, JGroup'ları düğümleri bulmak için diğer protokollerle çalışacak şekilde yapılandırabilirsiniz.

İlk seçenek kullanmaktır KUBE_DNShangi kullanır headless service Keycloak düğümlerini bulmak için JGroups'a düğümleri bulmak için kullanılacak hizmetin adını iletmeniz yeterlidir.

Başka bir seçenek de yöntemi kullanmaktır. KUBE_PINGDüğümleri aramak için API ile çalışan (yapılandırmanız gerekir) serviceAccount hakları olan list и getve ardından bölmeleri bununla çalışacak şekilde yapılandırın serviceAccount).

JGroup'ların düğüm bulma yöntemi, ortam değişkenlerinin ayarlanmasıyla yapılandırılır JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Karşı KUBE_PING sorarak bölmeleri seçmeniz gerekir namespace и labels.

️ Çok noktaya yayın kullanıyorsanız ve bir Kubernetes kümesinde (örneğin ad alanında bir tane diyelim) iki veya daha fazla Keycloak kümesi çalıştırıyorsanız production, ikinci - staging) - bir Keycloak kümesinin düğümleri başka bir kümeye katılabilir. Değişkenleri ayarlayarak her küme için benzersiz bir çok noktaya yayın adresi kullandığınızdan emin olun.jboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Veri merkezleri arasında çoğaltma

Bağlantı

Keycloak, Keycloak düğümlerinden oluşan Keycloack kümelerinin bulunduğu her veri merkezi için birden fazla ayrı Infinispan önbellek kümesi kullanır. Ancak farklı veri merkezlerindeki Keycloak düğümleri arasında hiçbir fark yoktur.

Keycloak düğümleri, veri merkezleri arasındaki iletişim için harici bir Java Data Grid (Infinispan sunucuları) kullanır. İletişim protokole göre çalışır Infinispan HotRod.

Infinispan önbellekleri bu öznitelikle yapılandırılmalıdır remoteStoreBöylece veriler uzaktan (başka bir veri merkezinde, yakl. çevirmen) önbellekler. JDG sunucuları arasında ayrı infinispan kümeleri bulunur, böylece JDG1'de depolanan veriler sahada site1 yerinde JDG2'ye kopyalanacak site2.

Ve son olarak, alıcı JDG sunucusu, HotRod protokolünün bir özelliği olan istemci bağlantıları aracılığıyla kendi kümesinin Keycloak sunucularına bildirir. Keycloak düğümleri açık site2 Infinispan önbelleklerini güncellediğinizde belirli kullanıcı oturumu Keycloak düğümlerinde de kullanılabilir hale gelir. site2.

Bazı önbellekler için yedekleme yapmamak ve Infinispan sunucusu üzerinden veri yazmaktan tamamen kaçınmak da mümkündür. Bunu yapmak için ayarı kaldırmanız gerekir remote-store belirli Infinispan önbelleği (dosyada bağımsız-ha.xml), ardından bazı spesifik replicated-cache Infinispan sunucu tarafında da artık gerekli olmayacak.

Önbellekleri ayarlama

Keycloak'ta iki tür önbellek vardır:

Yerel. Veritabanının yanında bulunur ve veritabanı üzerindeki yükün azaltılmasının yanı sıra yanıt gecikmesinin azaltılmasına da hizmet eder. Bu önbellek türü alanı, istemcileri, rolleri ve kullanıcı meta verilerini depolar. Bu önbellek türü, önbellek bir Keycloak kümesinin parçası olsa bile çoğaltılmaz. Önbellekteki bir giriş değişirse, kümedeki geri kalan sunuculara değişiklikle ilgili bir mesaj gönderilir ve ardından giriş önbelleğin dışında bırakılır. Açıklamayı gör work Prosedürün daha ayrıntılı bir açıklaması için aşağıya bakın.
Çoğaltıldı. Kullanıcı oturumlarını, çevrimdışı belirteçleri işler ve ayrıca parola kimlik avı girişimlerini ve diğer saldırıları tespit etmek için oturum açma hatalarını izler. Bu önbelleklerde depolanan veriler geçicidir, yalnızca RAM'de depolanır ancak küme genelinde çoğaltılabilir.

Infinispan önbellekleri

oturum - Keycloak'ta ayrı önbellekler adı verilen bir kavram authenticationSessions, belirli kullanıcıların verilerini depolamak için kullanılır. Bu önbelleklerden gelen isteklere genellikle uygulamalar değil, tarayıcı ve Keycloak sunucuları ihtiyaç duyar. Yapışkan oturumlara bağımlılığın devreye girdiği yer burasıdır ve bu tür önbelleklerin Aktif-Aktif modunda bile kopyalanmasına gerek yoktur.

Eylem Jetonları. Genellikle çeşitli senaryolar için kullanılan başka bir kavram, örneğin kullanıcının posta yoluyla eşzamansız olarak bir şey yapması gerektiği durumlarda. Örneğin işlem sırasında forget password önbellek actionTokens ilişkili belirteçlerin meta verilerini izlemek için kullanılır; örneğin, bir belirteç zaten kullanılmış ve yeniden etkinleştirilemez. Bu tür önbelleğin genellikle veri merkezleri arasında kopyalanması gerekir.

Saklanan verilerin önbelleğe alınması ve eskitilmesi veritabanı üzerindeki yükü hafifletmek için çalışır. Bu tür bir önbelleğe alma performansı artırır, ancak bariz bir soruna da yol açar. Bir Keycloak sunucusu verileri güncellerse, diğer sunucuların önbelleklerindeki verileri güncelleyebilmeleri için bilgilendirilmeleri gerekir. Keycloak yerel önbellekleri kullanır realms, users и authorization veritabanındaki verileri önbelleğe almak için.

Ayrı bir önbellek de var work, tüm veri merkezlerinde çoğaltılır. Kendisi veritabanındaki herhangi bir veriyi saklamaz, ancak veri merkezleri arasındaki küme düğümlerine veri eskimesi hakkında mesajlar göndermeye yarar. Yani veriler güncellendiği anda Keycloak düğümü kendi veri merkezindeki diğer düğümlerin yanı sıra diğer veri merkezlerindeki düğümlere de mesaj gönderir. Böyle bir mesajı aldıktan sonra her düğüm, yerel önbelleklerindeki ilgili verileri temizler.

Kullanıcı oturumları. Adları içeren önbellekler sessions, clientSessions, offlineSessions и offlineClientSessions, genellikle veri merkezleri arasında çoğaltılır ve kullanıcı tarayıcıda etkinken etkin olan kullanıcı oturumları hakkındaki verileri depolamaya yarar. Bu önbellekler, son kullanıcılardan gelen HTTP isteklerini işleyen uygulamayla çalışır, bu nedenle kalıcı oturumlarla ilişkilendirilirler ve veri merkezleri arasında kopyalanmaları gerekir.

Kaba kuvvet koruması. Önbellek loginFailures Bir kullanıcının kaç kez yanlış şifre girdiği gibi oturum açma hatası verilerini izlemek için kullanılır. Bu önbelleğin çoğaltılması yöneticinin sorumluluğundadır. Ancak doğru bir hesaplama için veri merkezleri arasında çoğaltmayı etkinleştirmeye değer. Ancak diğer taraftan bu verileri kopyalamazsanız performansı artırmış olursunuz ve bu sorun ortaya çıkarsa replikasyon etkinleştirilemeyebilir.

Bir Infinispan kümesinin kullanıma sunulması sırasında ayarlar dosyasına önbellek tanımları eklemeniz gerekir:

<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 kümesini başlatmadan önce Infinispan kümesini yapılandırmalı ve başlatmalısınız

Daha sonra yapılandırmanız gerekir remoteStore Keycloak önbellekleri için. Bunu yapmak için, değişkeni ayarlamak için kullanılan öncekine benzer şekilde yapılan bir komut dosyası yeterlidir. CACHE_OWNERS, onu bir dosyaya kaydetmeniz ve bir dizine koymanız gerekir /opt/jboss/startup-scripts:

Komut Dosyası İçeriği

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

Kurulumu unutmayın JAVA_OPTS Keycloak düğümlerinin HotRod'u çalıştırması için: remote.cache.host, remote.cache.port ve hizmet adı jboss.site.name.

Bağlantılar ve ek belgeler

Makale çalışanlar tarafından çevrildi ve Habr için hazırlandı Slurm eğitim merkezi — uygulama uzmanlarından (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE) yoğun kurslar, video kursları ve kurumsal eğitimler

Kaynak: habr.com

Keycloak'ı Kubernetes'te HA modunda çalıştırma