Garden v0.10.0: Your laptop does not need Kubernetes
Note trans. : We got acquainted with Kubernetes-enthusiasts from the Garden project at the recent KubeCon Europe 2019 event, where they made a good impression on us. This material, written on a relevant 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 company's main (same-name) product , whose idea is to automate workflows and simplify application development in Kubernetes. For this, the utility allows you to easily (literally one team) to deploy in the dev-cluster new changes made in the code, and also provides shared resources / caches to speed up the assembly and test the code with the command. Two weeks ago, Garden released a release of 0.10.0 , in which it became possible to use not only the local Kubernetes cluster, but also a remote one: this article is dedicated to this event.
The last thing I love working with Kubernetes on my laptop. "Pilot" absorbs its processor and battery, makes the coolers rotate without stopping and is difficult to maintain.
')
Stock Photo to topic for heightened effect
Minikube, kind, k3s, Docker Desktop, microk8s, etc. - great tools created to use Kubernetes were as convenient as possible, and thank them for that. Seriously. But no matter what side you look at, 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 virtual machine layers. The poor girl is trying her best, but she clearly does not like this occupation, showing her dissatisfaction with the howling of coolers and trying to burn her hips when I rashly put him on my knees.
Let's say: a laptop is a laptop.
Garden is a developer tool that occupies the same niche as Skaffold and Draft. It simplifies and accelerates the development and testing of Kubernetes applications.
From the very beginning of work on Garden, about 18 months ago, we knew that the local development of distributed systems was a temporary solution, so we laid considerable flexibility and a solid foundation for Garden.
Now we are ready to support both local and remote Kubernetes environments. Work has become much easier: 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 cluster Kubernetes and still get a quick response to changes in the code. All of this is free and open source.
Enjoy the same convenience when working with local and remote environments.
And I am glad of it, because we still have a lot of curious chips! The common use of dev clusters has broader implications, especially for cooperative teams and CI pipelines.
How so?
First of all, the intracluster collector — whether it is the standard Docker daemon or Kaniko — as well as the intracluster registry are common to the entire cluster . Your team can use the dev cluster together, while assembly caches and images are available to all developers. Because Garden assigns tags to images based on source hashes, tags and layers are defined uniquely and consistently.
This means that as soon as the developer creates an image, it becomes available to the entire team . Day after day we download the same basic images and do the same builds on computers. It is curious how much traffic and electricity is being wasted? ..
The same can be said about the tests: their results are available to the entire cluster and 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 jump opens the way for your team to a multitude of optimization possibilities - no more extra builds and test runs!
Most of us are accustomed to the fact that CI and local dev are two independent worlds that need to be configured separately (and they do not use the shared cache). Now you can combine them and get rid of too much:
You can run the same commands in CI and in the development process, as well as use a single environment, caches, and test results.
In essence, your CI turns into a bot developer working in the same environment as you.
Elements of the system; unhindered development and testing
It is possible to significantly simplify the configs of the CI pipelines. To do this, just run Garden from CI for builds, tests and deploys. Since you and the CI use the same environment, the likelihood of encountering CI problems is much lower.
Digging into countless lines of configs and scripts, then push'i, waiting, hope and endless repetitions ... All this is in the past. You just do the development. No unnecessary movements.
And to finally clarify the situation: when you or another representative of the team collected or tested something using Garden, the same thing happened for CI . If you did not change anything after the test runs, then there is no need to carry out tests (or even builds) for CI. Garden does everything by itself, and then proceeds to other tasks, such as organizing a pre-launch environment, pushing artifacts, etc.
Welcome to our GitHub repository ! Install Garden and play with examples. For those who already use Garden or want to get to know him better, we offer the Remote Kubernetes Guide . Join us on #garden's Slack Kubernetes channel if you have questions, problems, or just want to chat. We are always ready to help and welcome feedback from users.
Soon we will also publish a review of useful utilities for application developers operating in Kubernetes, which, in addition to Garden, have also included other interesting projects ... In the meantime, read also in our blog:
He talks about the company's main (same-name) product , whose idea is to automate workflows and simplify application development in Kubernetes. For this, the utility allows you to easily (literally one team) to deploy in the dev-cluster new changes made in the code, and also provides shared resources / caches to speed up the assembly and test the code with the command. Two weeks ago, Garden released a release of 0.10.0 , in which it became possible to use not only the local Kubernetes cluster, but also a remote one: this article is dedicated to this event.
The last thing I love working with Kubernetes on my laptop. "Pilot" absorbs its processor and battery, makes the coolers rotate without stopping and is difficult to maintain.
')
Stock Photo to topic for heightened effect
Minikube, kind, k3s, Docker Desktop, microk8s, etc. - great tools created to use Kubernetes were as convenient as possible, and thank them for that. Seriously. But no matter what side you look at, 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 virtual machine layers. The poor girl is trying her best, but she clearly does not like this occupation, showing her dissatisfaction with the howling of coolers and trying to burn her hips when I rashly put him on my knees.
Let's say: a laptop is a laptop.
Garden is a developer tool that occupies the same niche as Skaffold and Draft. It simplifies and accelerates the development and testing of Kubernetes applications.
From the very beginning of work on Garden, about 18 months ago, we knew that the local development of distributed systems was a temporary solution, so we laid considerable flexibility and a solid foundation for Garden.
Now we are ready to support both local and remote Kubernetes environments. Work has become much easier: 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 cluster Kubernetes and still get a quick response to changes in the code. All of this is free and open source.
Enjoy the same convenience when working with local and remote environments.
Got your attention?
And I am glad of it, because we still have a lot of curious chips! The common use of dev clusters has broader implications, especially for cooperative teams and CI pipelines.
How so?
First of all, the intracluster collector — whether it is the standard Docker daemon or Kaniko — as well as the intracluster registry are common to the entire cluster . Your team can use the dev cluster together, while assembly caches and images are available to all developers. Because Garden assigns tags to images based on source hashes, tags and layers are defined uniquely and consistently.
This means that as soon as the developer creates an image, it becomes available to the entire team . Day after day we download the same basic images and do the same builds on computers. It is curious how much traffic and electricity is being wasted? ..
The same can be said about the tests: their results are available to the entire cluster and 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 jump opens the way for your team to a multitude of optimization possibilities - no more extra builds and test runs!
What about CI?
Most of us are accustomed to the fact that CI and local dev are two independent worlds that need to be configured separately (and they do not use the shared cache). Now you can combine them and get rid of too much:
You can run the same commands in CI and in the development process, as well as use a single environment, caches, and test results.
In essence, your CI turns into a bot developer working in the same environment as you.
Elements of the system; unhindered development and testing
It is possible to significantly simplify the configs of the CI pipelines. To do this, just run Garden from CI for builds, tests and deploys. Since you and the CI use the same environment, the likelihood of encountering CI problems is much lower.
Digging into countless lines of configs and scripts, then push'i, waiting, hope and endless repetitions ... All this is in the past. You just do the development. No unnecessary movements.
And to finally clarify the situation: when you or another representative of the team collected or tested something using Garden, the same thing happened for CI . If you did not change anything after the test runs, then there is no need to carry out tests (or even builds) for CI. Garden does everything by itself, and then proceeds to other tasks, such as organizing a pre-launch environment, pushing artifacts, etc.
It sounds tempting. How to try?
Welcome to our GitHub repository ! Install Garden and play with examples. For those who already use Garden or want to get to know him better, we offer the Remote Kubernetes Guide . Join us on #garden's Slack Kubernetes channel if you have questions, problems, 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, have also included other interesting projects ... In the meantime, read also in our blog:
Source: https://habr.com/ru/post/459586/
All Articles