#helmfile - March 2020

I’ve just noticed a little issue with paths. When I run helmfile command against some custom path and this helmfile file contains “helmfiles:” I have to make the helmfiles’ values path relative to cli, i.e.

I run helmfile -f environments/dev/helmfile.yaml

inside this helmfile there is helmfiles: block:

helmfiles:
  - path: git::<https://my_user>:{{ requiredEnv "REPO_TOKEN" }}@my_domaincom/my_repo.git@deployment/helmfile.yaml?ref={{ env  "INFRA_VERSION" }}
    values:
      - ../../values.yaml

The folder structure is the following

├── environments
│   └── dev
│       ├── helmfile.yaml
│       ├── values.yaml

Is this an expected behaviour? Docs say the path in the manifest should be relative to this manifest.

The other thing. It seems terraform-helmfile-provider doesn’t respect a custom path for helmfile.yaml

Say, a config

resource "helmfile_release_set" "common_stack" {
  path = "custom_helmfile.yaml"

  working_directory = path.module
...

ends up with

specified state file helmfile.yaml is not found

but it works for the name hamefile.yaml

Ok, it seems one cannot just change the path or name for helmfile, as tf wants to make a diff using the old file as well:). So, at this time one need to have 2 helmfile files presented in the filesystem. Not that obvious at first)

Hello 🙂

This will be my first post here, so please forgive me if the answer to the question is too obvious.
Actually I create a dead-simple helmfile structure, here you can see the project tree:

.
├── chart
│   └── example
│       ├── charts
│       ├── Chart.yaml
│       └── templates
│           ├── deployment.yaml
│           ├── _helpers.tpl
│           ├── ingress.yaml
│           ├── NOTES.txt
│           ├── serviceaccount.yaml
│           ├── service.yaml
│           └── tests
│               └── test-connection.yaml
├── helmfile.d
│   └── 00-base.yaml
├── repositories.yaml
├── secrets
│   └── example
│       ├── dev
│       │   └── secret.yaml
│       └── qa
│           └── secret.yaml
└── values
    └── example
        ├── dev.yaml
        └── qa.yaml

 

At the 00-base.yaml helmfile I can use the {{ requiredEnv "PLATFORM_ENV" }} environment variable.
On the other hand, my value files would contain some env vars too e.g.

image: 
  tag: ${MAJOR_NUMBER}.${MINOR_NUMBER}.${PATCH_NUMBER}
 

As I experienced, the requiredEnv go template solution does not work this way.

Do you have any hint on how to solve this problem?
Am I on the right track with this logic at all?

@Norbert Fenk - You can use go templates in your values files, but they need to have a gotmpl extension. https://github.com/roboll/helmfile#templates

For example: if you rename values/example/dev.yaml to values/example/dev.yaml.gotmpl you'd be able to use {{ requiredEnv "PLATFORM_ENV" }} in that template as well.

Ohhh nice! 🙂 Thank you, I will give it a try 🙂

Is there a way to add logic in a helmfile configuration to detect helm v2.x?

We have a large helmfile repo, a folder for each kube namespace. I want to cut-over one of those namespaces/folders to helm3 but add protection for someone running helmfile against helm 2.x

Hello,
are environments taken into accoutn when calling helmfile template ?
It seem as no, and docs are only telling about helmfile sync

I hope I have understood correctly, but environments are taken into account when using template, you just have to add the flag. helmfile -e environment_one -l name=testservice template and helmfile -e second_env -l name=testservice template should yield different results assuming the values you have set in the different environments value files are different.

I’m missing something crucial i think. I’m trying to tune my nginx-ingress and https://docs.cloudposse.com/kubernetes-optimization/tune-nginx/ looked really interesting. But what i do not get is how with this helm file https://github.com/cloudposse/helmfiles/blob/master/releases/nginx-ingress.yaml some sort of compiled version of https://github.com/cloudposse/helmfiles/blob/master/releases/values/ingress.nginx.template ends up in the config map for stable/nginx-ingress.

hello all

I have a question.

what type of env can I use in values.yaml.gotmpl ?

can I use .Release.name? or maybe data from other chart? E.G. If I have an ES server and would like to connect to that server from fluentd and kibana? Should I move the creds to global env or can I set it in es's chart values file and call from the other values file ?

Does anyone know if you can specify dependency relations in Helmfile? We have a chart that requires another chart to be installed first.

To create a CRD

Create namespace functionality coming back to helm: https://github.com/helm/helm/pull/7648

Has anyone been able to successfully use a pipe passing input to stdin when using helmfile exec function? I'm trying to debug the code and I'm not entirely sure how it works with regards to putting inputs to stdin

Hello Everyone, do we need to migrate helm(2-3) in every helm client machine ?

It is as part of the helm2 to helm3 migration

no, you can just keep using helm 2 🙂

