138 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
			
		
		
	
	
			138 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Markdown
		
	
	
	
## Advanced Features
 | 
						|
 | 
						|
- [Import Configuration Parameters into Helmfile](#import-configuration-parameters-into-helmfile)
 | 
						|
 | 
						|
### Import Configuration Parameters into Helmfile
 | 
						|
 | 
						|
Helmfile integrates [vals]() to import configuration parameters from following backends:
 | 
						|
 | 
						|
- AWS SSM Parameter Store
 | 
						|
- AWS SecretsManager
 | 
						|
- Vault
 | 
						|
- SOPS
 | 
						|
 | 
						|
See [Vals "Suported Backends"](https://github.com/variantdev/vals#suported-backends) for the full list of available backends.
 | 
						|
 | 
						|
This feature was implemented in https://github.com/roboll/helmfile/pull/906.
 | 
						|
If you're curious how it's designed and how it works, please consult the pull request.
 | 
						|
 | 
						|
### Deploy Kustomizations with Helmfile
 | 
						|
 | 
						|
You can deploy [kustomize](https://github.com/kubernetes-sigs/kustomize) "kustomization"s with Helmfile.
 | 
						|
 | 
						|
Most of Kustomize operations that is usually done with `kustomize edit` can be done declaratively via Helm values.yaml files.
 | 
						|
 | 
						|
Under the hood, Helmfile transforms the kustomization into a local chart in a temporary directory so that it can be `helm upgrade --install`ed.
 | 
						|
 | 
						|
The transformation is done by generating (1)a temporary kustomization from various options and (2)temporary chart from the temporary kustomization.
 | 
						|
 | 
						|
An example pseudo code for the transformation logic can be written as:
 | 
						|
 | 
						|
```console
 | 
						|
$ TMPCHART=/tmp/sometmpdir
 | 
						|
$ mkdir -p ${TMPCHART}/templates
 | 
						|
$ somehow_generate_chart_yaml ${TMPCHART}/Chart.yaml
 | 
						|
 | 
						|
$ TMPKUSTOMIZATION=/tmp/sometmpdir2
 | 
						|
$ somehow_generate_temp_kustomization_yaml ${TMPKUSTOMIZATION}/kustomization.yaml
 | 
						|
$ kustomize build ${TMPKUSTOMIZATION}/kustomization.yaml > ${TMPCHART}/templates/all.yaml 
 | 
						|
```
 | 
						|
 | 
						|
Let's say you have a `helmfile.yaml` that looks like the below:
 | 
						|
 | 
						|
```yaml
 | 
						|
releases:
 | 
						|
- name: myapp
 | 
						|
  chart: mykustomization
 | 
						|
  values:
 | 
						|
  - values.yaml
 | 
						|
```
 | 
						|
 | 
						|
Helmfile firstly generates a temporary `kustomization.yaml` that looks like:
 | 
						|
 | 
						|
```yaml
 | 
						|
bases:
 | 
						|
- $(ABS_PATH_TO_HELMFILE_YAML}/mykustomization
 | 
						|
```
 | 
						|
 | 
						|
Followed by the below steps:
 | 
						|
 | 
						|
- Running `kustomize edit set image $IMAGE` for every `$IMAGE` generated from your values.yaml 
 | 
						|
- Running `kustomize edit set nameprefix $NAMEPREFIX` with the nameprefix specified in your values.yaml
 | 
						|
- Running `kustomize edit set namesuffix $NAMESUFFIX` with the namesuffix specified in your values.yaml
 | 
						|
- Running `kustomize edit set namespace $NS` with the namespace specified in your values.yaml
 | 
						|
 | 
						|
A `values.yaml` file for kustomization would look like the below:
 | 
						|
 | 
						|
```yaml
 | 
						|
images:
 | 
						|
# kustomize edit set image mysql=eu.gcr.io/my-project/mysql@canary
 | 
						|
- name: mysql
 | 
						|
  newName: eu.gcr.io/my-project/mysql
 | 
						|
  newTag: canary
 | 
						|
# kustomize edit set image myapp=my-registry/my-app@sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
 | 
						|
- name: myapp
 | 
						|
  digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
 | 
						|
  newName: my-registry/my-app
 | 
						|
 | 
						|
# kustomize edit set nameprefix foo-
 | 
						|
namePrefix: foo-
 | 
						|
 | 
						|
# kustomize edit set namesuffix -bar
 | 
						|
nameSuffix: -bar
 | 
						|
 | 
						|
# kustomize edit set namespace myapp
 | 
						|
namespace: myapp
 | 
						|
```
 | 
						|
 | 
						|
At this point, Helmfile can generate a complete kustomization from the base kustomization you specified in `releases[].chart` of your helmfile.yaml and `values.yaml`,
 | 
						|
which can be included in the temporary chart.
 | 
						|
 | 
						|
After all, Helmfile just installs the temporary chart like standard charts, which allows you to manage everything with Helmfile regardless of each app is declared using a Helm chart or a kustomization.
 | 
						|
 | 
						|
Please also see [test/advanced/helmfile.yaml](https://github.com/roboll/helmfile/tree/master/test/advanced/helmfile.yaml) for an example of kustomization support and more.
 | 
						|
 | 
						|
## Adhoc Customization of Helm charts
 | 
						|
 | 
						|
You can add/update any Kubernetes resource field rendered from a Helm chart by specifying `releases[].strategicMergePatches`:
 | 
						|
 | 
						|
```
 | 
						|
repositories:
 | 
						|
- name: incubator
 | 
						|
  url: https://kubernetes-charts-incubator.storage.googleapis.com
 | 
						|
 | 
						|
releases:
 | 
						|
- name: raw1
 | 
						|
  chart: incubator/raw
 | 
						|
  values:
 | 
						|
  - resources:
 | 
						|
    - apiVersion: v1
 | 
						|
      kind: ConfigMap
 | 
						|
      metadata:
 | 
						|
        name: raw1
 | 
						|
        namespace: default
 | 
						|
      data:
 | 
						|
        foo: FOO
 | 
						|
  strategicMergePatches:
 | 
						|
    - apiVersion: v1
 | 
						|
      kind: ConfigMap
 | 
						|
      metadata:
 | 
						|
        name: raw1
 | 
						|
        namespace: default
 | 
						|
      data:
 | 
						|
        bar: BAR
 | 
						|
```
 | 
						|
 | 
						|
Running `helmfile template` on the above example results in a ConfigMap called `raw` whose `data` is:
 | 
						|
 | 
						|
```yaml
 | 
						|
foo: FOO
 | 
						|
bar: BAR
 | 
						|
```
 | 
						|
 | 
						|
Please note that the second `data` field `bar` is coming from the strategic-merge patch defined in the above helmfile.yaml.
 | 
						|
 | 
						|
There's also `releases[].jsonPatches` that works similarly to `strategicMergePatches` but has additional capability to remove fields.
 | 
						|
 | 
						|
Please also see [test/advanced/helmfile.yaml](https://github.com/roboll/helmfile/tree/master/test/advanced/helmfile.yaml) for an example of patching support and more.
 |