You have your driver source code ready to compile, you want to use the Driver-Toolkit image, but can't use OpenShift BuildConfig resources for whatever reason,
While using a BuildConfig is the recommended solution for creating DTK based driver containers, it possible to use the DTK image within a standard Dockerfile, and build an image with podman
For example for the ptemplate_char_dev driver container a standalone Dockerfile might look like:
ARG KERNEL_VERSION
ARG DTK=registry.redhat.io/openshift4/driver-toolkit-rhel9:v4.13.0-202308011445.p0.gd719bdc.assembly.stream as builder
FROM ${DTK} as builder
WORKDIR /usr/src
RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/accelerator_templates.git"]
WORKDIR /usr/src/accelerator_templates/kernel_module/
RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_VERSION}/build make all KVER=${KERNEL_VERSION}
FROM registry.redhat.io/ubi9/ubi-minimal
ARG KERNEL_VERSION
RUN ["microdnf", "install", "-y", "kmod"]
COPY --from=builder /usr/src/accelerator_templates/kernel_module/*.ko /opt/lib/modules/${KERNEL_VERSION}/
RUN depmod -b /opt ${KERNEL_VERSION}
CMD [ "modprobe", "-d", "/opt", "ptemplate_char_dev"]
Then we build the driver container with podman via:
podman build -f Dockerfile.hard --build-arg KERNEL_VERSION=$(uname -r) \
-t quay.io/example/pt-char-dev:$(uname -r) .
This Docker file works in a very similar way to the non-DTK version, downloading the source code from github, and building it with make
, then in the second stage copying over only the .ko file created to a clean minimal image. The big difference is that the first stage does not need to install the build tools first, this removes any issues with entitlements and the availability of packages.