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

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

WARN [org.keycloak.events] (задача по умолчанию-10) type = LOGIN_ERROR, realmId = master, clientId = null, userId = null, ipAddress = 172.30.200.171, error = invalid_code

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

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

ИНФОРМАЦИЯ [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2, ee, 6dbce1e2a05a) ISPN000094: получено новое представление кластера для скрытой клавиатуры канала: [6dbce1e2a05a | 1] (2) [6dbce1e2a05a | 1] (2) [6dbce1e98fc02]

Мы подозреваем, что узлы не взаимодействуют друг с другом, когда мы запросили jboss mbean "jboss.as.expr: subsystem = jgroups, channel = ee", результат для первого узла был:

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 открыты.

Есть идеи, что может вызвать это?

Вот соответствующая конфигурация standalone-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

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


person Haim    schedule 17.08.2016    source источник


Ответы (2)


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

person Haim    schedule 11.09.2016

вам необходимо включить липкость балансировщика нагрузки AWS для успешного входа в систему.

person Aman Jaiswal    schedule 07.09.2016