Jenkins on dev@iostream.pl

Jenkins, Part Two: Disposable Agents and Builder Images

Sun, 12 Jul 2026 17:20:00 +0200

Once again: why all these containers?

The Kubernetes approach — short-lived, disposable things — works beautifully for Jenkins and similar CI/CD systems.

Here is a list of tasks to execute in a place described by a specification, not by a physical location. Whether that place existed five minutes ago or will disappear five minutes from now does not matter all that much.

Look at how the approach to running CI/CD jobs has evolved over the last twenty years:

run the job in a blocking shell script,
run the job directly on the Jenkins master,
run the job on a dedicated Jenkins node,
run the job on one of several dedicated Jenkins nodes.

And now?

run the job inside an ephemeral Pod, created just before the work starts and removed when the work is done.

Hard not to admire that, is it?

And there is more to admire. Each container can provide a different set of tools. Instead of installing everything manually on physical machines, you can point Jenkins at a ready-made image, built by someone else — and if you do not like that one, you can use another.

All right, that is enough admiration for now.

What do we already have?

Quite a lot:

Jenkins running under Kubernetes,
a working container registry,
a PVC for Jenkins data,
a Kubernetes cloud definition in Jenkins,
two already built images that we are about to use.

What else do we need?

Eventually, Jenkins will run jobs such as:

building Python applications,
building Go applications,
building Hugo sites.

So we need three images.

Python builder

The Python image can be built from the following Dockerfile:

