У нас есть 2 машины, работающие Keycloak 4.8.3.Final (WildFly Core 6.0.2.Final) в доменном режиме.Первый из них host1 собирается запустить контроллер домена и будет нашим хозяином.Host2 является нашим рабом и регистрирует себя на хозяина.Насколько мы понимаем, режим «Домен» решает эту проблему, предоставляя центральное место для хранения и публикации конфигурации.
Первый запускается при выполнении команды:
/ opt / keycloak /bin / domain.sh --host-config host-master.xml -Djboss.bind.address = 0.0.0.0 -Djboss.bind.address.management = 0.0.0.0 -Djava.security.egd = файл: / dev / urandom-Dkeycloak.profile.feature.token_exchange = enabled -Djboss.node.name = host1
Второй, выполнив команду:
/ opt / keycloak / bin/domain.sh --host-config host-slave.xml -Djboss.bind.address = 0.0.0.0 -Djboss.bind.address.management = 0.0.0.0 -Djboss.domain.master.username = slave -Djboss.domain.master.address = {host1_ip} -Dkeycloak.profile.feature.token_exchange = enabled -Djava.security.egd = файл: / dev / urandom -Djboss.node.name = host2
Оба изони запускаются успешно, и ведомому удается подключиться к главному.Мы используем машину MySQL, на которую оба сервера указывают для сохранения данных.
Во-первых, мы использовали домен domain.xml по умолчанию, поставляемый с дистрибутивом keycloak, и наши первоначальные ожидания заключались в том, что, создавая что-то на host1, изменениябудет распространен на хост2.К сожалению, этого не произошло.Когда мы создавали пользователя, он появлялся через некоторое время на host2.Когда мы создали область или клиента в области с host1, изменения не могли быть видны с host2, пока мы не перезапустили оба сервера и синхронизация информации не была принудительной.
Следующим шагом было изменение конфигурации domain.xml в директиве infinispan и репликация кэша на всех машинах.
<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
<cache-container name="keycloak">
<transport lock-timeout="60000" />
<replicated-cache name="authenticationSessions" />
<replicated-cache name="clientSessions" />
<replicated-cache name="offlineClientSessions" />
<replicated-cache name="authorization" />
<replicated-cache name="work" />
<replicated-cache name="keys" />
<replicated-cache name="actionTokens"></replicated-cache>
<replicated-cache name="realms" />
<replicated-cache name="users" />
<replicated-cache name="sessions" />
<replicated-cache name="offlineSessions" />
<replicated-cache name="loginFailures" />
<replicated-cache name="work" />
<replicated-cache name="realmVersions" />
</cache-container>
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000" />
<replicated-cache name="default">
<transaction mode="BATCH" />
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000" />
<distributed-cache name="dist">
<locking isolation="REPEATABLE_READ" />
<transaction mode="BATCH" />
<file-store />
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000" />
<distributed-cache name="dist">
<locking isolation="REPEATABLE_READ" />
<transaction mode="BATCH" />
<file-store />
</distributed-cache>
</cache-container>
<cache-container name="hibernate" module="org.infinispan.hibernate-cache">
<transport lock-timeout="60000" />
<local-cache name="local-query">
<object-memory size="10000" />
<expiration max-idle="100000" />
</local-cache>
<invalidation-cache name="entity">
<transaction mode="NON_XA" />
<object-memory size="10000" />
<expiration max-idle="100000" />
</invalidation-cache>
<replicated-cache name="timestamps" />
</cache-container>
</subsystem>
Однако у нас есть те же проблемы, особенно в том, что если вы восстанавливаете секрет для клиента, секрет не распространяется на подчиненный хост или наоборот.
Кто-нибудь еще сталкивался с этой проблемой и что вы делали для ее решения?Любая помощь будет высоко ценится!