Quickstart
If you encounter any problems during the quickstart make sure to use the flags. They help to understand what’s going on and what might be the problem.
https://github.com/buttahtoast/helmize/tree/main/examples/reference
First we create a new helm chart which is going to contain the entire deployment structure for helmize. We can simply do that with the following comment (In this case I will call the new chart reference, chose the name you would like):
helm create reference && cd reference/
We can clear the templates/* content and the ǜalues.yaml, since we are going to recreate them.
rm -rf templates/* && rm -f values.yaml && cd reference/
Now we add helmize as new chart dependency (Check out the release page or artifacthub to get the latest helmize version):
cat << EOF >> ./Chart.yaml
dependencies:
- name: helmize
# Make sure to use a fixed version
version: ">=0.0.0-0"
repository: "https://helmize.dev/"
EOF
Update dependencies to download the specified version for helmize:
helm dependency update
Now we need to add a template which includes the entrypoint for helmize:
cat << EOF > ./templates/deploy.yaml
{{- include "helmize.deploy" $ | nindent 0 }}
EOF
Now we create a very simplistic configuration in the chart root. This configuration reads all files which are located in structure/base/
cat << EOF > ./helmize.yaml
inventory_directory: "structure/"
conditions:
- name: "base"
path: "/base/"
any: true
EOF
With this initial configuration we have added a base directory which will lookup all files within (it’s not reuired to have a base condition).
Now we start creating our structure for the chart. We want to deploy podinfo (just the deployment) in the referenced base:
mkdir -p structure/base/podinfo
Under the structure we create some files so we can see the influence of helmize
After you have added those files and execute a template command:
helm template .
The result should not be surprising, for now the two new added files are just rendererd with additional comments.
For the quickstart we are going to add two conditions on top of the base condition called environment and location
Now we want to add a condition, that podinfo is different names on different environments. The environment can be controlled via the values of the chart. The Value which is considered is defined under key which points to $.Values.env. If no value is given the default of test is applied. With the filter we define, that only test and prod are accepted as value. Files for this condition are located under structure/env/{value}:
cat << EOF > ./helmize.yaml
inventory_directory: "structure/"
conditions:
- name: "base"
path: "/base/"
any: true
- name: "environment"
key: "env"
path: "env/"
default: "test"
filter: [ "test", "prod" ]
reverse_filter: true
EOF
Now we add two new structures for the environment testand prod
As you can see the output changes based on the input of the chart.
Let’s add a condition for the location. The location should also be controllable via Values of the chart.
cat << EOF > ./helmize.yaml
inventory_directory: "structure/"
conditions:
- name: "base"
path: "/base/"
any: true
- name: "environment"
key: "env"
path: "env/"
default: "test"
filter: [ "test", "prod" ]
reverse_filter: true
- name: "location"
key: "location"
default: "east"
EOF
Now we add two new structures for the location east and west
As seen with these two examples, conditions are a great mechanism to combine different indepdendent factors. You can extended the conditions at anytime without restructering the entire folder structure.
Throughout the entire rendering process you can access the different data contexts and add logic to the given values. Now we add a new condition, which evaluates the required data, to atuomaticaly adjust the ingress based on previous cdonditions.
cat << EOF > ./helmize.yaml
inventory_directory: "structure/"
conditions:
- name: "base"
path: "/base/"
any: true
- name: "environment"
key: "env"
path: "env/"
default: "test"
filter: [ "test", "prod" ]
reverse_filter: true
- name: "location"
key: "location"
default: "east"
- name: "expose"
any: true
data:
ingress_class: "company-domain"
tpls:
- tpls/ingress.tpl
EOF
This condition implements a data template which evaluates data. This template can use sprig. and you can add as many as you want, just make sure they return valid yaml. In addition we declare static data. Now let’s create the template:
mkdir -p tpls/
This template evaluates the field ingress_name based on the previous values from conditions. This is a very simple example, you can increase the complexity by as much as you are comfortable with :).
cat << EOF > ./helmize.yaml
{{/* Default Variables */}}
{{- $env := "" -}}
{{- $location := "" -}}
{{/* Iterate over previous Conditions */}}
{{- range $c := $.conditions -}}
{{/* Evaluate Environment */}}
{{- if (eq $c.name "environment") -}}
{{- $env = default "" $c.value -}}
{{/* Evaluate Location */}}
{{- else if (eq $c.name "location") -}}
{{- $location = default "" $c.value -}}
{{- end -}}
{{- end -}}
{{/* Return Data */}}
ingress_name: frontend.{{ $env }}.{{ $location }}.company.com
EOF
Now lets create the file which will implement this data.
mkdir -p structure/expose/
This template accesses the data. Since it’s coming from the condition, which sources the ingress, it can directly access the data via $.data. You could also do the same evaluation within this template, since you can access $.conditions in this context as well. This decision really comes down to how reusable the data must be and how many files implement it.
cat << EOF > ./structure/expose/ingress.tpl
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: frontend
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
{{- with $.data.ingress_class }}
ingressClassName: {{ . }}
{{- end }}
tls:
- hosts:
- {{ $.data.ingress_name }}
secretName: frontend-tls
rules:
- http:
paths:
- host: {{ $.data.ingress_name }}
path: /
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
EOF
Templating this, will result in a different ingress based on previous conditions, truly value driven. These were some very simple examples on how Helmize works.
Helmize has a lot to offer, are you ready to explore it’s possabilities?