Comparison to alternatives¶
Some comparisons may be outdated as we don't check every release. If any of the tools have improved, please open a PR.
As table¶
🌊 Helmwave | Helmfile | Helmsman | |
---|---|---|---|
Syntax | YAML + sprig/gomplate | YAML + sprig | TOML/YAML |
Code style | snake_case | camelCase | camelCase |
Requirements | No | kubectl , helm helm-diff (optional: helm-secrets , helm-s3 , helm-git ) |
kubectl , helm helm-diff |
Helm execution | function call of bundled helm | os.Exec |
os.Exec |
helm diff | function call of bundled helm-diff | os.Exec |
os.Exec |
Live-tracking k8s resources | Kubedog | No | No |
Get application logs | Kubedog | No | No |
Get k8s events | Kubedog and helm progress | No | No |
Labels | tags |
labels |
? |
Manage kube-context via iac | Yes | Yes | Yes |
Parallel releases | Yes | Yes | Releases with the same priority can be executed in parallel. |
Parallel limitations | Smart DAG goroutine count with concurrency limitation | concurrent helm processes | max number of concurrent helm releases to run |
Releases dependencies | depends_on |
needs |
Kind of (priority ) |
Dependencies cross namespaces | via @ |
via / |
No |
Manage pending strategy | Yes | No | No |
Explain graph dependencies | Yes | No | No |
Latest image size | |||
Compatible with helm v2 | No | Yes | Yes |
OCI | registries |
option in repositories |
only pull , not login |
Lifecycle Hooks | Yes (pre_up, post_up, pre_down, post_down, pre_rollback, post_rollback, pre_build, post_build) | Yes (prepare, preapply, presync, preuninstall, postuninstall, postsync, cleanup) | No |
Sub-main config | No | Yes | ? |
manage render values | render option and options for setting delimiters |
by file extension | ? |
Remote values | HTTP/HTTPS only | go-getter |
? |
Planfile | Yes | No | No |
Vault / AWS SSM | via gomplate datasources |
custom functions | ? |
Why not bare Helm?¶
Managing multiple environments¶
Imagine you have multiple environments for same release (e.g. dev, stage, production, etc.). You likely have different settings.
You will likely have bunch of bash scripts that run helm with different values files. It is quite hard to support and improve.
Set up helmwave.yml.tpl
to include different values for different environments.
Check out the example
Passing generated values¶
For example, you need to pass docker image tag.
Either you template values file (e.g. with ansible/jinja2 or any other templater) or you pass every individual value via --set
.
Every values file are templated via sprig
or gomplate
which allows you to generate any values even with external commands.
Check out the example
Install multiple releases¶
Imagine you need to deploy more than 1 release (e.g. deploy 10+ microservices to dynamic feature environment).
Either deploy releases one-by-one or create an umbrella chart (we think it is bad pattern).
All releases are deployed in parallel with a dependency mechanism.
Check out the example
Managing dependencies between releases¶
Imagine you need to deploy some DBMS and an app that uses it. While DBMS is provisioning (or scheduling) your app already starts failing probes. It may lead to failing app release.
Manually deploy releases one-by-one.
Use depends_on
to set up explicit dependencies between releases.
Release stuck in pending state¶
If your CI for some reason killed helm process your next helm upgrade
will fail because release is in pending-upgrade
state.
You need to either do helm rollback
(doesn't work for pending-install
) or helm delete
(destructive in production) and try upgrade one more time.
Use pending_release_strategy
to automatically do rollbacks or delete before upgrade if required.
Live-tracking release¶
You can enable debug logs which will provide you logs of what helm does.
Use kubedog to show status progress.
Check out the example
Why not Helmfile ?¶
We don't consider helmwave as a helmfile killer. Helmfile is an awesome project that really inspired us to implement the same in a bit different way with some other features. Probably there would be no helmwave if there was no helmfile.
Helm execution¶
Helmfile runs helm
via os.Exec
. It means that:
- You need
helm
binary as well as a lot of other dependencies (e.g. libc). Helmfile's official docker image requires for around 300MB. - Helmfile collects, parses and outputs
helm
stdout/stderr. Any helm backward incompatibility (even occasional) may be a big pain in the ass. os.Exec
is not the fastest way to run helm. If 10ns of overhead does really matter to you.
Helmwave runs helm
as an internal bundled library. It means that:
- Helmwave already contains builtin specific (we try to keep it up to date)
helm
version. - There are no helmwave dependencies at all - it can be completely static binary. Official docker image requires for around 30MB. And it can run both in musl and glibc environments.
- We constantly check out new
helm
features and try to enhance them in helmwave.
Live-tracking release¶
Only helm progress is available although there is a discussion about kubedog integration.
Use kubedog to show status progress.
Check out the example
Release stuck in pending state¶
If your CI for some reason killed helm process your next helm upgrade
will fail because release is in pending-upgrade
state.
The same as for helm
Use pending_release_strategy
to automatically do rollbacks or delete before upgrade if required.
Templating engine¶
By templating engine we understand collection of builtin functions for default golang templates.
Helmfile only supports sprig
as a template engine.
Every values file can be templated via sprig
or gomplate
(or even non-templated at all). Gomplate is an awesome huge engine that has a lot of features.