Hacker News new | past | comments | ask | show | jobs | submit login

I think I've commented this elsewhere, but using Cue [1] is also great for this purpose, with no extra infrastructure. E.g. you define a Cue Template [2], which seems analogous to Yoke/ATC's CRDs, and then your definitions just include the data.

Here's an example of Vaultwarden running on my K8s cluster:

    deployment: bitwarden: {
      spec: {
       template: {
        spec: {
         containers: [{
          image: "vaultwarden/server:1.32.7"
          env: [{
           name:  "ROCKET_PORT"
           value: "8080"
          }, {
           name: "ADMIN_TOKEN"
           valueFrom: secretKeyRef: {
            name: "bitwarden-secrets"
            key:  "ADMIN_TOKEN"
           }
          }]
          volumeMounts: [{
           name:      "data"
           mountPath: "/data"
           subPath:   "bitwarden"
          }]
          ports: [{
           containerPort: 8080
           name:          "web"
          }]
         }]
         volumes: [{
          name: "data"
          persistentVolumeClaim: claimName: "local-pvc"
         }]
        }
       }
      }
     }
And simpler services are, well, even simpler:

    deployment: myapp: spec: template: spec: containers: [{
      ports: [{
       containerPort: 8080
       name:          "web"
      }]
     }]
And with Cue, you get strongly typed values for everything, and can add tighter constraints as well. This expands to the relevant YAML resources (Services, Deployments, etc), which then get applied to the cluster. The nice thing of this approach is that the cluster doesn't need to know anything about how you manage your resources.

[1] https://cuelang.org/

[2] https://cuelang.org/docs/tour/types/templates/




I really want to dive in with Cue, but one thing that I got burned on when using jsonnet to generate CloudFormation templates years ago was lack of discoverability for newcomers to the repo.

Taking your sample code as an example, someone might look at the myapp deployment definition and ask: “does this deployment get created in the default namespace or does it automatically create a myapp namespace? What’s the default number of replicas? Are there any labels or annotations that get automatically added?” Etc.

On the flip side, there’s potential lack of “greppability.” The user may have found a problem with a deployed resource in, say, the development cluster, and go to grep for some resource-specific string in the repo, only to come up empty because that string is not in the source but rather generated at by the templating system.

To be clear, both of these problems can affect any method of generating config, be it yoke, helm, ksonnet, kustomize, or cue. It’s like a curse of abstraction. The more you make things into nice reusable components, the easier it is for you to build upon, and the harder it is for others to others to jump in and modify.

At least with Cue you get properly typed values and parameter validation built in, which puts it miles ahead of “everything is a string” templating systems like the helm templates the article complains about.


I was kind of interested in cue earlier last year as IIRC it can be served by helm and is much much better than templating yaml. Never really got started with it. Wish they had an LSP too.

https://github.com/cue-lang/cue/issues/142


What the hell is going on with their bot copy-pasting every comment on that issue? What a mess

Anyway, I wanted to ask what you meant by "served by helm?" I knew about https://github.com/stefanprodan/timoni and https://github.com/holos-run/holos but I believe they are merely "inspired by helm" and not "cue for helm"


Reminds me of gcl (yikes).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: