Helmfile post-HelmV3

As Helm enjoys a newly released V3, I decided it was a good opportunity to try it out with Helmfile and see how the ecosystem is shaping up.

For those who have been living in a cave, Helm is rapidly becoming the defacto tool for Kubernetes manifest templating, management and packaging.

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

Helmfile takes this a step further and allows you to orchestrate multiple Helm Charts through a single file, negating the need for lots of shell scripts and passing variables around.

Helmfile is a declarative spec for deploying helm charts. It lets you…

Keep a directory of chart value files and maintain changes in version control.

Apply CI/CD to configuration changes.

Periodically sync to avoid skew in environments.

You could think of this a bit like a monad that can be used to apply your specific configuration to chart from various repositories/hubs.

This configuration could be overriding values in the traditional helm way or to do advanced layering of configuration based on environment or even an Ansible role style approach to defining infrastructure. The abstraction that Helmfile provides unlocks doors intellectually in how we define our architecture.

A simple ecosystem where Helmfiles are powerful mechanisms for orchestrating & coordinating charts.

Coordination

As per the image above, I’ve used Artifactory to combine both local and remote helm chart mirrors, but you can do this easily within a Helmfile to provide a source of truth for all of your Kubernetes template configurations.

However, if you want to have your own chart repo, perhaps not in the wider Helm chart ecosystem, that’s easy too with helm-git…

repositories:
- name: stable
  url: https://kubernetes-charts.storage.googleapis.com
- name: helm-virtual
  url: https://mysupersecretartifactory.internaldns.com
- name: polaris
  url: git+https://github.com/reactiveops/polaris@deploy/helm?ref=master

What is really cool about this is that we’re able to aggregate from multiple repositories, this is especially satisfying when working for companies that traditionally would take a vendor clone of open source repositories. This way we can pull in our local super secret Charts and treat them like any other.

For example here we can lock Prometheus to a version just like you would with raw Helm. We’re also then defining our closed source chart and pulling it into the mix.

releases:
- name: prometheus
  namespace: monitoring
  chart: stable/prometheus
  version: 9.0.0
  set:
  - name: rbac.create
    value: false
- name: api-gateway
  namespace: default
  chart: helm-virtual/api-gateway
  version: 1.0.0
  set:
  - name: prometheus.scape.enabled
    value: true

Environments & personas

Another joy of Helmfile abstraction is you can create a repository to describe your infrastructure in a way that doesn’t require a meta Helm Chart with nested sub charts.

The following structure is a simple example I’ve used for pick up and play set of personas.

├── environments
│   ├── development
│   │   └── values.yaml
│   ├── production
│   │   └── values.yaml
│   └── qa
│       └── values.yaml
└── persona
    ├── developer
    │   ├── gateway.yaml
    │   └── microservices.yaml
    ├── devops
    │   └── observability.yaml
    └── operations
        └── alerting.yaml

With Helmfile sync aligning your Kubernetes cluster to the desired set of deployed Helm releases. For example…

helmfile --file=persona/devops/alerting.yaml

Will deploy

NAME       NAMESPACE  REVISION UPDATED                              STATUS   CHART            APP VERSION
grafana    monitoring 2        2019-11-28 12:30:06.182869 +0000 UTC deployed grafana-4.0.4    6.4.2
prometheus monitoring 6        2019-11-28 12:30:06.55709 +0000 UTC  deployed prometheus-9.0.0 2.11.1

Try it yourself

There are a few conflicting guides and issues floating around between Helmfile, Helm-diff and Helm. Let’s cut through that and get something simple that works.

The install commands are for OSX but Linux users can probably grab via yum,snap,apt, rpm or whatever you are using

Assumptions:

• You have minikube running locally with virtualbox/hyperkit
• You have kubectl installed

1. Install helm brew install helm
2. Install Helmfile brew install helmfile
3. Install helm-diff

helm plugin install https://github.com/databus23/helm-diff

4. Make a basic Helmfile

cat >> helmfile.yaml << EOF
repositories:
- name: stable
  url: https://kubernetes-charts.storage.googleapis.com
  
releases:
- name: prometheus
  namespace: monitoring
  chart: helm-virtual/prometheus
  version: 9.0.0
  
helmDefaults:
  verify: true
  wait: true
  timeout: 600
  force: true
EOF

5. Run the sync to deploy the release

helmfile sync
Adding repo stable https://kubernetes-charts.storage.googleapis.com
"stable" has been added to your repositories
Updating repo
Hang tight while we grab the latest from your chart repositories...

🎉

NAME       NAMESPACE  REVISION UPDATED                            STATUS   CHART            APP VERSION
prometheus monitoring 6        2019-11-28 12:30:06.55709 +0000 UTC  deployed prometheus-9.0.0 2.11.1

Conclusion

This article has barely scratched the surface in terms of what you can do with Helmfile, there is layering, environment composing, conditionals and a whole bunch of other features.

I think whilst it’s young, it’s still a really promising tool for another layer of abstraction from Helm and focuses on composing Charts into a set of releases to build an ecosystem within your cluster.