FROM registry.lab.local/base-builder:0.1

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 python3 \
 python3-pip \
 python3-venv \
 python3-build \
 && rm -rf /var/lib/apt/lists/*

RUN python3 -m pip install --break-system-packages \
 build \
 twine \
 wheel \
 setuptools \
 pytest \
 ruff

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Wait a moment. Do not reach for docker build yet.

Actually, do not reach for it at all.

Put this Dockerfile into a source repository, preferably in a dedicated subdirectory. Later it will be much easier to tell what kind of creatures are being produced from it.

We are about to enable a tiny bit of magic. If you are not ready, perhaps take a short walk.

Jenkins can wait. That is, after all, usually its main job.

Create a Jenkinsfile with the following contents:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/python-builder'
 IMAGE_TAG = '3.11.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} python-3"
 currentBuild.description = "python-builder:3, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/python-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Commit it to the same repository, in the same subdirectory as the Dockerfile.

The cluster needs one additional ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: kaniko-docker-config
 namespace: jenkins
data:
 config.json: |
 {
 "auths": {}
 }

The Jenkinsfile refers to this ConfigMap in the agent section.

Now create a new Multibranch Pipeline job. Give it a sensible name, for example python-builder, and configure it:

enter the repository URL,
if credentials are required, select them, or add them first,
under Build configuration → Mode, make sure by Jenkinsfile is selected,
in Script Path, enter the path to the file, for example python-builder/Jenkinsfile.

Save the job and wait a moment.

Jenkins will start scanning branches in your repository, looking for the specified Jenkinsfile in each of them. If it finds one, it will try to run the job for that branch.

Once the Stage View starts rendering, you can observe what is happening in the jenkins namespace:

kubectl get pods -n jenkins -w

A new Pod will appear, do its job, and leave, as in the example below:

NAME READY STATUS RESTARTS AGE
jenkins-0 1/1 Running 12 (57m ago) 19d
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Pending 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 ContainerCreating 0 0s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Running 0 1s
python-builder-main-1-30xvv-l1cp7-vcw9m 3/3 Terminating 0 63s
python-builder-main-1-30xvv-l1cp7-vcw9m 0/3 Error 0 93s

The job completed successfully and the python-builder image landed in the registry.

You can verify that either through registry-ui or directly:

curl http://registry.lab.local/v2/python-builder/tags/list

The response should look like this:

{"name":"python-builder","tags":["3.11.1"]}

The image is now ready to use.

What just happened?

The contents of the Jenkinsfile definitely deserve an explanation, so let us start from the beginning.

`agent`

The agent section is without a doubt the most interesting part of this file.

Besides the type name, kubernetes, it contains a full Kubernetes Pod definition. In the specification we can see that:

hostAliases are used, because we do not have proper DNS here and still need to smuggle the registry address into the Pod,
all important containers are listed:
- base, which provides Git and basic shell tools,
- kaniko, which provides… well, kaniko.

Keeping the names consistent is important.

If you name the containers something like the_one_with_git and the_one_with_kaniko, you will have to use exactly those names later in the actual pipeline steps:

stages {
 stage('Prepare') {
 steps {
 container('the_one_with_git') {

In short: Jenkins creates an agent described in the agent section, and pipeline steps are executed inside specific containers from that Pod — the ones that provide the required tools.

This is the important part.

We are not installing build tools inside the main Jenkins server. The server only orchestrates work. The tools live in disposable containers, created only for the job that needs them.

That keeps the Jenkins controller cleaner, makes builds easier to reproduce, and avoids the traditional CI server problem where one machine slowly turns into a museum of forgotten compilers, package managers, SDKs, symlinks and emotional damage.

`kaniko`

Remember that kaniko is not Docker.

Its job is simply to build a container image and push it to a registry.

The important parameters are:

--context — the working directory, usually the job workspace,
--dockerfile — the location of the Dockerfile, in this case inside a subdirectory,
--destination — the registry location, image name and tag to push after the build.

Simple? Simple.

“But wait!” you might shout. “What about that mysterious kaniko-docker-config ConfigMap?”

Here it is.

kaniko likes to look inside /kaniko/.docker, mainly for a config.json file containing credentials, if they are required.

Our registry does not require authentication, but we still mount a ConfigMap there and provide an empty auths object:

{
 "auths": {}
}

This allows kaniko to try pushing the image anonymously right away.

Go builder

Not enough examples? Fine. Let us create a go-builder.

The Dockerfile could look like this:

FROM golang:1.26-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
 git \
 openssh-client \
 ca-certificates \
 curl \
 wget \
 jq \
 make \
 rsync \
 && rm -rf /var/lib/apt/lists/*

RUN update-ca-certificates

USER root

WORKDIR /workspace

RUN go version

CMD ["sleep", "infinity"]

And the Jenkinsfile could look like this:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: base
 image: registry.lab.local/base-builder:0.1
 command: ["sleep"]
 args: ["infinity"]
 - name: kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/go-builder'
 IMAGE_TAG = '1.26.1'
 }

 stages {
 stage('Prepare') {
 steps {
 container('base') {
 script {
 env.GIT_SHA = sh(
 script: 'git rev-parse --short HEAD',
 returnStdout: true
 ).trim()

 currentBuild.displayName = "#${env.BUILD_NUMBER} go-${env.IMAGE_TAG}"
 currentBuild.description = "go-builder:${env.IMAGE_TAG}, commit ${env.GIT_SHA}"
 }

 sh '''
 echo "GO_VERSION=${IMAGE_TAG}"
 echo "IMAGE=${IMAGE_NAME}:${IMAGE_TAG}"
 ls -la
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/go-builder/Dockerfile" \
 --destination "${IMAGE_NAME}:${IMAGE_TAG}" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }

 post {
 success {
 echo "Built and pushed ${IMAGE_NAME}:${IMAGE_TAG}"
 }
 }
}

Yes, you do not need to rub your eyes in disbelief.

This Jenkinsfile looks almost identical to the previous one. The agent definition is the same, the kaniko invocation is the same, and the base image usage is the same. In practice, only names, version numbers and file paths change.

Simple? Simple.

Example use case

If you have a Go application lying around, you can use a Jenkinsfile like this one.

In this example, the test application is called rme:

pipeline {
 agent {
 kubernetes {
 yaml '''
apiVersion: v1
kind: Pod
spec:
 hostAliases:
 - ip: "10.10.10.24"
 hostnames:
 - "registry.lab.local"
 containers:
 - name: rme-go-builder
 image: registry.lab.local/go-builder:1.26.1
 command: ["sleep"]
 args: ["infinity"]
 - name: rme-kaniko
 image: registry.lab.local/kaniko-builder:latest
 command: ["sleep"]
 args: ["infinity"]
 volumeMounts:
 - name: docker-config
 mountPath: /kaniko/.docker
 volumes:
 - name: docker-config
 configMap:
 name: kaniko-docker-config
'''
 }
 }

 environment {
 IMAGE_NAME = 'registry.lab.local/rme'
 }

 stages {
 stage('Prepare') {
 steps {
 container('rme-go-builder') {
 script {
 env.VERSION = env.GIT_COMMIT.take(7)

 currentBuild.displayName = "#${env.BUILD_NUMBER} ${env.VERSION}"
 currentBuild.description = "${env.IMAGE_NAME}:${env.VERSION}"
 }
 }
 }
 }

 stage('Build binary') {
 steps {
 container('rme-go-builder') {
 sh '''
 git config --global --add safe.directory "$WORKSPACE"
 CGO_ENABLED=0 GOOS=linux go build -o rme .
 '''
 }
 }
 }

 stage('Build and push image') {
 steps {
 container('rme-kaniko') {
 sh '''
 /kaniko/executor \
 --context "${WORKSPACE}" \
 --dockerfile "${WORKSPACE}/Dockerfile" \
 --destination "${IMAGE_NAME}:${VERSION}" \
 --destination "${IMAGE_NAME}:latest" \
 --insecure \
 --skip-tls-verify \
 --insecure-registry registry.lab.local
 '''
 }
 }
 }
 }
}

The application Dockerfile can be very small:

FROM scratch

COPY rme /rme

EXPOSE 9101

ENTRYPOINT ["/rme"]

This is a more realistic example.

It uses a dedicated builder image, go-builder, to compile the Go application, and kaniko only for building and pushing the final container image.

A few details are worth noticing, because the devil usually lives exactly there:

container names matter, because they are later used in container(...) blocks,
the second --destination in the kaniko invocation:

--destination "${IMAGE_NAME}:latest" \

is intentional.

The latest tag will not magically appear in our registry by itself. If we want the most recently pushed image to also be available as latest, we need to tag and push it that way.

Summary and notes

As you can see, there is less and less that we strictly must do inside the cluster, and more and more that we can do in a controlled and repeatable way.

Versioned configuration, job history, artifact history, example applications, builds running inside containers — quite a lot is happening here.

Why use a Multibranch Pipeline?

Good question, but the answers are fairly obvious:

we do not have to clone the repository manually or hard-code credentials in the Jenkinsfile,
test branches do not require separate Jenkins jobs,
Jenkins detects new branches automatically,
deleted branches can disappear from Jenkins automatically as well,
each branch can have its own version of the Jenkinsfile,
pull requests are handled in a much cleaner way.

And now a suspicious thought appears.

What if we put all those YAML files under version control and let some clever mechanism take care of them automatically, instead of calling kubectl by hand every few minutes?

Could such a thing exist?

Who knows.

Jenkins in Kubernetes: Bring a Bucket

Sat, 11 Jul 2026 11:10:00 +0200

Warning: working with Jenkins requires a lot of determination. It is also wise to prepare a bucket in advance — for blood, sweat, tears, and all the failed pipelines.

There. I warned you.

Why Jenkins?

Jenkins has accumulated enough myths and urban legends to deserve several dedicated episodes of a good television show about mysterious phenomena and conspiracy theories.

For now, let us focus on a few practical facts:

Jenkins is a true Swiss Army knife in the CI/CD world.
Jenkins is worth knowing, because it may be lurking just around the corner in the organization you are about to join.
Jenkins is easy to run both locally and centrally.
Thanks to its many plugins, Jenkins can probably be used for almost anything.
You do not have to spend your life clicking around the UI. Jenkins Pipelines do their job.
It is worth getting familiar with Jenkins if only to form your own opinion about what you actually need from a CI/CD ecosystem.

A pinch of history

Jenkins originally started as a tool for building Java code, wrapped in a convenient web service available to everyone.

At first it was called Hudson, and perhaps it would still be called that today, but Sun Microsystems — where Hudson was created — was acquired by the large and not particularly cuddly company known for large and not particularly agile databases.

Then came a dispute over the name and project ownership. A fork appeared, someone proposed a new name, and off it went.

If this reminds you of MariaDB, congratulations: your pattern recognition module is working correctly.

Jenkins in a Kubernetes cluster

We will use Jenkins not only to build containers, but also to build regular applications and run ordinary tasks using purpose-built containers.

Requirements

Jenkins stores data on disk, so we will need a PersistentVolumeClaim.

From the cluster’s point of view, the main Jenkins server will run as a StatefulSet. An Ingress controller will provide HTTP(S) access through the address jenkins.lab.local.

As usual in this lab, add the following line to /etc/hosts on every machine that needs to access Jenkins, including your workstation:

10.10.10.24 jenkins.lab.local

The image

You can use an existing Jenkins image, for example the latest LTS image.

I do not recommend doing that here.

The bucket for blood, sweat and tears would need to be emptied far too often, with very little benefit. It is better to commit a custom image yourself — or in pairs, because at some point the basement nerds need someone to hold the light bulb.

Dockerfile

The Dockerfile looks like this:

FROM jenkins/jenkins:lts-jdk21 AS jenkins-tools

FROM eclipse-temurin:21-jre-jammy

ARG JENKINS_VERSION=2.555.3

USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
 curl \
 git \
 openssh-client \
 ca-certificates \
 tini \
 fontconfig \
 jq \
 unzip \
 zip \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -d /var/jenkins_home -u 1000 jenkins

RUN mkdir -p /usr/share/jenkins /var/jenkins_home /usr/share/jenkins/ref/plugins

RUN curl -fsSL \
 -o /usr/share/jenkins/jenkins.war \
 "https://get.jenkins.io/war-stable/${JENKINS_VERSION}/jenkins.war"

COPY --from=jenkins-tools /usr/bin/jenkins-plugin-cli /usr/bin/jenkins-plugin-cli
COPY --from=jenkins-tools /opt/jenkins-plugin-manager.jar /opt/jenkins-plugin-manager.jar

COPY plugins.txt /tmp/plugins.txt

RUN JENKINS_WAR=/usr/share/jenkins/jenkins.war \
 JENKINS_HOME=/usr/share/jenkins/ref \
 jenkins-plugin-cli \
 --war /usr/share/jenkins/jenkins.war \
 --plugin-file /tmp/plugins.txt

RUN chown -R jenkins:jenkins /usr/share/jenkins /var/jenkins_home

USER jenkins

ENV JENKINS_HOME=/var/jenkins_home

VOLUME /var/jenkins_home

EXPOSE 8080 50000

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["java", "-Djenkins.install.runSetupWizard=false", "-jar", "/usr/share/jenkins/jenkins.war", "--httpPort=8080"]

You can put plugins in plugins.txt and install them directly into the image.

You can also install them later, because Jenkins will have persistent storage. Whether this is a convenience or the beginning of a future archaeology project depends on your level of optimism.

Building the image

The image is built for the arm64 architecture:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

The most likely result at this point is something like this:

> [stage-1 2/11] RUN apt-get update && apt-get install -y --no-install-recommends curl git openssh-client ca-certificates tini fontconfig jq unzip zip && rm -rf /var/lib/apt/lists/*:
0.126 exec /bin/sh: exec format error

Which means we need to help Docker understand how to run arm64 binaries:

docker run --privileged --rm tonistiigi/binfmt --install arm64

A successful installation should produce something like this:

Installing: arm64 OK
{
 "supported": [
 "linux/amd64",
 "linux/amd64/v2",
 "linux/amd64/v3",
 "linux/arm64",
 "linux/386"
 ],
 "emulators": [
 "python3.14",
 "qemu-aarch64"
 ]
}

Now we can build the image again:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/jenkins-lab:0.0.1 \
 --push .

Cluster objects

For Jenkins to work properly, we need a few Kubernetes objects.

Namespace

The simplest way to create the namespace is:

kubectl create namespace jenkins

If you keep your configuration under version control — and you should, because future you has enough problems already — use a manifest instead:

---
apiVersion: v1
kind: Namespace
metadata:
 name: jenkins

PersistentVolumeClaim

The PVC definition looks like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: jenkins-home
 namespace: jenkins
spec:
 accessModes:
 - ReadWriteOnce

 resources:
 requests:
 storage: 20Gi

 storageClassName: local-path

ServiceAccount and Role

Jenkins needs permission to create and manage agent Pods in its namespace.

The following definitions are enough for this lab:

apiVersion: v1
kind: ServiceAccount
metadata:
 name: jenkins
 namespace: jenkins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/exec", "pods/log", "persistentvolumeclaims"]
 verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]
 - apiGroups: [""]
 resources: ["secrets", "configmaps"]
 verbs: ["get", "list", "watch"]
 - apiGroups: [""]
 resources: ["events"]
 verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: jenkins-agent-manager
 namespace: jenkins
subjects:
 - kind: ServiceAccount
 name: jenkins
 namespace: jenkins
roleRef:
 kind: Role
 name: jenkins-agent-manager
 apiGroup: rbac.authorization.k8s.io

Service and Ingress

Now we need a Service and an Ingress:

apiVersion: v1
kind: Service
metadata:
 name: jenkins
 namespace: jenkins
spec:
 selector:
 app: jenkins
 ports:
 - name: http
 port: 8080
 targetPort: http
 - name: agent
 port: 50000
 targetPort: agent
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: jenkins
 namespace: jenkins
spec:
 ingressClassName: nginx
 rules:
 - host: jenkins.lab.local
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: jenkins
 port:
 name: http

StatefulSet

Finally, the StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: jenkins
 namespace: jenkins
spec:
 serviceName: jenkins
 replicas: 1

 selector:
 matchLabels:
 app: jenkins

 template:
 metadata:
 labels:
 app: jenkins

 spec:
 serviceAccountName: jenkins
 nodeSelector:
 przeznaczenie: ci-cd

 volumes:
 - name: jenkins-home
 persistentVolumeClaim:
 claimName: jenkins-home

 containers:
 - name: jenkins
 image: registry.lab.local/jenkins-lab:0.0.1
 imagePullPolicy: Always

 ports:
 - name: http
 containerPort: 8080
 - name: agent
 containerPort: 50000

 env:
 - name: JENKINS_HOME
 value: /var/jenkins_home
 - name: JAVA_OPTS
 value: "-Djenkins.install.runSetupWizard=false"

 volumeMounts:
 - name: jenkins-home
 mountPath: /var/jenkins_home

 startupProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 60

 readinessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 10
 failureThreshold: 12

 livenessProbe:
 httpGet:
 path: /login
 port: http
 periodSeconds: 30
 failureThreshold: 10

Save all of the above definitions as YAML files and apply them with kubectl.

First start

Jenkins should start and greet us by asking for the initial token.

That token can be found in the depths of its home directory on the PVC. After that, it is the usual Jenkins ritual: administrator account, password, pending plugins, and all the other traditional rites of passage.

A freshly started Jenkins is a strange creature.

On one hand, it can be armed to the teeth with plugins. On the other hand, it is as naked as a jaybird. It does not have any build tools installed — but that is fine. We do not really need them.

The actual work will be done by purpose-built containers, created only when needed.

Configuring the Kubernetes cloud

This is where the Jenkins Cloud configuration comes in.

Configure it like this:

Manage Jenkins → Clouds → Add a new cloud → Kubernetes
Name: kubernetes, or any other name you prefer
Kubernetes URL: https://kubernetes.default.svc
Kubernetes namespace: jenkins
Enable WebSocket
Jenkins URL: http://jenkins.jenkins.svc.cluster.local:8080

Save the configuration.

Now all that remains is to create a few useful images, wire them into Jenkins pipelines, and then use them, use them, and use them some more.

Base builder

The first image will be… a base image for building other, better base images.

What does that mean?

The plan is for Jenkins to build many different applications, and also run jobs that may not build anything at all, but still need containers with specific tools inside.

There are two ways to approach this problem:

create one large image with every possible tool inside,
create many small, specialized images and use each one only when needed.

The second approach is easier to maintain.

The Dockerfile for the base builder looks roughly like this:

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
 ca-certificates \
 curl \
 wget \
 git \
 openssh-client \
 bash \
 make \
 jq \
 yq \
 tar \
 gzip \
 xz-utils \
 unzip \
 zip \
 rsync \
 file \
 procps \
 iputils-ping \
 dnsutils \
 && rm -rf /var/lib/apt/lists/*

RUN useradd -m -u 1000 builder

USER builder
WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/base-builder:0.1 \
 --push .

Kaniko builder

The second image will contain kaniko, mainly for building container images.

Note: this is a lab setup. Kaniko works well enough for our purposes here, but before using it in production, check the current state of the project and consider alternatives such as Buildah or Podman. The CI/CD ecosystem moves quickly, usually while pretending it is doing so in a controlled manner.

Yes, kaniko is simpler to use than Docker in this setup. It does not require root privileges and it does not need a Docker daemon.

The Dockerfile can look like this:

FROM gcr.io/kaniko-project/executor:latest AS kaniko

FROM alpine:3.21

RUN apk add --no-cache \
 ca-certificates \
 bash \
 coreutils \
 curl \
 git

COPY --from=kaniko /kaniko /kaniko

ENV PATH="/kaniko:${PATH}"

WORKDIR /workspace

CMD ["sleep", "infinity"]

Build it like this:

docker buildx build \
 --platform linux/arm64 \
 -t registry.lab.local/kaniko-builder:0.1 \
 --push .

These two images need to be built manually.

All the other ones will be created later by Jenkins itself.

If you managed to get here in one piece, that is already quite good. In the next episode, we will learn how to make actual use of our newly assembled toys.