The serious answer is yeah, on each deployed cluster with helm2 charts, you probably should upgrade to helm 3. Or better yet, just blow them away and start from scratch so you can practice treating them as cattle instead of pets.

Hi @Zachary Loeber

Yeah.. I can continue to use helm2. However in future I should be upgrade to 3.
I am thinking to migrate the helm charts in 1 client machine and in remaining Client machines just remove the helm2 binary and place helm3 binary.. will that help?

Are you running tillerless? Either way, yeah completely removing the helm2 deployments in the other machines and switching to helm 3 after the deployments have been updated is smart. I ran into issues with plugins that would not respect the local PATH variable (for instance) when attempting to use both versions.

going one or the other is going to be easier

Thankyou @Zachary Loeber

@here
while installing the helm chart for grfana from stable/grafana, the container is keep restarting.
The only changes i made in values file is
1. changing the service type from ClusterIP to NodePort(32323)
2. setting the password for admin
3. making the persistent as true
I have installed Promethues in first place and it is working fine..

Did anyone has faced similar kind of issue?
i could not find much logs either from k8s or docker for troubleshooting

root@master:~/grafana# k logs grafana-df5bc8c76-2zgt5 -n grafana
Error from server (BadRequest): container "grafana" in pod "grafana-df5bc8c76-2zgt5" is waiting to start: ContainerCreating

I suspect it could be an issue with resources... It's started working..

hello. I've been trying for a while now to import a defined template into another file but I can't find a way of doing this. I've submitted this issue https://github.com/roboll/helmfile/issues/1146. Did anyone tried to do this or how can this be done? My template file for the values.yaml has reached more than 1000 lines and a vast majority of those are {{ define "test" }} templates. I want to extract those from this file and move those into separate files and import them as needed. Thank you

I've read most of the docs but I don't see any clear reference or some examples of doing this

I found this from the godoc but couldn't find a way to do this

By construction, a template may reside in only one association. If it's necessary to have a template addressable from multiple associations, the template definition must be parsed multiple times to create distinct *Template values, or must be copied with the Clone or AddParseTree method.

Parse may be called multiple times to assemble the various associated templates; see the ParseFiles and ParseGlob functions and methods for simple ways to parse related templates stored in files.

is it crazy for me to look for a solution where:

helmfile apply

triggers a blue/green deployment (instead of rolling deployment) (no istio)?

Disregard. Taking a different approach

We are doing blue green with Helmfile

If you are interested @Igor Rodionov can share details

Please share details @Igor Rodionov on how you are doing blue/green deployments

Whoa, no way?

nice

anyone can help me with the above problem?

Is it possible to make a value immutable somehow? Say it’s set once(initially) and it should be ignored during subsequent runs or it returns an error if it’s changed? Have a use case right now, but haven’t checked out the possibilities yet.

I want to do something like this, but it doesn't seem to work, does anyone have a working example?

bar: {{ exec "sh" (list "-c" requiredEnv "FOOL" ) }}

file name is values.yaml.gotmpl

My solution so far:

bar: {{ exec "sh" (list "-c" (printf "echo %s" (requiredEnv "FOOL")) ) }}

but maybe there is a neater way

hello any news with this issue? https://github.com/roboll/helmfile/issues/1146

Adding @U010XGY9B46 bot

Hello everyone

I just discovered helmfile while working for quite a bit of time on a python script that essentially does what helmfilme was designed to do. I'm looking to investigate and switch to it soon, look really cool 🙂

I’ve started noticing that installed: false is not working for us anymore. Don’t know since when. Haven’t used it extensively. It could be an issue with tf helmfile provider though. Also we are using pretty old version of helmfile right know, can’t keep pace with the frequency of helmfile releases). I’ll try to investigate.

Ok, I got it. Since helmfile diff cannot handle this, tf doesn’t see the difference and does nothing. tf plan shows No changes. Infrastructure is up-to-date.

If I would want to "bootstrap" certain releases all at once on different clusters (cert-manager, nginx-ingress etc). How would one "loop" through all of the clusters in a helmfilme and apply certain subcharts such as the ones I mentioned to each cluster?

labels are very useful for this. you could make a label that's something like infra: true and then run helmfile with infra=true as a selector

so each chart you want to install as your infrastructure package, you'd label with infra: true

(the label name is arbitrary, as is the value, this is just how i do it)

@James Huffman that sounds swell, how is this applied across all clusters though?

So if I have 10 clusters and a release in each and in 8 I want to deploy nginx-ingress and cert-manager

how do you currently determine what goes into each cluster? or do you not have a mechanism so far?

@James Huffman so far I have just the app I deploy and include it in the release list of the helmfile

Maybe an include/function call where I pass the subcharts and the kubecontext ?

you could do that. that's how we feed helm chart versions into our setup. we pull in a file whose path is determined by environment variables