Introduces DAG-aware installation/deletion ordering to Helmfile.
`needs` controls the order of the installation/deletion of the release:
```yaml
relesaes:
- name: somerelease
needs:
- [TILLER_NAMESPACE/][NAMESPACE/]anotherelease
```
All the releases listed under `needs` are installed before(or deleted after) the release itself.
For the following example, `helmfile [sync|apply]` installs releases in this order:
1. logging
2. servicemesh
3. myapp1 and myapp2
```yaml
- name: myapp1
chart: charts/myapp
needs:
- servicemesh
- logging
- name: myapp2
chart: charts/myapp
needs:
- servicemesh
- logging
- name: servicemesh
chart: charts/istio
needs:
- logging
- name: logging
chart: charts/fluentd
```
Note that all the releases in a same group is installed concurrently. That is, myapp1 and myapp2 are installed concurrently.
On `helmdile [delete|destroy]`, deleations happen in the reverse order.
That is, `myapp1` and `myapp2` are deleted first, then `servicemesh`, and finally `logging`.
Resolves#715
This adds clarity in docs by:
- Changing references to the supported file extension
- Previously, using `values.tmpl` in helmfile.yaml would throw errors. `values.gotmpl` gives expected output
Resolves#689
This adds a new yaml entry for the hook definition to allow the users to specifcy if they want to show the `command` logs or not.
here is an example.
```
releases:
- name: myapp
chart: mychart
# *snip*
hooks:
- events: ["cleanup"]
showlogs: true
command: "kubectl"
args: ["get", "ingress"]
```
this will display the following output:
```
hook[cleanup] logs | NAME HOSTS ADDRESS PORTS AGE
hook[cleanup] logs | catalog-gateway tdc.foo 80 2d6h
hook[cleanup] logs | dataset foobar.barr.foo.xxxxxxx.com 80 2d6h
hook[cleanup] logs | rating fooba.barr.foo.xxxxxxx.com 80 2d6h
hook[cleanup] logs | sharing foobar.barr.foo.xxxxxxx.com 80 2d6h
hook[cleanup] logs | tpsvc-iam-dev foo.barr.foo.xxxxxxx.com 80 2d6h
hook[cleanup] logs | tpsvc-iam-front bar.barr.foo.xxxxxxx.com 80 2d6h
```
The root cause of this bug was due to that `--kube-context` and `kubeContext` had been treated specifically in code. So on the way I have made it consistent with other per-release settings - by adding `kubeContext` for each release and treating `helmDefaults.kubeContext` as just the default value for per-release setting.
Fixes#674
This enhances helmfile so that it can:
- Treat K8s manifests directories and Kustomize projects as charts
- Add adhoc chart dependencies on sync/diff/template without forking or modifying chart(s) (#649)
- Add adhoc patches(JSON Patch or Strategic Merge Patch supported) to be applied to the K8s resources before sync/diff/template, without forking or modifyin chart(s) (#650)
The usage is as outlined in https://github.com/mumoshu/helm-x/tree/master/examples/helmfile.
Add any or all of `dependencies:`, `jsonPatches:` and `strategicMergePatches:` so that it adds additional flags to `helm` calls that is only supported by `helm x`.
```yaml
releases:
- name: kustomize
chart: ../kustomize
- name: manifests
chart: ../manifests
- name: foo
chart: incubator/raw
dependencies:
- alias: bar
chart: incubator/raw
values:
- values.yaml
- bar:
enabled: true
resources:
- apiVersion: v1
kind: Pod
metadata:
name: bar
spec:
containers:
- command:
- sleep
- 1000
image: alpine:3.9.4
imagePullPolicy: IfNotPresent
name: bar
jsonPatches:
- target:
version: v1
kind: Pod
name: foo
patch:
- op: replace
path: /spec/containers/0/command
value:
- sleep
- "123"
strategicMergePatches:
- apiVersion: v1
kind: Pod
metadata:
name: bar
spec:
containers:
- name: bar
command:
- sleep
- "234"
```
You can alternatively provide `source: path/to/patch.yaml` for `jsonPatches` and `strategicMergePatches` items to externalize it. Add `.gotmpl` suffix like you would do for values files for templating.
When running `helmfile` you must point `--helm-binary` to the `helm-x` binary like below:
```
$ helmfile --helm-binary ~/.helm/plugins/helm-x/bin/helm-x --log-level debug apply
```
after installing the [helm-x](https://github.com/mumoshu/helm-x) plugin.
The integration should ideally be automatic. That is, it shouldn't force you to set `--helm-binary`. But I had no other way to not bloat helmfile's codebase to just add this experimental feature.
Resolves#649Resolves#650
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles.
```yaml
helmfiles:
- # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file
# The nested-state file is locally checked-out along with the remote directory containing it.
# Therefore all the local paths in the file are resolved relative to the file
path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0
```
The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works.
Under the hood, it uses [hashicorp/go-getter](https://github.com/hashicorp/go-getter), that is used for [terraform module sources](https://www.terraform.io/docs/modules/sources.html) as well.
Only the git provider without authentication like git-credentials helper is tested. But theoretically any go-getter providers should work. Please feel free to test the provider of your choice and contribute documentation or instruction to use it :)
Resolves#347
The addition of `--set k1=v1,k2=v2` and `--values file1 --values file2` was originally planned in #361.
But it turned out we already had `--values` for existing helmfile commands like `sync`. Duplicated flags doesn't work, obviously.
So this actually add `--state-values-set k1=v1,k2=v2` and `--set-values-file file1 --set-values-file file2`.
They are called "state" values according to the discussion we had at #640Resolves#361
We added envvals overrides in the state file via #622 two days ago:
```
helmfiles:
- name: sub.helmfile.yaml
environment:
values:
- mykey: myvalue
```
This change removes the `environment` level in the above cofig, so that it looks like:
```
helmfiles:
- name: sub.helmfile.yaml
values:
- mykey: myvalue
``
This is an inevitable breaking change towards #361. But I wanted to break it earlier so that less folks are affected.`
Ref https://github.com/roboll/helmfile/issues/361#issuecomment-497530819
* feat: specify env values from the parent to the nested state
Adds the `helmfiles[].environment.values` that accepts a mix of file pathes and inline dictes:
```yaml
helmfiles:
- path: path/to/nested/helmfile.yaml
environment:
values:
- key1: val1
- values.yaml
```
The values files are loaded in the context of the parent state file. For example, in case the above state file is located at `/path/to/helmfile.yaml`,
`values.yaml` is located at `/path/to/values.yaml` instead of `/path/to/nested/values.yaml`.
Resolves#523
* fix: multiple "bases" declarations yields duplicate releases
Fixes#615
* fix regression in double-rendering with env value overrides
The latest commit broke any state files like the below to NOT pass env value overrides at all:
```
helmfiles:
- path: nested/state.yaml
environment:
values:
- overrides.yaml
```
This fixes the issue.
```yaml
environments:
default:
missingFileHandler: Warn
values:
- path/to/values.yaml
secrets:
- path/to/secrets.yaml
```
`missingFileHandler` set to `Warn`, `Info`, or `Debug` results in helmfile NOT stop when `path/to/values.yaml` or `path/to/secrets.yaml` is missing.
Resolves#548
While implementing the above feature, I also found a bug that has been causing #559. This also fixes that.
To verify it is actually fixed, create an example helmfile.yaml that looks like the below, and run `helmfile diff`:
```
$ cat helmfile.yaml
environments:
default:
secrets:
- env-secrets.yaml
releases:
- name: myapp
chart: nginx
namespace: default
secrets: [secrets.yaml] # Notice this file does not exist
values:
- ingress:
enabled: true
$ helmfile diff
could not deduce `environment:` block, configuring only .Environment.Name. error: failed to read helmfile.yaml.part.0: environment values file matching "env-secrets.yaml" does not exist
in ./helmfile.yaml: failed to read helmfile.yaml: environment values file matching "env-secrets.yaml" does not exist
```
Fixes#559
`postsync` events are triggered after each release is applied to the cluster in `helmfile sync` or `helmfile apply`.
This should be a best hook to notify only after each sync failed or succeeded. This can be used for running operations like patching K8s resources managed by helm, but that should be the last-resort. Maybe you should fork/update the chart, or submit a feature request to add `replicated/ship` integration to `helmfile` in that case :)
Resolves#599
In order to maintain predictable deployments, as developer I want to generate and use "lock files" for all chart versions retrieved from a helmfile.
This change solves it by (1)enhancing `helmfile deps` to generate a lock file containing all the direct chart dependencies of each helmfile state file and
(2)making other helmfile sub-commands reads the lock file and merge the locked version numbers to the helmfile state file being processed.
The lock file is named after the helmfile state file being locked, so that you can have multiple set of the helmfile state file and the lock file pairs in a directory.
When `helmfile deps` are not explicitly run before commands like `sync`, all the helmfile behavior should remain as before.
Let's say you have `helmfile.1.yaml`:
```
repositories:
- name: stable
url: https://kubernetes-charts.storage.googleapis.com
releases:
- name: envoy
chart: stable/envoy
- name: envoy2
chart: stable/envoy
```
`helmfile deps` generates `helmfile.1.lock` that looks like:
```
dependencies:
- name: envoy
repository: https://kubernetes-charts.storage.googleapis.com
version: 1.5.0
digest: sha256:e43b05c8528ea8ef1560f4980a519719ad2a634658abde0a98daefdb83a104e9
generated: 2019-05-14T16:45:37.78205+09:00
```
Under the hood, `helmfile deps` creates a temporary local helm chart with a dummy `Chart.yaml` and `requirements.yaml` deduced from the `helmfile.yaml` content, then runs `helm dependency update` to produce od update the corresponding `requirements.lock` file.
`helmfile` then renames it to match the name of the targeted helmfile state file and moves it, so that it becomes adjacent to each `helmfile.yaml`.
Other `helmfile` commands like `sync`, `diiff`, `apply`, `lint` read chart version numbers from the lock file.
Resolves#483
Fixes#344 by allowing explicit selectors to be specified for composed helmfiles using the following structure
```yaml
helmfiles:
- path: helmfile.d/a*.yaml
selectors:
- name=prometheus
- name!=zipkin
- helmfile.d/b*.yaml
- path: helmfile.d/c*.yaml
selectors: {}
```
2 modes here :
* legacy mode when no the env var HELMFILE_EXPERIMENTAL is not set to true
* no selector : inherit from the command line.
* selector: is specified then it is used (an emty means no inheritance from command line and take everything).
* experimental when the env var HELMFILE_EXPERIMENTAL=true
* no selector : nothing is inherited from the command line so use all releases.
* selector: is specified then it is used (an emty means no inheritance from command line and take everything).
* feat: `helmfile destroy` deletes and purges releases
This adds `helmfile destroy` that is basically `helmfile delete --purge`.
I've also tweaked the behavior of `delete` and `destroy` for releases with `installed: false`, so that it becomes consistent with other helmfile commands.
It now delete releases only when `installed: true` AND the release is already installed.
**Why an another command?**
Because it's easy to remember, and it also makes it easier to iterate on your helmfile.
We've been using `helmfile delete` from the beginning of helmfile,
and several months have been passed since we've added `--purge` to it.
We noticed that we always prefer to use `--purge` so that we can quickly iterate on helmfile by
e.g. `helmfile delete --purge && helmfile sync`. But making `--purge` default makes the `delete` command inconsistent with the helm's `delete`.
`destroy`, on the other hand, doesn't have such problem, and is still easy to remember for terraform users.
Resolves#511
* Update docs about `helmfile delete` and `helmfile destroy`
This basically allows to define both `releases` and `helmfiles` within a helmfile.yaml, so that you can start using sub-helmfiles easily, by extracting only reused releases.
Resolves#445
This feature is supposed to help advanced use-cases like Conventional Directory Structure explained in several issues like #428.
Newly added configuration keys `templates`, `missingFileHandler`, and the ability to defer executing template expressions in `values`, `secrets`, `namespace`, and `chart` of releases allows you to abstract away repetitions into a reusable template:
```yaml
templates:
default: &default
missingFileHandler: Warn
namespace: "{{`{{ .Release.Name }}`}}"
chart: stable/{{`{{ .Release.Name }}`}}
values:
- config/{{`{{ .Release.Name }}`}}/values.yaml
- config/{{`{{ .Release.Name }}`}}/{{`{{ .Environment.Name }}`}}.yaml
secrets:
- config/{{`{{ .Release.Name }}`}}/secrets.yaml
- config/{{`{{ .Release.Name }}`}}/{{`{{ .Environment.Name }}`}}-secrets.yaml
releases:
- name: envoy
<<: *default
```
See the updated documentation for more details.
Resolves#428
KUOKA Yusuke
Martin Devlin
Rajat Goyal
art kon
Theo Meneau
eddycharly
Max Williams
sgandon
刘相轩
jonathan cowling msm
Raj Perera
prakharrr-sl
Aaron Gershman
Facundo Guerrero
Patrick Valsecchi
Erik Osterman
Mike Eves
Shane Starcher
Maxim Mironenko
Raphael Sampaio
Anatoly Rugalev
Sam Weston
Martin Mauch