chore: migrate base images to Chainguard - #1
Conversation
Replace public base images with Chainguard equivalents from cgr.dev/spotdraft.com. - Uses -fips variants where available - Build stages use :latest-dev (shell available) - Runtime stages use :latest (minimal) - Platform pinned to linux/amd64
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| @@ -1,9 +1,8 @@ | |||
| FROM openjdk:8u171-jre-alpine3.7 | |||
| FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8 | |||
There was a problem hiding this comment.
ARM Kubernetes nodes cannot run services
The API frontend, cluster manager, and engine pods can still be scheduled on ARM64 nodes while using the fixed linux/amd64 image, so mixed-architecture clusters fail to start them — should we add a kubernetes.io/arch=amd64 scheduling constraint or publish a multi-architecture image?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
api-frontend/Dockerfile around line 1, the image is hard-pinned to `linux/amd64` via
`FROM --platform=linux/amd64`, which makes the artifact incompatible with ARM64 nodes
when Kubernetes schedules there. Refactor the release strategy by either (preferred)
removing the hard platform pin in the Dockerfile and updating the build/publish pipeline
to push a multi-architecture manifest (amd64+arm64), or (fallback) enforce amd64
scheduling by updating the Helm chart templates for the API frontend, cluster manager,
and any engine pods they create to add `nodeSelector`/affinity for
`kubernetes.io/arch=amd64`. Ensure the scheduling constraint is applied consistently to
all pods created by those workloads so mixed-architecture clusters don’t fail
deployments.
| @@ -1,4 +1,4 @@ | |||
| FROM openjdk:8u141-jdk | |||
| FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8-dev | |||
There was a problem hiding this comment.
ARM developer builds fail without emulation
core-builder is forced to linux/amd64, so run_core_builder_in_host, run_core_builder_in_minikube, and build-all-in-minikube fail on ARM64 hosts or Minikube VMs because none provisions QEMU or an amd64 builder — should we preserve host-native resolution or explicitly provision/document amd64 emulation?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
core-builder/Dockerfile around line 1, the image is pinned with `FROM
--platform=linux/amd64`, which forces amd64 execution even when the host/Minikube is
ARM64. Remove the hard-coded `--platform=linux/amd64` so the build can use the native
architecture (or the architecture provided by the Docker build/run context), and update
the Dockerfile comments to instruct how to select amd64 when required (e.g., via build
platform/args). If you cannot remove the pin due to dependency constraints, then
explicitly add/document the required QEMU/binfmt/amd64 builder setup for the ARM64 paths
that call `run_core_builder_in_host`, `run_core_builder_in_minikube`, and
`build-all-in-minikube` so those flows provision amd64 emulation before building.
| # install docker | ||
| RUN \ |
There was a problem hiding this comment.
Core builder image cannot build
The # install docker RUN step in core-builder/Dockerfile invokes Debian's apt-get and add-apt-repository against the cgr.dev.../jdk-fips:8-dev Chainguard base, so the build fails before Maven/Python/Docker CLI setup — should we use apk instead?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
core-builder/Dockerfile around lines 5-8 (the RUN block immediately after switching to
`cgr.dev/spotdraft.com/jdk-fips:8-dev` and under the comment `# install docker`), the
build is using Debian/Ubuntu packaging commands like `apt-get` and `add-apt-repository`,
which are incompatible with the Chainguard base image that uses `apk`. Refactor this RUN
block to use `apk add --no-cache ...` for the required Docker client/engine packages
(and remove any `add-apt-repository`/apt repo logic), keeping the rest of the Dockerfile
setup intact. If equivalent apk packages aren’t available, switch the base image back
to a Debian-based OpenJDK image so the existing apt-based install continues to work.
| FROM --platform=linux/amd64 cgr.dev/spotdraft.com/python-fips:2.7.14-dev | ||
|
|
||
| COPY _wrappers /wrappers | ||
|
|
There was a problem hiding this comment.
Python wrapper image cannot build
wrappers-docker/Dockerfile uses Debian-style apt-get/add-apt-repository on Chainguard python-fips, whose package manager is apk, so the build stops before installing grpcio-tools, jinja2, and tester dependencies — should we replace those steps with apk-compatible commands or use a compatible base image?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
wrappers-docker/Dockerfile around lines 1-4, the base image was switched to
cgr.dev/spotdraft.com/python-fips:2.7.14-dev (apk-based), but the later dependency
installation logic still uses Debian/apt-get-style commands
(apt-get/add-apt-repository), which will fail before grpcio-tools, jinja2, and tester
deps are installed. Refactor the later OS package installation steps to use
apk-compatible equivalents for the same packages, and ensure any repository additions
are removed or replaced with apk-compatible methods; then verify the build succeeds and
that the Python deps are installed as originally intended. If large compatibility
changes are needed, instead revert to a Debian-based python image so the existing
apt-get commands work unchanged.
These Dockerfile lines were left unchanged. |
1 participant
User description
Summary
cgr.dev/spotdraft.com:latest-dev(includes shell):latest(minimal, no shell)linux/amd64Images updated
See Dockerfile diffs above.
🤖 Generated by chainguard-migrate.sh
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Migrate Java and Python container builds to Chainguard FIPS base images from
cgr.dev/spotdraft.com. Pin builds tolinux/amd64and use runtime versus-devimages across application, builder, and wrapper components.jdk-fips:8-devforcore-builderandpython-fips:2.7.14-devforwrappers-docker.Modified files (2)
Latest Contributors(2)
jdk-fips:8, while preserving their application entrypoints.Modified files (3)
Latest Contributors(2)