Using werf to roll out complex Helm charts

The article is devoted to the development of Helm charts for Kubernetes using ready-made solutions from chart repositories. With this approach, the user applies community recipes or his own, ensuring timely updating of the standard components of all his projects and the convenience of maintaining solutions in general.



Such a convenient feature is now built into our werf GitOps utility, which should simplify the entire process of operating the infrastructure for applications assembled and rolled out to Kubernetes.

Built-in Helm

Perhaps the main success of Helm - the “package manager for Kubernetes” - is associated not so much with its functionality as with the official chart repository and support for repositories in general. Recipes and chart settings are accompanied by a huge community. Specialists support current solutions that are required by end users. Each chart of the official repository is standardized and well documented.



In trivial cases, the user does not even need to create a chart to roll out the application: he just finds a ready-made solution, reads the documentation, prepares the settings and uses the official chart.



For a long time, we have been actively using Helm inside werf to roll out the application infrastructure and now we go further. Starting with version v1.0.4-alpha.10 , commands for working with dependencies and chart repositories have been added to werf to completely abandon the Helm client.



The main commands for this:

• werf helm repo
  
  
  
  
  
  
  
  

   add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in 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 Update information of available charts locally from chart repositories
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• werf helm dependency
  
  
  
  
  
  
  
  

   build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

Plus, the werf helm deploy-chart



command werf helm deploy-chart



added support for chart reference .



And this is how all this magic looks in action - more precisely, here we show a comparison of the rollout of the same chart in werf (left) and in Helm (right):

More practice

Returning to the convenience of using ready-made solutions for rolling out entire applications - a commonplace example with WordPress . Rolling out his Helm chart to the Kubernetes cluster using werf 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

→ Demonstration in asciicinema .



Since repositories contain many solutions , you can build your own applications from them as cubes, where the cubes will be the various Helm charts on which the whole system depends. Most likely, you only need to properly configure the components to your needs.



For example, a web application requires a queue, cache, and data storage. How do we deploy these components through werf?



To get started - let's speed up the search for everything you need using the 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...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

By analogy, we will find the remaining components for all registered chart repositories (the list of used repositories can be seen by running the werf helm repo list



command).



After everything is found, it remains only to add them to the chart. There are several ways to do this: add component charts to the charts directory or create a requirements.yaml



file and describe the dependencies, and then interact with them using special werf helm dependency build|list|update



commands.



Illustration of the second path:

 $ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

→ Demonstration in asciicinema .



In the rollout process, werf will create all the dependencies and track them along with the rest of the resources - no additional actions are required.



As a result, taking into account the expertise of the experienced community, you significantly save time on the development and maintenance of charts. However, no one restricts you to using public charts: you can roll out your charts with equal success, the configuration of which is prepared taking into account the required specifics.



The documentation on repository and dependency commands in werf is presented here . You may also be interested in reading the documentation for more details about rolling out to werf and the main differences from Helm .

Conclusion

The absence of features critical for us in existing Open Source solutions forces us to create the corresponding capabilities, bindings, and integration. The werf project was created and supported, first of all, to solve the everyday tasks of our DevOps engineers.



As an example, we have been working for a long time (second year!) So that our proposal for tracking resources in Helm is accepted as an alternative mode in the main code base of the project (upstream). The community accepted and supported the idea, as many need this opportunity. However, progress in this direction began in Helm 3 and only now ...



Until now, the implementation of this idea in Helm has been virtually blocked by developers. However, during this time we have developed the corresponding resource tracking functions in a separate Open Source library - kubedog - and we are already using it in werf. And judging by the activity on GitHub, the library found interest among other Kubernetes / Helm users, which is very pleasing.



You can support our idea (and implementation) by placing a star on the kubedog project on GitHub and / or thumbs up in the original issue in Helm. Thank!

PS

Read also in our blog:

• A series of notes on innovations in werf:
  
  
  • “ Support for monorepo and multirepo in werf and what does the Docker Registry have to do with it ”;
  • “ Now Docker-images can be built in werf using the usual Dockerfile ”;
• "A sober look at Helm 2:" That's what it is ... " ";
• “ A practical introduction to the package manager for Kubernetes - Helm ”;
• “ Introducing the kubedog library for tracking Kubernetes resources. ”