Skip to content

chore: migrate base images to Chainguard #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sachin-spotdraft wants to merge 1 commit into
base: master
Choose a base branch
from
Open

chore: migrate base images to Chainguard #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions api-frontend/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,8 @@
FROM openjdk:8u171-jre-alpine3.7
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8

@baz-reviewer baz-reviewer Bot Aug 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Severity web_search

Want Baz to fix this for you? Activate Fixer

Fix in Cursor

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.


ARG APP_VERSION=UNKOWN_VERSION

COPY /target/seldon-apife-${APP_VERSION}.jar app.jar
COPY /target/generated-resources /licenses/

ENTRYPOINT [ "sh", "-c", "java -Djava.security.egd=file:/dev/./urandom $JAVA_OPTS -jar app.jar $SPRING_OPTS" ]

3 changes: 1 addition & 2 deletions cluster-manager/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,8 @@
FROM openjdk:8u171-jre-alpine3.7
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8

ARG APP_VERSION=UNKOWN_VERSION

COPY /target/seldon-cluster-manager-${APP_VERSION}.jar app.jar
COPY /target/generated-resources /licenses/

ENTRYPOINT [ "sh", "-c", "java -Djava.security.egd=file:/dev/./urandom $JAVA_OPTS -jar app.jar $SPRING_OPTS" ]

3 changes: 1 addition & 2 deletions core-builder/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM openjdk:8u141-jdk
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8-dev

@baz-reviewer baz-reviewer Bot Aug 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Severity

Want Baz to fix this for you? Activate Fixer

Fix in Cursor

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 \
Comment on lines 3 to 4

@baz-reviewer baz-reviewer Bot Aug 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Severity

Want Baz to fix this for you? Activate Fixer

Fix in Cursor

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.

Expand Down Expand Up @@ -37,4 +37,3 @@ WORKDIR /work

# Define default command.
CMD ["bash"]

3 changes: 1 addition & 2 deletions engine/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM openjdk:8u171-jre-alpine3.7
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/jdk-fips:8

ARG APP_VERSION=UNKOWN_VERSION

Expand All @@ -8,4 +8,3 @@ COPY /target/seldon-engine-${APP_VERSION}.jar app.jar
COPY /target/generated-resources /licenses/

ENTRYPOINT [ "sh", "-c", "java -Djava.security.egd=file:/dev/./urandom $JAVA_OPTS -jar app.jar" ]

4 changes: 2 additions & 2 deletions wrappers-docker/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM python:2.7.14-jessie
FROM --platform=linux/amd64 cgr.dev/spotdraft.com/python-fips:2.7.14-dev

COPY _wrappers /wrappers

Comment on lines +1 to 4

@baz-reviewer baz-reviewer Bot Aug 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Severity

Want Baz to fix this for you? Activate Fixer

Fix in Cursor

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.

Expand Down Expand Up @@ -33,4 +33,4 @@ RUN pip install numpy requests redis flask
WORKDIR /wrappers/python

ENTRYPOINT ["python","wrap_model.py"]
CMD []
CMD []