Photo by Tim Wilson

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 Tiltfile.

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.

Rancher Desktop interface on macOS

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: Rancher Desktop open to the "Kubernetes Settings" section highlighting the checkbox for /usr/local/bin/kim

⚠️ kim is still considered experimental!

Since Tilt’s built-in docker_build function does not natively support kim, we can use custom_build instead.

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 Tiltfile. (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 custom_build:

def kim_build(ref, context, deps=None, **kwargs):
        command='kim build -t $EXPECTED_REF ' + shlex.quote(context),
        command_bat='kim build -t %EXPECTED_REF% ' + shlex.quote(context),
        deps=deps or [context],

Now, we can replace our docker_build calls with kim_build calls:

# docker_build(
#     'my-static-site',
#     '.',
#     only=['web/'],
#     live_update=[
#         sync('web/', '/usr/share/nginx/html/')
#     ])
# ⬇️ ⬇️ ⬇️ ⬇️ ⬇️ ⬇️ ⬇️

    deps=['web/', 'Dockerfile'],
        sync('web/', '/usr/share/nginx/html/')

And that’s it!

When we tilt up, we’ll see:

STEP 1/3 — Building Custom Build: [my-static-site]
    Custom Build: Injecting Environment Variables
    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?

  1. Tilt invoked our custom_build command to run kim
  2. No registry push was performed because kim builds directly on the cluster node and we passed disable_push=True and skips_local_docker=True
  3. 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. Because 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 **kwargs.

And of course, you still get all the other Tilt goodies like triggering rebuild on changes and immutable tags.

A full 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!

Both Rancher Desktop and kim are new and evolving fast! We’re always excited to see new tools in the local Kubernetes space - if you’re using Rancher Desktop with Tilt, let us know ❤️


Keep up with Developments in Multi-Service Development
Keep up with Developments in Multi-Service Development

Already have a Dockerfile and a Kubernetes config?

You’ll be able to setup Tilt in no time and start getting things done. Check out the docs! 

Having trouble developing your servers in Kubernetes?