Repository navigation
|
https://www.keycloak.org/server/containers this page only shows how to run existing dockerfile with kc.sh and ubi-null.sh, why isn't there an easier way with graalvm or mandrel builder images like this? it seem very complicated for me to understand how kc.sh is created or how tar.gz is created and hotlinked in a fedora container? why doesn't keycloak use quarkus capabilities outlined here https://quarkus.io/guides/building-native-image#multistage-docker? |
Replies: 1 comment 8 replies
|
@mrwormhole Could you please elaborate a bit more what difficulties are you experiencing with our ubi based Dockerfile? In the mentioned container guide we instruct the users to use the Keycloak image as a base for their custom image, no need to build Keycloak from sources. If you are interested in building the dist from sources instead, you can follow: https://github.com/keycloak/keycloak/blob/main/quarkus/README.md |
|
hello, I have built it from the source but it compiles it only down to .jar , I can not turn .jar into a native executable file. I don't like ubi based dockerfile because essentially it is downloading the artifacts from GH and running kc.sh(which is somehow generated JVM options) with javac, this causes 2-3 seconds startup delay as docker image consists of fedora-like ubi running with openjdk then running javac during container startups. In ideal world, I would like to use a self-sufficient(containing maven and compiler toolchain like mandrel) multi-stage dockerfile where I build with quarkus native to static app then I would run that in alpine or scratch without the need of ubi containing openjdk, dockerfile would also build itself without relying on tar.gz artifacts Even if I relied on tar.gz artifacts of GH, I would love a smaller image that only derives from openjdk or xyzjdk, not sure why there is fedora image then some shell script to remove things manually from OS inside docker also everytime I build with I feel like it would be simplified but i am not sure why keycloak uses ubi images and i respect that however it would be very nice if something similar to this quarkus multistage dockerfile has been used I have also searched every issue so I don't know why quarkus native images in dockerfile has never been used since WildFly, there is definitely something I am missing since I am not keycloak contributor or java professional. If you can point it out, I would be very glad. Thanks for your help and patience |
|
We do not support building a native binary, Keycloak needs JVM. |
Is it because of keycloak dependencies? Or quarkus is not ready at the moment? thanks |
|
Quarkus is ready, Keycloak is not. :) AFAIK, dependencies are one problem but some changes would be needed also in Keycloak code base. Another thing is that Keycloak would not support extensions in native. That said, we do still plan to explore this in more detail in the future. |
I'm also very interested in this, as of today both Keycloak and Operator images are the bottlenecks on wire-size and readiness-time of the Java workloads I'm building natively. I have custom extensions but I wouldn't mind compiling the image natively to include the extensions as part of the native executable. |
|
Status of GraalVM? |
We do not support building a native binary, Keycloak needs JVM.
kc.shis just a wrapper that eventually calls java.