This article should be useful if you create & apply Helm charts for Kubernetes using the existing solutions drawn from the chart repositories. Following this approach, you can benefit from both community-created and your own recipes, ensuring the timely update of the standard components in all applications and the overall convenience of maintaining solutions.
Having this useful feature in our GitOps utility, werf, we strive to simplify the entire process of operating the infrastructure for applications that are built for and deployed to Kubernetes.
We believe, the main reasons for the popularity of Helm — a so-called “package manager for Kubernetes” — are its official chart repository and the very possibility to use repositories. To a much lesser degree, its popularity is attributable to rich features. The large and loyal community maintains recipes and chart settings. Professionals ensure the relevance of solutions that end-users demand. Each chart of the official repository is standardized and well-documented.
In trivial cases, the user doesn’t even need to create a chart for deploying an application: (s)he just finds a ready-made solution, reads the documentation, adjusts settings, and runs the official chart.
We have been actively using external Helm client in werf for rolling out the application infrastructure for years. Now it is time to make one step further. Starting with version v1.0.4-alpha.10, we have added to werf specific commands for working with dependencies and chart repositories — it allowed us to completely abandon the Helm client*.
* By the way, deploying with werf doesn’t require a Tiller installed in your Kubernetes cluster. Helm is fully embedded into werf, and Tiller is started locally during the time relevant commands are executed only.
Here is the list of key commands:
werf helm repo
add Add a chart repository
fetch Download a chart from a repository and (optionally) unpack it in a local directory
init Init default chart repositories configuration
list List chart repositories
remove Remove a chart repository
search Search for a keyword in charts
update Get the latest information about charts from the chart repositories and store it locally
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file
list List all of the dependencies declared in a chart
update Update charts/ according to the contents of requirements.yaml
Also, we added support for chart references to the
werf helm deploy-chart command.
Here’s how all this “magic” looks in action — to be more precise, here is a comparison of installing of the same chart in werf (left side) and Helm (right side):
More hands-on examples
The following trivial example involving WordPress once again demonstrates the convenience of using ready-made solutions for deploying applications in their entirety. Installing WordPress’ Helm chart to the Kubernetes cluster is incredibly simple with werf and might look like this:
$ cat << EOF > values.yaml
$ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
Recorded by aigrychev
Since repositories contain many various solutions, you can build your own applications with them using Helm charts (on which the whole system depends) as building blocks. Most likely, you’ll only have to configure components correctly to suit your needs.
Let’s suppose, a web application requires a queue, a cache, and a data storage. How do we deploy these components via werf?
Firstly, let’s speed up the search for required components by using CLI:
$ werf helm repo search queue
NAME CHART VERSION APP VERSION DESCRIPTION
stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A...
stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
Similarly, let’s find out the remaining components by searching through registered chart repositories (you can get the list of active repositories by running
werf helm repo list).
Having found all the required components, you can add them to the chart. There are several ways to do it: you can put charts of the components into the
charts directory or create
requirements.yaml file and define dependencies in there and then run
werf helm dependency build|list|update commands on them.
Here is a demonstration of the second scenario:
During this deploy process, werf will create all the dependencies and start tracking them along with the other resources — no additional actions are required.
Thus, using the expertise of the knowledgeable community, you can develop and maintain charts more quickly and easily. Besides, you are not limited to public charts: you might as well install your own charts that are adapted to the specific context.
The lack of critically important features in the existing Open Source solutions forces us to make our own tools, wrappings, integrations. The werf project has been created and is being supported primarily for the everyday needs of our DevOps engineers.
As a matter of fact, a little less than two years ago we opened an issue where described two problems that we were experiencing at that time. We proposed making tracking resources in Helm an alternate mode in the upstream. The community accepted and supported the idea, as many craved for such a feature. However, progress in that direction has been remarkably slow. We have started to see some improvements in Helm 3 just recently.
Until that, the implementation of this idea in Helm was essentially blocked by developers. Fortunately, during that time we have implemented corresponding resource tracking functions in a separate Open Source library named kubedog. We extensively use it in werf. And based on GitHub’s feedback, our library is quite popular among other Kubernetes/Helm users, which is really exciting.
You can support our idea (and its implementation) by starring the kubedog project on GitHub and/or “thumbing up” the original issue in Helm. Thanks in advance!
P.S. This article has been originally written and published in Russian language by Flant’s system developer Alexey Igrychev. More technical stuff from our engineers is to come soon — please don’t forget to follow our blog!