Can't reproduce example for JDBC_PING with docker containers

[makaxel]

Hello, can you share some info about environment and starting docker containers. I have some vagrant vms (virtualbox) - k1 k2 k3 for keycloak, pg1 for postgre Vagrantfile.txt Postgre is run by docker run -d -p 5432:5432 --name postgres -e POSTGRES_DB=keycloak -e POSTGRES_USER=keycloak -e POSTGRES_PASSWORD=password postgres I can telnet postgre and see it in pgAdmin. Then I try to run keycloak docker containers like this: vagrant@k1:~/test5$ docker image build -t local_repo/keycloak_k1:k1_test5_1 . Sending build context to Docker daemon 8.192kB Step 1/3 : FROM jboss/keycloak:latest ---> 2ce01d473520 Step 2/3 : ADD cli/TCPPING.cli /opt/jboss/tools/cli/jgroups/discovery/ ---> c6960b8007c3 Step 3/3 : ADD cli/JDBC_PING.cli /opt/jboss/tools/cli/jgroups/discovery/ ---> 15405fe36007 Successfully built 15405fe36007 Successfully tagged local_repo/keycloak_k1:k1_test5_1

vagrant@k1:~/test5$ docker run --name keycloak_k1 -p 2221:22 -p 7600:7600 -p 8443:8443 -p 45700:45700 -p 57600:57600 -p 9991:9990 -p 8180:8080 -e DB_VENDOR=postgres -e DB_ADDR=10.0.0.14 -e DB_PORT=5432 -e DB_DATABASE=keycloak -e DB_SCHEMA=public -e DB_USER=keycloak -e DB_PASSWORD=password -e JGROUPS_DISCOVERY_EXTERNAL_IP=10.0.0.10 -e JGROUPS_DISCOVERY_PROTOCOL=JDBC_PING local_repo/keycloak_k1:k1_test5_1

And on vm k2 all the same. I created table JGROUPSPING manually in postgres. And corrected JDBC_PING.cli
JDBC_PING.cli.txt

I see no errors in log output, but still there are no entries in table JGROUPSPING. And both containers became single. Logs from vms k1 and k2 are k1.log k2.log

Why on your picture port 7600, but in my log it is "Channel ejb local address is 7cc37d615f74, physical addresses are [172.17.0.2:55200]"? What I am missing in configurations? Thanks in advance.

[liqiang-fit2cloud]

Hi, I think you did very well but I didn't find out why your deploy doesn't work.... To help you I can describe how it works.

1. The JDBC_PING.cli is used to modify the file /opt/jboss/keycloak/standalone/configuration/standalone-ha.xml, here you can see the file modified by my JDBC_PING.cli which is deployed on Kubernetes. And the jgroups-tcp will use port 7600.
2. About how to trigger the execution of JDBC_PING.cli. The entrypoint of Keycloak docker image is /opt/jboss/tools/docker-entrypoint.sh, in this file you can see below line:

   /opt/jboss/tools/jgroups.sh $JGROUPS_DISCOVERY_PROTOCOL $JGROUPS_DISCOVERY_PROPERTIES

   And /opt/jboss/tools/jgroups.sh is very simple that it only triggers the $JGROUPS_DISCOVERY_PROTOCOL.cli if env JGROUPS_DISCOVERY_PROTOCOL is set, then standalone-ha.xml will be modified into above 1st part.

So back to your issue. I think first of all you need to confirm whether your cli is executed, maybe you could add some debug logging or something. Then confirm if it is executed as expected, you can do this by checking your standalone-ha.xml file, or you can manually execute the cli in container by below command to see any error occurred.

$JBOSS_HOME/bin/jboss-cli.sh --file="/opt/jboss/tools/cli/jgroups/discovery/$JGROUPS_DISCOVERY_PROTOCOL.cli"

Good luck and let me know any help you need...

[liqiang-fit2cloud]

@makaxel Hi, I tried your JDBC_PING.cli on my server, there are some syntax errors and it throws exception while executing.

I modified your JDBC_PING.cli which has been tested successfully on my server. JDBC_PING.cli.txt

I believe it will work on your server.

[makaxel]

@liqiang-fit2cloud Thank you a lot for very quick help! I also dig into container as you wrote, and found that mistake was in cli file "20:46:05,944 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 6.0.1 (WildFly Core 8.0.0.Final) starte d in 5065ms - Started 64 of 83 services (30 services are lazy, passive or on-demand) Can't proceed with node type 'initialize_sql' until the node name for the previous node type has been specified." Your corrected JDBC_PING.cli works like a charm.

on k1

Received new cluster view for channel ejb: [ff715dc19a17|0] (1) [ff715dc19a17]
Channel ejb local address is ff715dc19a17, physical addresses are [10.0.0.10:7600]
....
Received new cluster view for channel ejb: [ff715dc19a17|1] (2) [ff715dc19a17, 831fa9afddfc]
Node 831fa9afddfc joined the cluster
Starting rebalance....

on k2

Received new cluster view for channel ejb: [ff715dc19a17|1] (2) [ff715dc19a17, 831fa9afddfc]
Channel ejb local address is 831fa9afddfc, physical addresses are [10.0.0.11:7600]

in postgre

One more question. Can you suggest the best way how to use federation of Active Directory? I can federate users, groups and make some mappings to roles in Keycloak. But how can I tier access to URI for user directly in AD? Do I need to write custom SPI? Can I extend existing AD implementation?

Thanks one more time.

[liqiang-fit2cloud]

Hmmm, what I have done for AD is just user federations of LDAP. For now I don't know how to login directly to AD at client-side instead of sending credentials to LDAP through Keycloak either... But AFAIK one of our developers did some workaround in our application (springboot and keycloak-springboot-adapter), the application validates httprequest to check if the client has login AD, if yes then call the impersonation API of Keycloak to get Keycloak's token, so that if the client has already login AD it can access the application directly. It works well although I don't think it's a good solution... I am not sure whether a custom SPI is useful, maybe something like "keycloak-springboot-active-directory-adapter" works for this...

[dzerhusen]

Had the same problem here with postgresql. Using this SQL Statement to instantiate Postgres worked for me: CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data bytea DEFAULT NULL, PRIMARY KEY(own_addr, cluster_name) ) ; and giving the right ownership: ALTER TABLE jgroupsping OWNER TO youruser

[DanPM]

Sorry for spam, but I just want to say thank you. Hats off to you for providing a solution and making our lives easier. This behavior should be already in official images. There are people building clusters between docker hosts (even cross dc) without using fancy docker swarms or kubernetes.