I am making an attempt to noodle out make this primary workflow occur in Docker Desktop for Mac, with Kaniko working within a Kubernetes pod:
- Pull a base picture from the native Docker context
- Construct a picture on high of that with different sources
- Publish the brand new picture again to Docker to the native context
with the objective of beginning a brand new pod in Kubernetes that references the picture that was simply constructed, and having Kubernetes launch the pod with that new picture.
We’re already type of doing this in a full-blown Kubernetes cluster the place Kubelet is configured to tug from an exterior registry through an alias of cluster.native so as a substitute of pulling from / publishing to Docker we’re speaking to that registry. The Dockerfile would resemble:
ARG REGISTRY_HOST=exterior.registry.fqdn
FROM ${REGISTRY_HOST}/path/to/my-base-image:1.0.0
COPY ...
RUN ...
...and many others...
and we publish to exterior.registry.fqdn/path/to/my-new-image:2.0.0. However the picture identify spec for the pod could be cluster.native/path/to/my-new-image:2.0.0. So in Docker Desktop we might want to have the ability to configure the construct argument REGISTRY_HOST in order that it factors to the Docker Desktop context (I believe).
That is primarily for having the ability to take a look at the method domestically, as a substitute of getting to push helm charts, and many others. as much as a cluster to check modifications. Any ideas on how one may go about doing one thing like this, maybe with an area registry exterior of Kubernetes and tweaks to kubelet to have it work like the complete cluster configuration we’re utilizing could be vastly appreciated.
If somebody has managed to do one thing like this utilizing colima and kubernetes, I’ll gladly check out that answer as properly.
Is there a basis to start this work or has somebody solved this already?