For added effect, a relevant stock photo.
My least favorite part of working with Kubernetes is running it on my laptop.
It gobbles up my CPU and battery, keeps the fans running non-stop, and it’s a nuisance to maintain.
Minikube, kind, k3s, Docker for Desktop, microk8s, etc. are all good efforts designed to make that as pleasant as possible, and kudos to all of them. Seriously. But no matter how you slice it, Kubernetes isn’t designed to run on my laptop. Nor is my laptop designed to run a cluster of containers in layers of VMs. The poor thing will try its best, but it won’t like it, and will show its dissatisfaction by making its fans scream, and scalding my thighs if I’m not careful.
Let laptops be laptops, we say.
Garden is a tool for developers, in the same area as Skaffold and Draft, that makes developing and testing Kubernetes applications faster and easier.
Since we started working on Garden, about eighteen months ago, we knew that developing distributed systems locally was a stop-gap solution, so we designed Garden with a lot of flexibility in mind and laid some solid foundations.
Now we’re ready to support both local and remote Kubernetes environments, and it’s better than ever: you can now run all your builds, deployments, and tests in a remote cluster.
In short:
With Garden v0.10 you can completely get rid of your local Kubernetes cluster, and still enjoy rapid feedback while you write your code. All free and open source.
Okay, you have my attention.
I’m glad to hear that, dear reader who is totally not me talking to myself, because there’s more!
Sharing development clusters has broader implications, especially for teams working together, and for CI pipelines.
“How so?”
First off, the in-cluster builder — either a standard Docker daemon or Kaniko — and the bundled in-cluster registry are shared cluster-wide. Meaning, your team can share a development cluster, and all the build caches and images are shared across all developers. Because Garden tags your images based on hashes of your source files, the tags and layers are consistent between users.
This means that once any developer has built a version of an image, your whole team has as well. Day in and day out, developers download the same base images and build the exact same things on separate computers. I wonder how much bandwidth and electricity has been wasted on that…
And the same goes for tests: test results are stored cluster-wide and are available for your whole team, in much the same way. Once one developer has tested a version of your code, no-one has to repeat the exact same test.
So it’s not just about not having to run minikube. This leap opens up a lot of optimizations for your team — no more redundant builds and test runs!
What was that about CI?
Most of us are used to local dev and CI being two separate worlds that you need to configure separately — and don’t share a cache. Now you can fold the two together, and get rid of much of that friction:
You can run the same exact commands in CI as when you develop, and use the same environment, caches and test results.
Your CI basically becomes a bot developer working in the same environment as you.
You can drastically simplify your CI pipeline configs. Just run Garden from CI to do the builds, tests, and deploys — and because you and CI use the same environment, you’re much less likely to find yourself debugging CI issues.
All that poking at thousands of lines of configs and scripts, then pushing, waiting, hoping, rinsing, and repeating ad nauseam… None of that. You just develop. No extra steps.
And just to make it crystal clear: When you or anybody on your team has built or tested something with Garden, so has your CI. If you don’t change anything after running tests yourself, your CI doesn’t need to test it again, or even build it. Garden just checks the box and goes straight to your other workflows, like spinning up a preview environment, pushing artifacts, and so on.
Sounds good! How do I try it out?
Hop over to our GitHub repo, install Garden, and try out some examples. If you’re already using Garden, or would like to get straight to the good stuff, check out the Remote Kubernetes Guide.
Join us at the #garden on Kubernetes Slack if you have any questions, problems, or just want to chat. We’re eager to help and get feedback from you.
—
Thanks again for all your help with the post, Ellen Körbes. ❤
