This is worst docker image ever.

It's starting multiple minutes.

You're supposed to "compile" it, creating your own image, hosting it somewhere (and it's huge). And then this "compiled" image will be fast. Well, fast in Java terms.

Agree

I was shocked when I read the instructions and realized I had to build a secondary container.

On top of this, there are some keycloak options (parameters and env vars) which are valid only at the time of compiling a new container, where others are valid only at runtime

You absolutely don't have to build a container. You can, and it makes startup a few seconds faster so they recommend it, since it's hardly a pain anyway if you already have CI in place.

Anyway, they changed the default behavior a few releases ago. In the past you had to pass --auto-build to avoid having to build, but now the default behavior is to auto build. If you instead want to optimize you have to do extra steps: https://www.keycloak.org/server/configuration

That's great to hear -- thank you for the update!

If you `docker pull` an image, you already "host" it. It's a bunch of local files right on your machine.

Starting a few minutes? It looks like there must be some DNS problem somewhere. Or maybe it's the download build time? In any case, I'd measure the second startup time.

Java can be blazingly fast if done right. (And C++ can be stupidly slow if done wrong.)

I'm aware Java can be fast, but thats never what I work with. The products I've supported include vmware vcenter, confluence and epo. In all cases, just restarting a service is a "go have a coffee" affair. It really says a lot that something can take longer than a Microsoft exchange server to start but when I see it, I know someone badly wrote a Java app. To be clear I'll happily buy that this is a case of it not done right, but that seems pervasive.

It says more about the era than Java.

Those services were all built to not be restarted so they've never optimized for it. More recent Java frameworks and projects do try to optimize restarts due to kubernetes adoption etc.

Every newer Java application I've seen is just as dog slow as those older ones. Keycloak itself being a prime example — it was rewritten on top of Quarkus recently, and it didn't help much. You're still expected to build a second image (and maintain it — it wouldn't be a problem if you only had to it once), and it still takes 2-3 minutes to become responsive.

You may have have seen those magical Java applications that both implement a decent amount of functionality (so not just a toy), and start in a couple of seconds, but the rest of us will believe it when we see it.

I wonder how they're developed, it feels like a throwback to the punch-card era.

While I don't have much love for Microsoft, you should take a look at dotnet. Applications written on top of dotnet (even using massive frameworks like ASP.NET + EF) actually do start in a few seconds, which is at least an order of magnitude faster than anything similar in Java.

I've only used docker for local dev environments, so I'm curious what happens if the process crashes? Does the docker daemon perform health checks to restart it, or is that the domain of k8s? It's pretty simple to do with systemd.

Plain systemd can run docker containers, and keep them up if they crash. (Yes, systemd can be a useful thing sometimes!)

Also, Docker and Podman know how to restart containers if needed, depending on a policy you set.

If you want something even smaller, take https://github.com/containers/bubblewrap or https://github.com/arachsys/containers and run them under the process monitor of your choice, like runit or s6.

Simplest form is `docker run --restart=unless-stopped` and `systemctl enable docker`

They will restart when crash, and after reboot.

Docker and kubernetes are different things.

But both systems can restart crashed containers. That's not an issue at all. Kubernetes does it automatically. Docker does not do it automatically but you just need to supply proper option for `run` (or just in docker-compose.yaml).