Faster container startup: default to start mode, publish multi-arch image#8
Merged
Merged
Conversation
Drop the exec-maven-plugin that drove a single-arch `docker build`/`docker push` and switch the release workflow to `docker/build-push-action@v6` with QEMU + buildx, producing a manifest that covers both linux/amd64 and linux/arm64. Arm64 consumers (Apple Silicon in particular) get a native image instead of running under Rosetta, which speeds up JVM startup. The workflow builds amd64 first with `load: true` so the entrypoint integration test runs against a local image, then does the multi-arch push. Buildx cache reuses the amd64 layers across the two builds. Refs #7.
`kc.sh build` already runs at image build time, so `start` can launch without the per-boot augmentation that `start-dev` performs. In local testing on Apple Silicon this cut cold-start time from ~70s to ~17s. Set `KC_HTTP_ENABLED=true` and `KC_HOSTNAME_STRICT=false` as runtime defaults in the Dockerfile so `start` launches cleanly behind a TLS- terminating reverse proxy without any extra configuration. Both can be overridden at `docker run` time. `start-dev` remains available as an explicit command override for contributors iterating on theme or realm config. Refs #7.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses #7 — the two contributors to the ~70s cold start.
startinstead ofstart-dev.kc.sh buildalready runs at image build time, so production mode launches without the per-boot augmentation that dev mode performs. Local cold-start timing on Apple Silicon dropped from ~70s to ~17s (Quarkus startup ~5.4s).KC_HTTP_ENABLED=trueandKC_HOSTNAME_STRICT=falseare baked in as runtime defaults sostartworks out of the box behind a TLS-terminating reverse proxy.start-devis still available as an explicit override.docker/setup-qemu-action+docker/setup-buildx-action+docker/build-push-action@v6to publish a manifest covering bothlinux/amd64andlinux/arm64. Arm64 consumers stop running under Rosetta. The old single-archexec-maven-plugindocker build/push block inpom.xmlhas been removed.load: truesotest-entrypoint.shstill runs against a locally-loaded image; the multi-archpush: truebuild follows (buildx reuses the amd64 layers).Test plan
docker build -t protegeproject/webprotege-keycloak:test .succeeds against the updated Dockerfile./test-entrypoint.sh— all 15 assertions pass (first-boot realm import, protocol mapper fix, URI patching, restart idempotency) against thestart-mode imagedocker runto "Realm configuration complete" on arm64 (previously ~70s)docker manifest inspect protegeproject/webprotege-keycloak:<version>shows bothlinux/amd64andlinux/arm64after the next release🤖 Generated with Claude Code