Search code examples
dockerwildflykeycloak

Keycloak SPI Providers and layers not loading when using Docker


I'm trying to setup a docker image with some custom things, such as a logback extension, so I have some CLI scripts, like this one:

/subsystem=logging: remove()
/extension=org.jboss.as.logging: remove()

/extension=com.custom.logback: add()
/subsystem=com.custom.logback: add()

I also have CLI scripts to configure datasource pool, themes, add some SPI on keycloak-server subsystem, etc. I put these scripts in the /opt/jboss/startup-scripts directory. However, when I create the container things do not work well. The scripts are not loaded as expected and keycloak starts with an error, not loading providers such as password policies used by the realms.

When I'm using standalone Keycloak all SPI providers are loaded fine as the log below:

2019-07-25 18:27:07.906 WARN  [org.keycloak.services] (ServerService Thread Pool -- 65) KC-SERVICES0047: custom-password-policy (com.custom.login.password.PasswordSecurityPolicyFactory) is implementing the internal SPI password-policy. This SPI is internal and may change without notice
2019-07-25 18:27:07.909 WARN  [org.keycloak.services] (ServerService Thread Pool -- 65) KC-SERVICES0047: custom-event (com.custom.event.KeycloakServerEventListenerProviderFactory) is implementing the internal SPI eventsListener. This SPI is internal and may change without notice
2019-07-25 18:27:08.026 WARN  [org.keycloak.services] (ServerService Thread Pool -- 65) KC-SERVICES0047: custom-mailer (com.custom.mail.MessageSenderProviderFactory) is implementing the internal SPI emailSender. This SPI is internal and may change without notice
2019-07-25 18:27:08.123 WARN  [org.keycloak.services] (ServerService Thread Pool -- 65) KC-SERVICES0047: custom-user-domain-verification (com.custom.login.domain.UserDomainVerificationFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice
2019-07-25 18:27:08.123 WARN  [org.keycloak.services] (ServerService Thread Pool -- 65) KC-SERVICES0047: custom-recaptcha-username-password (com.custom.login.domain.RecaptchaAuthenticatorFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice

If I use the same package with Docker, using jboss/keycloak:6.0.1 as the image base, providers do not load. I'm using it as modules, adding them to the $JBOSS_HOME/modules folder and configuring like the script below:

/subsystem=keycloak-server/: write-attribute(name=providers,value=[classpath:${jboss.home.dir}/providers/*,module:com.custom.custom-keycloak-server])

/subsystem=keycloak-server/theme=defaults/: write-attribute(name=welcomeTheme,value=custom)
/subsystem=keycloak-server/theme=defaults/: write-attribute(name=modules,value=[com.custom.custom-keycloak-server])

/subsystem=keycloak-server/spi=emailSender/: add(default-provider=custom-mailer)

When I execute the script inside the container all works fine.

I tried both using volumes to map the jar with the providers and copying the jar when building the custom image but none of these ways is working.

I'm using jboss:keycloak:6.0.1 docker image and Keycloak 6.0.1 standalone, layers and modules put in the same directories.

What am I doing wrong? What is the trick to using SPI provider with Docker or the image was not intended for production or this type of need?


Solution

  • OK, I've found why this happen

    it comes from the opt/jboss/tools/docker-entrypoint.sh

    #################
    # Configuration #
    #################
    
    # If the server configuration parameter is not present, append the HA profile.
    if echo "$@" | egrep -v -- '-c |-c=|--server-config |--server-config='; then
        SYS_PROPS+=" -c=standalone-ha.xml"
    fi
    

    it will launch the keycloak as a clustered, as I think they considered the standalone as not safe for production

    Standalone operating mode is only useful when you want to run one, and only one Keycloak server instance. It is not usable for clustered deployments and all caches are non-distributed and local-only. It is not recommended that you use standalone mode in production as you will have a single point of failure. If your standalone mode server goes down, users will not be able to log in. This mode is really only useful to test drive and play with the features of Keycloak Blockquote

    To keep the 'standalone mode', override the image to add the property -c standalone.xml as parameters:

    CMD ["-b", "0.0.0.0", "-c", "standalone.xml"]