#helmfile (2023-07)

https://github.com/helmfile/helmfile

Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles

Archive: https://archive.sweetops.com/helmfile/

2023-07-03

Marcus Ramberg avatar
Marcus Ramberg

So far we’ve been using helmfile.lock in our workflow, but we’ve started using Renovate and adding versions to the helmfile.yaml - however this makes the for some problems in our workflow because the lock isn’t updated by renovate. Is there any reason we need the lockfiles at all when we pin the versions in the helmfile.yaml ?

yxxhero avatar
yxxhero

please post an issue on the github repo.

Marcus Ramberg avatar
Marcus Ramberg

an issue? I’m not reporting a bug.

Gabriela Campana (Cloud Posse) avatar
Gabriela Campana (Cloud Posse)

@Andriy Knysh (Cloud Posse)

Andrew Nazarov avatar
Andrew Nazarov

We’ve been successfully using helmfile+renovate for years already without caring about lockfiles:)

1

2023-07-05

2023-07-07

Pablo Silveira avatar
Pablo Silveira

Hi everybody, I wonder how can CRDS dependencies be managed with helmfile. For example in the same run I am deploying the prometheus op CRDs and the k8s cluster autoscaler (in which values I have a service monitor resource(crd)) . my pipeline make first a helmfile diff and this fail as expected, because that resource does not exist

voron avatar

Well, I’m not sure you have to use diff in this case. Is it possible to you to use sync instead? Deps can be handled by helmfile needs: then.

voron avatar

Autoscaler chart expects service monitor is present already, you cannot handle it with diff in the same run imho.

Pablo Silveira avatar
Pablo Silveira

thank you very much I will try that!

voron avatar

Let’s imagine that you don’t have a helmfile - what would you do with helm alone to get diff with the missing autoscaler helm release?

z0rc3r avatar

RTFM

    # passes --disable-validation to helm 3 diff plugin, this requires diff plugin >= 3.1.2
    # It is useful when any release contains custom resources for CRDs that is not yet installed onto the cluster.
    # <https://github.com/roboll/helmfile/pull/1618>
    disableValidationOnInstall: false
1
1
Pablo Silveira avatar
Pablo Silveira

thank you guys, make a search in the docs but I didn’t find it

Pablo Silveira avatar
Pablo Silveira

you are the best thank you

Pablo Silveira avatar
Pablo Silveira

is there any way to avoid this control ?

2023-07-13

z0rc3r avatar

I have helmfile.yaml.gotmpl with following simplified content:

---
environments:
  core-01:
    values:
    - envType: prod
      region: <ref+vault://secret/core/service/{{> .Values.envType }}/{{ .Environment.Name }}/s3#/region

---
releases:
- name: some-release
  namespace: some-namespace
  chart: some/chart
  version: 5.0.0
  values:
  - storage:
      backend: s3
      s3:
        endpoint: s3.{{ .Values.region | fetchSecretValue }}.amazonaws.com
        region: {{ .Values.region | fetchSecretValue }}
        bucket_name: <ref+vault://secret/core/service/{{> .Values.envType }}/{{ .Environment.Name }}/s3#/storage

with HELMFILE_V0MODE=true this works fine, but with with HELMFILE_V1MODE=true produces in ./helmfile.yaml.gotmpl: error during helmfile.yaml.gotmpl.part.0 parsing: template: stringTemplate:6:54: executing "stringTemplate" at <.Values.envType>: map has no entry for key "envType". It seems v1 doesn’t allow to reuse env values in other env values. Is this right? What would be refactoring approach to keep things mostly dry?

z0rc3r avatar

In case anyone interested. With v1 mode I have to write environments with layers to resolve environment values within environment values like this:

---
environments:
  core-01:
    values:
    - envType: prod

---
environments:
  core-01:
    values:
    - region: <ref+vault://secret/core/service/{{> .Values.envType }}/{{ .Environment.Name }}/s3#/region

Which is just meh. Hopefully this will be fixed with https://github.com/helmfile/helmfile/pull/741

#741 feat: add environments values inheritance

Refers to this discussion: #726

Summary

