fix(docker): base runtime images on ubuntu:26.04 - #2380
Merged
avantgardnerio merged 1 commit intoAug 26, 2026
Conversation
These Dockerfiles are not hermetic: the binary is compiled on the host and
each image does `COPY target/${RELEASE_FLAG}/<bin> /root/<bin>`, so the
host's glibc must be no newer than the base image's. Building on Ubuntu
26.04 (glibc 2.43) against `ubuntu:24.04` (2.39) produces images that fail
at the loader before `main` runs:
/root/ballista-executor: /lib/x86_64-linux-gnu/libm.so.6:
version `GLIBC_2.43' not found (required by /root/ballista-executor)
This raises the floor rather than making the build hermetic — a host newer
than the base will break again the same way. Building inside a container
matching the base would fix it properly, at the cost of a separate target
dir per image.
`chaos.Dockerfile` is untouched: it builds inside `rust:1-bookworm` and runs
on `debian:bookworm-slim`, so it carries its own toolchain and does not
depend on the host at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
@phillipleblanc FYI |
andygrove
approved these changes
Aug 25, 2026
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
2 participants
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.
Which issue does this PR close?
None.
Rationale for this change
dev/docker/*.Dockerfileare not hermetic. The binary is compiled on the host bydev/build-ballista-docker.sh, and each image then does:COPY target/${RELEASE_FLAG}/ballista-executor /root/ballista-executorSo the host's glibc must be no newer than the base image's. Building on Ubuntu 26.04 (glibc 2.43) against
ubuntu:24.04(glibc 2.39) produces images that fail at the dynamic loader, beforemainruns:The scheduler and executor crash-loop immediately, which on a Kubernetes deployment looks like an application fault rather than a build-environment mismatch.
What changes are included in this PR?
Bumps the five runtime images that copy a host-built binary from
ubuntu:24.04toubuntu:26.04:ballista-schedulerballista-executorballista-benchmarksballista-standaloneballista-clichaos.Dockerfileis deliberately not changed: it builds insiderust:1-bookwormand runs ondebian:bookworm-slim, so it carries its own toolchain and does not depend on the host's glibc.Are these changes tested?
Yes. All five images were rebuilt on this base and exercised on a 4-node EKS cluster running h2o benchmarks at 1e9 rows — scheduler and executors registered and ran queries to completion. Each binary was also smoke-tested inside its image before deploy:
Building on an older host (e.g. CI on
ubuntu-24.04) is unaffected: an older-glibc binary runs fine on a newer base.Are there any user-facing changes?
The published images move to an
ubuntu:26.04userland.One limitation worth stating plainly: this raises the floor rather than making the build hermetic. A host newer than the base image will break again in exactly the same way. The complete fix is to compile inside a container matching the runtime base, at the cost of a separate target directory per image; that seemed like a larger change than this bug warranted, but I'm happy to do it that way instead if maintainers prefer.