Switch from Docker Desktop to Rancher Desktop in 5 Minutes
UPDATE: There is a
kim Tilt extension available!
If you want to get building using
kim as fast as possible, check out the usage instructions for how to add it to your
If you’re interested in how Tilt extensions for non-Docker container builders work, read on!
Rancher Desktop is a new way to run Kubernetes on macOS and Windows.
While there are some similarities with Docker Desktop due to using a transparent VM, Rancher Desktop does not include the Docker Engine.
Instead, images are built with
kim (Kubernetes Image Manager), which uses a BuildKit daemon bound to the containerd socket on a Kubernetes node.
If your eyes glazed over during the second half of that sentence: images are built directly within the Kubernetes cluster using the same underlying technology (BuildKit) as Docker.
You’ll need to activate the
kim symlink from the Rancher Desktop settings for Tilt to be able to use it:
⚠️ kim is still considered experimental!
To start, if you’re using Tilt < v0.22.7, you’ll need to approve the Rancher Desktop Kubernetes context:
Place this as early as possible in your
(By default, Tilt will only run against a built-in set of known context names corresponding to local K8s cluster tools such as minikube or KIND to prevent an accidental deploy to prod! 😰)
Let’s create a
kim_build function that uses
def kim_build(ref, context, deps=None, **kwargs): custom_build( ref, command='kim build -t $EXPECTED_REF ' + shlex.quote(context), command_bat='kim build -t %EXPECTED_REF% ' + shlex.quote(context), deps=deps or [context], disable_push=True, skips_local_docker=True, **kwargs )
Now, we can replace our
docker_build calls with
# docker_build( # 'my-static-site', # '.', # only=['web/'], # live_update=[ # sync('web/', '/usr/share/nginx/html/') # ]) # ⬇️ ⬇️ ⬇️ ⬇️ ⬇️ ⬇️ ⬇️ kim_build( 'my-static-site', '.', deps=['web/', 'Dockerfile'], live_update=[ sync('web/', '/usr/share/nginx/html/') ])
And that’s it!
tilt up, we’ll see:
STEP 1/3 — Building Custom Build: [my-static-site] Custom Build: Injecting Environment Variables EXPECTED_REF=my-static-site:tilt-build-1630528500 Running custom build cmd "kim build -t $EXPECTED_REF ." ... STEP 2/3 — Pushing my-static-site:tilt-build-1630528500 Skipping push: custom_build() configured to handle push itself STEP 3/3 — Deploying Injecting images into Kubernetes YAML Applying via kubectl: → my-static-site:deployment ...
What just happened?
- Tilt invoked our
custom_buildcommand to run
- No registry push was performed because
kimbuilds directly on the cluster node and we passed
- Deployment was applied to our Rancher Desktop cluster!
You might have noticed that we also passed Live Update steps, yet didn’t add any custom logic within
kim_build to handle it.
custom_build supports Live Update regardless of how you build your images, we passed through the
live_update and any other non-
kim specific arguments via
And of course, you still get all the other Tilt goodies like triggering rebuild on changes and immutable tags.
kim_build implementation might take more arguments, e.g. custom path to
Dockerfile, build args, and more.
There is a
kim_build extension available and we’re always open to PRs to improve it!