Helmwave is another tool for deploying helm charts

There are a huge number of different tools for deploying applications in Kubernetes. If you look at the corresponding section in CNCF Landscape, you can get lost in the diversity. Therefore, it is sometimes good to have a “silver bullet” in your arsenal that will suit most tasks. Helmwave may well be just such a tool.

Recently, my favorite tool for describing declarative deployments in Kubernetes has been Helmfile. Three non-obvious, but useful features of Helmfile, I considered in a separate article on Medium: “3 Helmfile features you don’t know”.

Helmfile features that are important to note:

• Built-in templating capability.

• Environments with the ability to specify a default configuration.

• Integration with HashiCorp Vault, AWS KMS and other secret management tools.

• Support for the helm diff plugin.

Despite the fact that GitOps and the tools that implement this approach are now at the peak of popularity, there are many questions about them in terms of reliability, manageability and observability. That’s why I’m always on the lookout for new projects: they might be easier to use or better at solving specific problems. That’s how I found Helmwave.

What is Helmwave

The project readme on Github is quite concise and briefly describes the main task of the project:

Helmwave is docker-compose for @helm.

Helmwave is a tool for declarative description of the deployment of helm charts.

Let’s see how it is better or worse than its competitors.

Helmwave Features

Helmwave has all the necessary standard features: everything-as-code, deployment to multiple environments and the ability to set up a default configuration.

But there are also a few obscure ones:

• Step by step deployment (depends_on, allow_failure).

• Monitor Kubernetes resources in real time with kubedog.

• No external dependencies: just download the helmwave binary and you can start deploying.

Helmwave example

For example, I will try to solve a standard task: set up a deployment to several environments from one repository with the possibility of configuration override.

First, let’s look at the project structure:

.
├── .github/
├── .kube-linter/
│   └── config.yaml
├── README.md
├── charts/
│   ├── adservice
│   ...
│   └── shippingservice
├── envs-values/
│   ├── prod
│   └── stage
├── helmwave.yml
├── helmwave.yml.tpl
└── releases.yaml

• In directory .github/ there is a configuration for CI / CD, in my case it is Github Actions.

• AT .kube-linter/ – configuration file for linting manifests.

• AT charts/ — helm-charts for microservices-demo.

• AT envs-values/ store values ​​for stage and production environments.

• helmwave.yml is the file that is rendered from template (helmwave.yml.tpl).

• helmwave.yml.tpl — this is a deployment configuration template.

• releases.yaml — a file with a list of required helm releases and their configurations for deployment.

helmwave.yml.tpl

At the beginning of this file is the version of Helmwave. The latest version is 0.19.5.

version: 0.19.5

.options: &options
  namespace: microservices-demo
  wait: true
  timeout: 300s
  create_namespace: true

releases:
{{- with readFile "releases.yaml" | fromYaml | get "releases" }}
{{ range $v := . }}
- name: {{ $v | get "name" }}
  chart:
    name: charts/{{ $v | get "name" }}
  tags: [{{ $v | get "name" }}]
  values:
    - envs-values/{{ requiredEnv "CI_ENVIRONMENT_NAME"}}/{{ $v | get "name" }}.yaml
  <<: *options
{{ end }}
{{- end }}

In this file, we can use the anchor with default options (.options) and specify it in the section releases, when it is necessary. Thus, we will get the most DRY-config. Typically, a number of default values ​​are set here: namespace, helm options etc. See the full list of options in documentation.

In chapter releases specifies a list of helm releases to be deployed. This list can be found in the file releases.yaml. Each release needs to be given a name and a chart from which to deploy. Other parameters are optional.

Each release also contains:

• Variables for the desired environment, the environment is set by a variable CI_ENVIRONMENT_NAME.

• A tag with the name of the application, which can be used to filter the deployment of specific services.

• Anchor parameters added via << : *options.

releases.yaml

Structure releases.yaml does not require further explanation:

releases:
  - name: adservice
  - name: cartservice
	...
  - name: shippingservice

helmwave.yml

This file will contain the rendered template helmwave.yml.tpl. To generate it, you can run the following command:

$ CI_ENVIRONMENT_NAME=stage helmwave yml

version: 0.19.5

.options: &options
  namespace: microservices-demo
  wait: true
  timeout: 300s
  create_namespace: true

releases:

- name: adservice
  chart:
    name: charts/adservice
  tags: [adservice]
  values:
    - envs-values/stage/adservice.yaml
  <<: *options

	...

- name: shippingservice
  chart:
    name: charts/shippingservice
  tags: [shippingservice]
  values:
    - envs-values/stage/shippingservice.yaml
  <<: *options

Deployment process

For implementing CI/CD, I chose GitHub Actions because they are freely available on GitHub. Moreover, the developers of Helmwave have made an action for them, which helps to quickly and conveniently use different versions of Helmwave in pipelines.

The deployment process consists of three steps: preparing, running tests, and running the deployment in the selected environment.

Training

At the preparation stage, we install the necessary tools – Helmwave and kind, which will create a Kubernetes cluster using containers. Further, depending on the value CI_ENVIRONMENT_NAME preparing a plan for change helmwave.

To define the environment, you can write bash-script or use the capabilities of the selected CI / CD platform.

Example for Github Actions:

- name: Set environment for branch
  run: |
    if [[ $GITHUB_REF == 'refs/heads/main' ]]; then
        echo "CI_ENVIRONMENT_NAME=prod" >> "$GITHUB_ENV"
    else
        echo "CI_ENVIRONMENT_NAME=stage" >> "$GITHUB_ENV"
    fi

For testing and deployment, we need to render helm-charts into ready-made Kubernetes manifests. To do this, you need to run one of the following commands:

# если вы уже запускали helmwave yml
helmwave build

# сгенерировать helmwave.yml и все манифесты сразу
helmwave build --yml

These commands create directory .helmwavewhich contains the required manifests and plan.

Testing

For testing, I use the most popular tools:

They are similar, but each has its own implementation features and test cases, so I decided to use all three in one pipeline.

At this stage, you can use the same command as for generating the plan. But if the deployment is performed in a temporary environment (as in my case), you need to set an additional parameter diff-mode=local, which will render diff changes locally without sending requests to the Kubernetes cluster. This option is also suitable for use in CI.

helmwave build --yml --diff-mode=local

To deploy the application, run the following command:

helmwave up

# если хотите увидеть ход процесса деплоя 
helmwave up --kubedog

# или все сразу
helmwave up --yml --build --kubedog

cleaning

To remove all created resources, you need to run one of the following commands:

helmwave down

# или удалить namespace в Kubernetes
kubectl delete microservices-demo

Helmwave is a complete alternative helmfile and other similar tools. Despite the fact that the project is quite young, it has useful and non-obvious features, and I will watch its development with interest.

From myself, I can recommend using it in a situation where you need to quickly set up an application deployment and be able to monitor the deployment process in real time. Also, helmwave is well suited for CI and test environments due to full support for templating, the ability to receive application logs during its direct deployment and see the diff between what is already in the cluster and the planned changes.

useful links

1. Repository with all code and configuration

2. Helmwave Documentation

3. Helmwave on Github