As a developer, working with Kubernetes in a local environment can sometimes be tedious. However, with Colima for local Kubernetes management and DevX CLI, you can significantly enhance your development workflow. In this guide, I’ll walk you through setting up a local Kubernetes cluster using Colima and leveraging DevX CLI to manage and deploy containerized applications efficiently.

Why Colima?

Colima is a lightweight tool that provides a simple way to run Docker containers and Kubernetes clusters locally. Unlike minikube or kind, Colima integrates seamlessly with macOS and Linux, offering a robust, low-overhead solution. I also worked on an even more basic solution: setting up a VM directly with lima. But Colmia brings everything I need and is such a small layer that I decided to not invest more time into that.

The initial idea was to run the cluster with containerd and have a container registry in the cluster where I push the locally builded images. But I also need Docker to run integration tests with Testcontainers. A possible solution for that could be that I install both, docker and containerd in the VM and expose only Docker to the Host system. In the end, I have not seen a big benefit from having both and decided to run the cluster with docker. To have the cluster running with the same runtime engine as I build the images with brings the benefit that these images are available to the cluster by default and I don’t need a container registry.

With this solution, I only have colima installed on my machine. No Docker Desktop, no Rancher no other VM.

Key Benefits of Colima:

  • Native macOS virtualization with Rosetta support
  • Easy setup with Docker runtime
  • Built-in Kubernetes support
  • Low resource consumption compared to alternatives
  • Docker as runtime option

Getting Started with Colima

To set up Colima for Kubernetes development, install Colima first (if you haven’t already):

brew install colima

Now, start Colima with Kubernetes enabled:

colima start --cpu 8 --memory 26 --disk 50 --vm-type=vz --vz-rosetta --runtime docker --kubernetes

This command:

  • Allocates 8 CPUs and 26GB of memory
  • Provides 50GB of disk space
  • Uses the vz virtualization type with Rosetta translation
  • Enables Docker as the runtime
  • Starts a Kubernetes cluster

After the VM is created the config can be edited eny time. This are only some defaults. You can alse edit a YAML file with all possible customisations directly in the starting prozess with:

colima start --edit

Like the lima cli, you can list all running VM’s with:

colima list

Verify that your cluster is running:

kubectl get nodes

You should see a running node indicating that Kubernetes is up and ready.

The Colima CTL also sets a new Docker context colima. So the next time you build an image you use the runtime inside the VM.

DevX CLI

With a running cluster and a local container runtime, the first problem is solved. Now I needed a way to run my local changes as quick and easy as possible in the cluster. To describe more of my workflow image as a microservice architecture where a port forward is not enough to make sure that the changes really work. Aside from that, I have quite often context switches to changes from colleges or a bug that needed immediate attention.

To solve all that and don’t lose track, I work only with git worktrees where every branch has its own folder. If you are not familiar with worktrees I highly recommend giving it a try. It is much easier that git stash constantly back and forth.

To quickly test if the changes a college has made or start working on a new thing, I needed a tool that supports exactly that. With a configured project in the devx configuration, I have exactly that.

  1. Switch to a new worktree
  2. Set this folder as build context
  3. Build the image and set it in the deployment

Devx uses the buildx extension from Docker to also use the build cache effectively. Even if the first build takes the same time, most of the apps I am working on only need a couple of seconds to run in the local cluster.

Devx uses a separate Dockerfile for each configured project to have only the things in there that are needed for a dev image. Even more: it is possible to define additional files and folders that need to be part of the build context.

Homebrew Installation

brew install zenginechris/tap/devx

Nix Flake Installation

{
  inputs = {
    devx = {
      url = "github:zenginechris/devx";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = {
    devx
  } @ inputs: let
    configuration = {pkgs, ...}: {
      nixpkgs.overlays = [
        (final: prev: {
          devx-cli = devx.packages.${prev.system}.default;
        })
      ];
      environment.systemPackages = [
        pkgs.devx-cli
      ];
  };
}

Managing Projects with DevX CLI

1. Create a New Project

To create a new project, run:

devx new my-app

This command:

  • Initializes a new project
  • Adds it to the DevX configuration
  • Generates a default Dockerfile

2. Set Project Context

Specify the directory containing your application:

devx context my-app ./my-app-folder

3. Edit the Dockerfile

To modify the Dockerfile, use:

devx edit my-app docker

This opens the default editor to update configurations as needed.

Building and Deploying with DevX

1. Build Your Application Image

Once your project is set up, build a Docker image with:

devx build my-app

This process:

  1. Creates a temporary build directory
  2. Copies the project’s context and Dockerfile
  3. Builds a Docker image tagged with the project name and timestamp
  4. Updates the Kubernetes deployment with the new image

2. Deploy to Kubernetes

DevX automatically updates your running Kubernetes deployment. You can check your running pods with:

kubectl get pods

Managing Configurations

DevX stores its configuration in a .config/devx directory. You can manually edit project configurations in:

cd ~/.config/devx
tree

Each project is represented in a devx.toml file. Example:

[[projects]]
name = 'ui'
context = '/Users/chris/github.com/project/ui'
config_path = '/Users/chris/.config/devx/projects/ui'
deployment_name = 'ui'
namespace = 'default'

[[projects]]
name = 'api'
context = ''
config_path = '/Users/chris/.config/devx/projects/api'
deployment_name = 'api'
namespace = 'default'

Conclusion

By combining Colima for local Kubernetes management and DevX CLI for streamlined project handling, you can significantly enhance your development experience. Whether you’re working on microservices or full-scale applications, this setup allows for fast iteration and deployment without the complexities of cloud environments.

Ready to level up your local Kubernetes development? Give Colima and DevX a try today!

Happy coding! 🚀