Skip to content

Experiments with CUE on the quest to reimagine devops-ops.

License

Notifications You must be signed in to change notification settings

hofstadter-io/cuelm

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Cuelm

latest tag

Experiments with CUE for Helm, Terraform, and more in the quest to reimagine devops ops. This repository has a collection of scripts and files to:

  • generating CUE schemas for|from tools & apis
  • enrichments and transformations, everything is a snowflake
  • automation for creating e2e artifacts the CUE community can use

Currently

you can...

kubernetes:

  • schemas and enrichments (schema/k8s)
  • validate yaml resources
  • generate yaml from CUE

terraform:

  • generate TF provider schemas as JSON (reshaping & cuetifying is WIP) (schema/tf)

You'll need cue, dagger, and/or hof depending on which parts you use. We use these tools to automate CUE schema generation for all the things.

Goals

The inspirational idea is to build a CUE based experience as we develop code and ship it from developer to user. We want to leverage the various tools we already use, but also explore where a CUE first approach might yield something better.

  • single config language spanning from commit to desired state
  • Real packages, imports, references, language constructs
  • Native schemas, defaults, templates, and transformations via Cue
  • consistent, singular source-of-truth (as much as possible anyway)
  • start as glue, replace when appropriate

I want to say

  • deploy this app for me...

    • it needs a database table in my namespace, I may or may not have one running (dev/test/ci vs prod)
    • spin up required infra, but be lazy like dagger
  • want a drop in upgrade for the vanilla cue import of k8s

    • publish a module, use as a dep eventually, import path domain, maybe need something else?
    • wrap vendor/k8s/... with schema/k8s/... rather than adding files into the generated content?
      • apiVersion & kind & other consts, port and other _ fields, perhaps we treat these differently?
    • hof create to add to current projects for now

Pains

DevOps' Inferno - The Circles of YamHell

  • Helm: Yaml files with text/template, ... more ... talked about elsewhere
  • HCL: Terraform, bad language constructs, leaky abstractions (most have this leak)
  • Pulumi: Language SDK or "yaml" (extended and !!"interact with outside world")
  • Crossplain: how does this fit in? Has some improvements, but need k8s just to do tf?!

Generally,

  • multiple, tool specific, languages or "enhancements"
  • competing workflows, or tools viaing to be the most important

Current work

  • Dagger to do cue import k8s

  • fill in the gaps

    • add schema to ports (was _)
    • add apiVersion & kind to all k8s objects
    • various fields are underspecified, (like ip / cidr)
  • defaults (show different scales of providing them, schema separate from defaults)

  • Hof creator to setup using this project

  • publish OCI modules to github for enriched k8s

    • (make these github.com/hofstadter-io/k8s.io/... explain the hof prefix will go away)
    • Dagger to publish
  • example of a widely used chart side-by-side with the CUE version (especially show the templates) (also cloc)

  • Hof flow to run gen / stacks / charts / helm

Usage

  • Setup your project as a Cue module (hof mod init cue <module name>)
  • Add this repo to your cue.mods file and hof mod vendor cue
  • Create Cue files using this (external example)
  • cue export -e Install | kubectl apply -f -