Deploying Helm charts with dependencies in Kubernetes via werf

Please note this post was moved to a new blog: https://blog.werf.io/ — follow it if you want to stay in touch with the project’s news!

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.

Built-in Helm

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
wordpressBlogName: flant
wordpressUsername: admin       
wordpressPassword: password
mariadb:                                                          
  mariadbRootPassword: password
EOF
$ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app

werf helm deploy-chart --values values.yaml stable/wordpress my-web-app

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:

werf deploy chart with dependencies

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.

Here you may find the documentation on werf repository and dependency commands. Also, there is detailed information about the deployment process in werf and major differences from Helm.

Conclusion

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!

Please note this post was moved to a new blog: https://blog.werf.io/ — follow it if you want to stay in touch with the project’s news!

P.S. This article has been written by Flant’s system developer Alexey Igrychev.