Oh! I see now. So I think you want to use Jgroups JDBC_PING way of creating the cluster. I do not have now a code sample but I had the same problem and I can highlight what you can do, I hope you will find the answer. Hint: is in this forum, in some older question.
So first: what is the problem? The modern, Qaurkus based Keycloak does not support out of the box the JDBC_PING mechanism that was so easy to use in the older, Wildly versions. You will see in the Keycloak documentation in this page All configuration - Keycloak the config called cache-stack. And the only accepted values are: tcp, udp, kubernetes, ec2, azure, google.
So not jdbc_ping. However, there is a way to do it without too much hastle. You will notice in your Keycloak docker container in the path /opt/keycloak/conf/cache-ispn.xml (or something like that, as I said I do not have the container in front of me but should be very easy to find). And you can very easily copy that default file in the place where you build your keycloak container, and in the Dockerfile where you customize your Keycloak you just need to override that file. And in the cache-ispn.xml you can add a jgroups config before the cache-container block, something like this:
<jgroups>
<stack name="jdbc-ping-tcp" extends="tcp">
// ...
</stack>
</jgroups>
<cache-container name="keycloak">
And with this extension everything should work. You can inspire from this thread (found it meanwhile: Use of JDBC_PING with Keycloak 17 (Quarkus distro) - #38 by keepthemomentum)
However, there is a small caveat. In our case we used a custom port, not the default one (those were the rules set in the cloud provider, does not matter). So we had to look exactly what is the default configuration, and what is the java property from which the port is read and pass that to the Docker container when starts. But if you go with the default port you will have no problem with the approach described in the original thread I’ve shared, I made this setup work following the steps