KeyCloak HA на AWS EC2 с док-кластером, но сбой входа в систему

Question

Мы пытаемся установить KeyCloak 1.9.3 с HA на AWS EC2 с докере, кластер работает без ошибок, однако сбой входа с ошибкой ниже:

WARN [org.keycloak.events] (по умолчанию задача-10) типа = LOGIN_ERROR, realmId = мастер, ClientID = NULL, NULL = идентификатор пользователя, IPaddress = 172.30.200.171, ошибка = invalid_code

мы вслед за этим (http://lists.jboss.org/pipermail/keycloak-user/2016-February/004940.html), но используется S3_PING вместо JDBC_PING.

Кажется, что узлы обнаруживают друг друг:

INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Входящий-2, й, 6dbce1e2a05a) ISPN000094: Получены новый вид кластера для канала keycloak: [6dbce1e2a05a | 1] (2) [6dbce1e2a05a, 75f2b2e98cfd]

мы подозреваем, что узлы не общаются друг с другом, когда мы запросили в JBoss MBean «jboss.as.expr: подсистема = JGroups, канал = й «результатом для первого узла был:

jgroups,channel=ee = [6dbce1e2a05a|1] (2) [6dbce1e2a05a, 75f2b2e98cfd] 
jgroups,channel=ee receivedMessages = 0 
jgroups,channel=ee sentMessages = 0 

И для второго узла:

jgroups,channel=ee = [6dbce1e2a05a|1] (2) [6dbce1e2a05a, 75f2b2e98cfd] 
jgroups,channel=ee receivedMessages = 0 
jgroups,channel=ee sentMessages = 5 

Мы также проверили, что порты TCP 57600 и 7600 открыты.

Любая идея, что может вызвать это?

Вот соответствующая конфигурация автономного-ha.xml и ниже, что команда запуска:

<subsystem xmlns="urn:jboss:domain:jgroups:4.0"> 
<channels default="ee"> 
<channel name="ee" stack="tcp"/> 
</channels> 
<stacks> 
<stack name="udp"> 
<transport type="UDP" socket-binding="jgroups-udp"/> 
<protocol type="PING"/> 
<protocol type="MERGE3"/> 
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/> 
<protocol type="FD_ALL"/> 
<protocol type="VERIFY_SUSPECT"/> 
<protocol type="pbcast.NAKACK2"/> 
<protocol type="UNICAST3"/> 
<protocol type="pbcast.STABLE"/> 
<protocol type="pbcast.GMS"/> 
<protocol type="UFC"/> 
<protocol type="MFC"/> 
<protocol type="FRAG2"/> 
</stack> 
<stack name="tcp"> 
<transport type="TCP" socket-binding="jgroups-tcp"> 
<property name="external_addr">200.129.4.189</property> 
</transport> 
<protocol type="S3_PING"> 
<property name="access_key">AAAAAAAAAAAAAA</property> 
<property name="secret_access_key">BBBBBBBBBBBBBB</property> 
<property name="location">CCCCCCCCCCCCCCCCCCCC</property> 
</protocol> 
<protocol type="MERGE3"/> 
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"> 
<property name="external_addr">200.129.4.189</property> 
</protocol> 
<protocol type="FD"/> 
<protocol type="VERIFY_SUSPECT"/> 
<protocol type="pbcast.NAKACK2"/> 
<protocol type="UNICAST3"/> 
<protocol type="pbcast.STABLE"/> 
<protocol type="pbcast.GMS"/> 
<protocol type="MFC"/> 
<protocol type="FRAG2"/> 
</stack> 
</stacks> 
</subsystem> 

<socket-binding name="jgroups-tcp" interface="public" port="7600"/> 
<socket-binding name="jgroups-tcp-fd" interface="public" port="57600"/> 

И мы начинаем сервер, используя ниже (INTERNAL_HOST_IP является контейнером внутренний IP-адрес):

standalone.sh -c=standalone-ha.xml -b=$INTERNAL_HOST_IP -bmanagement=$INTERNAL_HOST_IP -bprivate=$INTERNAL_HOST_IP 

Любая помощь будет оценена по достоинству.

Answer 1

Очевидно, что никаких проблем с установкой не возникало, проблема заключалась в том, что мы случайно сконфигурировали DB в БД памяти для каждого экземпляра вместо нашей общей БД.

Answer 2

Вы должны включить липкость балансировочного устройства AWS, чтобы получить успешный вход в систему.