This repository was archived by the owner on Feb 6, 2026. It is now read-only.
Repository navigation
Conversation
github-actions
Bot
added
A-sdf
Dependency Review✅ No vulnerabilities or OpenSSF Scorecard issues found.Scanned FilesNone |
fnichol
force-pushed
the
fnichol/distroless-images
branch
from
January 20, 2026 23:30
1520c15 to
c8ca520
Compare
This change re-introduces container image builds for our core deployed services, namely: - edda - forklift - luminork - pinga - rebaser - sdf - veritech This solution takes a much different approach to how we've built these images in the past. Prior to this change, we've compiled the target binary from scratch in a build container, using the same Nix and Buck2 infrastructure. This proved to be very difficult to initially implement and was hard to maintain it. Furthermore, the images weren't being directly relied upon by the team leading many images to be built in the `si/merge-queue` pipeline that took at least as long as building our primary artifacts (and often longer). The approach taken here uses base images from Google's [Distroless] project which can be thought more of a way to statically build in the *runtime* requirements for a service. In our case, this image provides nothing more than the basic libc/libgcc/ssl/certificate environmental requrements for a dynamically linked Rust binary to work as expected. The container images use Debian 13 as their upstream basis for Glibc, GCC libs, etc. and so are just as compatible as any debian-derived base. So, these container images will use/consume an already-built binary and overlay it onto the image. This makes the image build phase very fast and similar to our "binary artifact" artifacts (which essentially tar up the binary). [Distroless]: https://github.com/GoogleContainerTools/distroless References ---------- - https://github.com/grafana/tempo/blob/main/cmd/tempo/Dockerfile - https://labs.iximiuz.com/tutorials/gcr-distroless-container-images - https://github.com/GoogleContainerTools/distroless - https://youtu.be/lviLZFciDv4?si=o-NWKb5dwgg1nsI- Signed-off-by: Fletcher Nichol <[email protected]>
fnichol
force-pushed
the
fnichol/distroless-images
branch
from
January 20, 2026 23:36
c8ca520 to
d890379
Compare
fnichol
changed the title
Contributor
|
/try |
|
Okay, starting a try! I'll update this comment once it's running... |
Contributor
Author
|
/try |
Contributor
Author
I think that failure was a Docker Hub login flake, re-running the |
|
Okay, starting a try! I'll update this comment once it's running... |
Contributor
Author
|
Figured it out, we're missing a Docker Hub repository for Luminork. We'll get that created and we should be good to go. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This change re-introduces container image builds for our core deployed services, namely:
This solution takes a much different approach to how we've built these images in the past.
Prior to this change, we've compiled the target binary from scratch in a build container, using the same Nix and Buck2 infrastructure. This proved to be very difficult to initially implement and was hard to maintain it. Furthermore, the images weren't being directly relied upon by the team leading many images to be built in the
si/merge-queuepipeline that took at least as long as building our primary artifacts (and often longer).The approach taken here uses base images from Google's Distroless project which can be thought more of a way to statically build in the runtime requirements for a service. In our case, this image provides nothing more than the basic libc/libgcc/ssl/certificate environmental requrements for a dynamically linked Rust binary to work as expected. The container images use Debian 13 as their upstream basis for Glibc, GCC libs, etc. and so are just as compatible as any debian-derived base.
So, these container images will use/consume an already-built binary and overlay it onto the image. This makes the image build phase very fast and similar to our "binary artifact" artifacts (which essentially tar up the binary).
References