Note. transl.: With Kubernetes enthusiasts from the project we met at a recent event where they made a good impression on us. This material of theirs, written on a current technical topic and with a noticeable sense of humor, is a clear confirmation of this, and therefore we decided to translate it.
He talks about the main (of the same name) a company whose idea is to automate workflows and simplify the development of applications in Kubernetes. To do this, the utility allows you to easily (literally with one command) deploy new changes made in the code to the dev cluster, and also provides shared resources / caches to speed up the assembly and testing of the code by the team. Two weeks ago, the Garden hosted , in which it became possible to use not only a local Kubernetes cluster, but also a remote one: this article is devoted to this event.
The last thing I like to do is work with Kubernetes on my laptop. Pilot consumes his processor and battery, makes coolers spin non-stop, and is difficult to maintain.
Stock photo in theme for heightened effect
Minikube, kind, k3s, Docker Desktop, microk8s, etc. - excellent tools created in order to use Kubernetes as conveniently as possible, and thanks to them for that. Seriously. But no matter how you look at it, one thing is clear: Kubernetes is not designed to run on my laptop. And the laptop itself is not designed to work with a cluster of containers scattered across layers of virtual machines. The poor thing tries his best, but obviously doesn't like it, showing his displeasure with the howl of coolers and trying to burn his thighs when I recklessly put him on his knees.
Let's say: laptop - laptop.
is a developer tool in the same niche as Skaffold and Draft. It simplifies and speeds up the development and testing of Kubernetes applications.
From the very beginning of work on Garden, about 18 months ago, we knew that local The development of distributed systems is a temporary solution, so Garden has a lot of flexibility and a solid foundation.
We are now ready to support both local and remote Kubernetes environments. It has become much easier to work: assembly, deployment and testing can now be carried out in a remote cluster.
Shortly speaking:
With Garden v0.10, you can completely forget about the local Kubernetes cluster and still get a quick response to changes in the code. All of this is free and open source.
Enjoy the same convenience across local and remote environments
Got your attention?
And I'm glad about it, because we have many more interesting features! The general use of dev clusters has broader implications, especially for collaborative teams and CI pipelines.
How so?
First of all, the intra-cluster builder - be it the standard Docker daemon or Kaniko - as well as the intra-cluster registry are shared for the whole cluster. Your team can share a dev cluster, with build caches and images available to all developers. Since Garden assigns tags to images based on source hashes, tags and layers are uniquely and consistently defined.
This means that once a developer creates an image, it becomes available to the whole team. Day after day, we download the same base images and make the same builds on computers. Curious how much traffic and electricity is wasted?..
The same can be said about tests: their results are available to the entire cluster and to all team members. If one of the developers tested a certain version of the code, there is no need to re-run the same test.
In other words, it's not just that you don't need to run minikube. This leap paves the way for your team to many optimization opportunities - no more unnecessary builds and test runs!
How about CI?
Most of us are used to the fact that CI and local dev are two separate worlds that need to be configured separately (and they do not use a shared cache). Now you can combine them and get rid of the excess:
You can run the same commands in CI and during development, as well as use a single environment, caches and test results.
In essence, your CI turns into a developer bot working in the same environment as you.
Elements of the system; seamless development and testing
You can significantly simplify the configs of CI pipelines. To do this, just run Garden from CI for builds, tests and deployments. Since you and CI use the same environment, you are much less likely to run into CI issues.
Digging through countless lines of configs and scripts, then pushes, waiting, hoping and endless repetitions ... All this is in the past. You are just developing. No extra moves.
And to make things clear: when you or another team member built or tested something with Garden, the same thing happened for CI. If you haven't changed anything since the test runs, then you don't need to run tests (or even builds) for CI. Garden does everything itself and then moves on to other tasks such as setting up a pre-launch environment, pushing artifacts, and so on.
Sounds tempting. How to try?
Welcome to ! Install Garden and play with examples. For those who already use Garden or want to get to know it better, we offer . Join us on the channel if you have questions, concerns or just want to chat. We are always ready to help and welcome feedback from users.
PS from translator
Soon we will also publish a review of useful utilities for application developers operating in Kubernetes, which, in addition to Garden, includes other interesting projects ... In the meantime, read also on our blog:
- Β«";
- Β«";
- Β«";
- «».
Source: habr.com