#helmfile (2020-11)

it’s too much of helm, and too few of helmfile, imho

Here’s what I use in my slides…

But it’s a file, like file folder, hence helm*file*.

This one? https://artifacthub.io/packages/olm/community-operators/spark-gcp

its this one: https://github.com/helm/charts/tree/master/incubator/sparkoperator

I wonder if the one I linked will have the problem too. The Incubator repo usually isn’t the best when you are trying to find something reliable

Will take a look on the one spark-gcp (although we are not running in gcp and use Spark 3)

Its actually the same: The opertaor code is at https://github.com/GoogleCloudPlatform/spark-on-k8s-operator

I’m not seeing anything that locks it to GCP

but idk, haven’t looked that hard

Forget what I wrote last - the charts may of course be diff.

Ah - the operator hub link is just for the operator and doesn’t appear to include a Chart

Found a workaround - I will simply add a label “skiplint: true” and run helmfile -l 'skiplint!=true' lint

Also, note…

Thanks for the heads up - I’m running helm 3.4.0 so I have already swapped stable and incubator to charts.helm.sh since it kept nagging me about it

though if you’re using a chart based on <https://github.com/helm/charts/tree/master/incubator/sparkoperator> (as above), the entire <https://github.com/helm/charts/> repo will be archived, and incapable of receiving updates.

can’t you just generate uuid outside of deployment and just provide generated UUID to deployment to use it ?

we are doing that for most of them that we need, but it doesn’t work for all cases as the first chart doesn’t expose the ability to set all of them

in another case, sometimes its more than just uuid’s, some charts generate secrets during first install, and it would be nice to pull those in for subsequent charts

well, you may wrap anything in exec | get

but it may be tricky to wait for external value generation

hmm solved it with leaving the tillerNamespace empty

tillerNamespace: ""

I don’t have an example project right now but it shouldn’t be hard with flagger.

You will deploy flagger and your apps with helmfile. Flagger is configured to monitor your apps as “canary” k8s deployments, so that Flagger watches and mirrors your deployment, balances traffic between the older “stable” k8s deployments, and carries blue/green deployment.

@mumoshu - do you have a link to flagger? I’m not familiar with it, but it sounds wonderful.

here you are! https://flagger.app/

https://github.com/cloudposse/helmfiles/tree/master/releases

it’s better to keep helmfile updated all around, as long as you’re not blocked by some bug etc

it’s just a tool, no need to pin version w/o reason.

mumoshu bakes new features and fixes bugs really fast

these are now moved.

environments in helmfile are completely diff concept (not related to terraform and the environment variable in the TF modules)

https://github.com/roboll/helmfile#configuration

in your helmfile.yaml you specify something like this

bases:
- ../environments.yaml

and then in the environments.yaml you do

environments:
  prod:
    values:
      - defaults.yaml
      - prod.yaml
  staging:
    values:
      - defaults.yaml
      - staging.yaml
  dev:
    values:
      - defaults.yaml
      - dev.yaml

where each YAML file is a collection of values for the helmfile for a particular environment

e.g. in dev.yaml you could have

installed: true

unlimited_staging_enabled: false

The problem is not the environments feature of helmfile but the dependency of the release to use specific variables like .Values.stage to specify the IAM role

I have an Idea and could push a MR as a proposal

Try using the fromYaml filter. Or take a look to the template feature in the helmfile docs, specially the github issues

To render a go template that contains expressions like {{ .Values... }}, try renaming the values file as values.yaml.gotmpl

otherwise it’s treated as a plain yaml without templates and may result in e.g. a yaml syntax error

ah i just realized that you found it yourself :)

Happens to me all the time! =)

yes sure, just run helm template -f values.yaml .

sweet

i think helmfile template

thanks! the first one seems like a bug. would you mind opening an issue?

- values passed to helmfile apply /helmfile sync via –set or –values arguments are ignored while applying the patch, only way is to pass those values via helmfile.yaml this can also be a bug(or regression?) i rarely try to add adhoc chart values via command-line(i only do that via —state-values-set/values) so perhaps i slipped it while testing

will open issue(s) for this thank you

You might want to check Makefile in the repo:) It helped me when I faced this. Can’t write the solution right now answering with the phone, sorry

Well, there’s a few issues

1. have no idea what to check in Makefile, since has zero experience with them
2. Makefile in master branch is expected to be working without any changes, especially when building inside a docker but thanx anyway, if you got a chance to give some clues later - I’d be appreciated

I can just confirm, I have the same errors on docker build for .helm3 Dockerfile

ah good catch. this is far from ideal but you need to run go mod vendor before running make image

https://github.com/roboll/helmfile/blob/988c218096f77393c8298d715a8a106f84ca01ca/.circleci/config.yml#L42

Oh, I’m a bit late for an answer)). Yeah mumoshu nailed it. I messed up files a bit, it was in circleci configuration indeed, couldn’t check yesterday. Sorry for the misleading info.

Yet again, i am building a docker image From a dockerfile from master branch

isnt it supposed that proposed go mod vendor must be put into dockerfile ?

i dont remeber the rationale/original reason anymore, but ideally there should be no go mod vendor in neither circleci config nor dockerfile

as go build is expected to download all the deps as in go.mod on demand

well, but currently either Dockerfile in master is broken or docker image should be built with some undocumented steps ,or finally, maybe i have some very special bug in my PC setup causing this issue

No special bug, I also can’t build Dockerfile.helm3 from master branch

yep. i think that’s bug in (perhaps) helmfile’s go.mod/go.sum

Should I open an issue ? Or you all could open / fix it ?

it would be great if you could open one!

works for me in presync hook args

Hmm, I’ll try it again. Maybe there was a typo.

Nope, I still get an empty string after using that: https://github.com/relaycorp/cloud-gateway/commit/3338800c5c6eb3214d7a5e544852483842fa2e7a

I’m sure that’s an empty string because the hook is printing the value it gets: https://github.com/relaycorp/cloud-gateway/blob/3338800c5c6eb3214d7a5e544852483842fa2e7a/charts/vault/pre-install.sh#L35-L38

Are you setting the namespace explicitly in the helmfile?

Maybe I need to do that

Are you setting the namespace explicitly in the helmfile? Yes. IDK other options for helmfile to guess the namespace.

I assumed it’d read the current context . I’ll set the namespace explicitly

nvm, i just found https://github.com/mumoshu/terraform-provider-helmfile/issues/5

@Erik Osterman (Cloud Posse) did you find any workaround for terraform cloud ?

Actually, I think he has addressed this issue so it downloads the dependencies but haven’t tried it yet

It uses another library called “dep” to manage those dependencies

I tried last helmfile provider release and no, it will not download binaries

But its generic problem of Terraform Cloud..

Did you read this section?

Seems its not stable enough, I tried:

helmfile_release_set "mystack" {
  version = "0.128.0"
  helm_version = "3.2.1"
  helm_diff_version = "v3.1.3"
  ...
}

in TF 0.13.5, but plan will get stuck, without any log info… ( TF_LOG_PATH=/tmp/tf.log TF_LOG=TRACE terraform plan )

for traefik v2? what do you need exactly?

i assume there is no way w/o having a -kustomize folder the that kustomization.yaml file