Allow inheriting values defined in previous values items.
There were some concerns about the risk of introducing a breaking change with this feature, that’s why we changed the field name in order top isolate this behaviour and avoid breaking changes.

Default behaviour stays the same with environment values but you can now use layeredValues

Example

environments:
  default:
    layeredValues:
        - values1.yaml
        - values2.yaml.gotmpl <-- variables from values1.yaml are available in there

We added a dedicated test for EnvironmentValuesLoader.

I’m not sure about the instantiation of EnvironmentValuesLoader within desiredStateLoader. Tell me if I should do it another way.

Gabriela Campana (Cloud Posse) avatar
Gabriela Campana (Cloud Posse)

Hi @z0rc3r Do you need help on this?

z0rc3r avatar

@Gabriela Campana (Cloud Posse) is cloud posse accountable for this project?

z0rc3r avatar

I though this channel is for general helmfile discussions

Gabriela Campana (Cloud Posse) avatar
Gabriela Campana (Cloud Posse)

It is indeed, but I can chase internal resources if any community member needs help

2023-07-19

Pablo Silveira avatar
Pablo Silveira

Hello everybody, i am trying to apply a nested state implementation, I have read the docs and I think I am applying it well. this is my scheme: **** Remote repo: sre-tools-helm-centralized ├── helmfiles │ └── monitoring │ └── global │ ├── kube-prometheus-stack.yaml │ └── loki-stack.yaml └── values ├── kube-prometheus-stack │ └── global │ ├── kube-prometheus-stack-alertmanager.yaml │ ├── kube-prometheus-stack-alertmanager.yaml.gotmpl │ ├── kube-prometheus-stack-grafana.yaml.gotmpl │ ├── kube-prometheus-stack-prometheus.yaml.gotmpl ****** And I am working in this folder: 01_monitoring ├── helmfile.d │ └── helmfile-v3.yaml └── values └── kube-prometheus-stack └── kube-prometheus-stack-alertmanager.yaml ********* this is helmfile-v3.yaml content: helmBinary: helm3 missingFileHandler: Error namespace: {{ requiredEnv “NAMESPACE” }} helmfiles:

  • path: “git://[email protected]/sre-prod/sre-tools/sre-tools-helm-centralized@/helmfiles/monitoring/global/kube-prometheus-stack.yaml?ref=v1.1.1>” selectors:
    • name=kube-prometheus-stack values:
      • ../values/kube-prometheus-stack/kube-prometheus-stack-alertmanager.yaml **** this is global/kube-prometheus-stack.yaml: — helmBinary: helm3 namespace: monitoring

repositories:

  • name: prometheus-community url: https://prometheus-community.github.io/helm-charts releases:
  • name: kube-prometheus-stack chart: prometheus-community/kube-prometheus-stack version: 41.7.3 values:
    • ../../../values/kube-prometheus-stack/global/kube-prometheus-stack-alertmanager.yaml
    • ../../../values/kube-prometheus-stack/global/kube-prometheus-stack-alertmanager.yaml.gotmpl
    • ../../../values/kube-prometheus-stack/global/kube-prometheus-stack-grafana.yaml.gotmpl
    • ../../../values/kube-prometheus-stack/global/kube-prometheus-stack-prometheus.yaml.gotmpl ****** *I don’t understand why values file in “helmfiles:” section is not beeing applied?
1
Gabriela Campana (Cloud Posse) avatar
Gabriela Campana (Cloud Posse)

@Max Lobur (Cloud Posse) @Zinovii Dmytriv (Cloud Posse)

1
yxxhero avatar
yxxhero

any logs?

Pablo Silveira avatar
Pablo Silveira

yes, let me run it again

Pablo Silveira avatar
Pablo Silveira
Pablo Silveira avatar
Pablo Silveira

in line 71 de file is being rendered

Pablo Silveira avatar
Pablo Silveira

party_parrot

Pablo Silveira avatar
Pablo Silveira

Hi there, may I open an issue? I am not totally sure if there is some kind of misuse from my side..

yxxhero avatar
yxxhero

yeah. you can post a issue on the github repo.

2023-07-20

2023-07-21

2023-07-22

2023-07-24

2023-07-25

2023-07-27

    keyboard_arrow_up