Try CUE for writing helmfile.yaml

[mumoshu]

I got to know about the CUE language which is similar to Jsonnet at glance but based on somewhat different theory and goal.

CUE provides you a typed, structured template that can be used in various places of your helmfile.yaml for templating and validation. With CUE, you can avoid all and the mix of nested go text template expressions and YAML anchors.

In the context of Helmfile, compared to Jsonnet(#814), CUE's ability to reference sibling fields while defining field keys and values, templating and unification is the key features to ease writing a huge set of helmfile configs.

Curious? Please take a look at the below examples and share your thoughts 😃

Basic example

helmfile.cue

_release <NAME>: {
  name: NAME
  chart: "charts/\(name)"
  values: [
    "\(name).yaml"
  ]
}

_release mydb: {}
_release myweb: {}

// Render helmfile releases
releases: [
  v for k, v in _release
]

cue export helmfile.cue

{
    "releases": [
        {
            "name": "mydb",
            "chart": "charts/mydb",
            "values": [
                "mydb.yaml"
            ]
        },
        {
            "name": "myweb",
            "chart": "charts/myweb",
            "values": [
                "myweb.yaml"
            ]
        }
    ]
}

Advanced example

helmfile.cue

// Constants

baseValues:: ["defaults.yaml", {foo:"bar"}]

_ns: "myns"

// Templates

// _release is a template of helm releases that has conventional chart name and the default ns
_release <NAME>: {
  name: NAME
  // Or "charts/\(NAME)". `name` is a sibling of this `chart` field that can be referenced from within this interpolation(`\( ... ))
  chart: "charts/\(name)"
  namespace: _ns
}

// _releaseB is a template of helm releases that has conventional values files
_releaseB <NAME>: {
  name: NAME
  chart: "charts/\(name)"
  namespace: _ns
  values: baseValues + [
    "\(NAME).yaml"
  ]
}

// Releases

// mydb is a conventional release that conforms to _release
_release mydb: {
  values: baseValues + [
  ]
}

// myweb is a conventional release that conforms to myweb
_releaseB myweb: {
}

// myapi is a non-conventional release that is similar to those of _releaseB
r1:: "myapi"
_release "\(r1)": {
  values: baseValues + [
    "\(r1).yaml", // \(r1) is a interpolation expr that is replaced to the value of r1 = "myapi"
    "extras.yaml"
  ]
}

helmDefaults: {
  tillerless: true
  wait: true
}

// Render helmfile releases
releases: [
  v for k, v in _release
] + [
  v for k, v in _releaseB
]

You can run cue export to render JSON from CUE.

cue export helmfile.cue

{
    "helmDefaults": {
        "tillerless": true,
        "wait": true
    },
    "releases": [
        {
            "name": "mydb",
            "chart": "charts/mydb",
            "namespace": "myns",
            "values": [
                "defaults.yaml",
                {
                    "foo": "bar"
                }
            ]
        },
        {
            "name": "myapi",
            "chart": "charts/myapi",
            "namespace": "myns",
            "values": [
                "defaults.yaml",
                {
                    "foo": "bar"
                },
                "myapi.yaml",
                "extras.yaml"
            ]
        },
        {
            "name": "myweb",
            "chart": "charts/myweb",
            "namespace": "myns",
            "values": [
                "defaults.yaml",
                {
                    "foo": "bar"
                },
                "myweb.yaml"
            ]
        }
    ]
}

The JSON data built with CUE can be consumed by any helmfile command as JSON is subset of YAML:

cue export helmfile.cue > helmfile.yaml
helmfile -f helmfile.yaml template

If you're still interested, I'd recommend reading CUE's Kubernetes tutorial that shows you how to gradually reduce boilterplate from your K8s manifests.

We're interested in reducing boilterplate in helmfile.yaml but the theory and technics mentioned there would still be useful.