Recently I am working on small project named Kubix, the kubernetes manifest generator using Nix language.
I am working as DevOps and writing k8s manifest daily, and I found it is very painful to writing YAML and Helm charts. It is error-prone and tedious.
I am currently using NixOS as my daily driver, and familiar to Nix langu age and tried to write manifests with Nix. First I tried kubenix project and immediately fell in love with it, but I found it is somehow hard to write some custom resources like `Certificate` or karpenter `NodePool`, etc. And it lacked features like generating helm chart easily so I cannot use it in my work without changing our CI/CD infrastructure already working well.
So I wanted to make a project that:
- Easily use various CustomResources
- Strictly validated manifests on build time
- Be able to generate Helm chart, so I can integrate immediately on my CI/CD pipeline
- Easy to use so I can sell this to my coworkers
So I want to introduce my small hobby project: Kubix.
https://github.com/skystar-p/kubix
I am currently using this on my personal k8s clusters and very enjoying right now. I want to hear your opinions. Please take a look!
Very interesting project. I particularly like the build-time validation.
I’ve also made a Nix-based system for working with Kubernetes manifests albeit with slightly different goals (plain manifest output, primarily consumed by an Argo CD plugin and CI jobs for validation, diffing, etc.). It’s not public and might never be, but it has also helped us a lot with alleviating the pain points with Helm and plain manifests, and entirely replaced our countless internal Helm charts with reusable modules.
Previously the only other project I’ve been aware of doing something similar was Kubenix, so it’s fun to see others put similar ideas into practice.
One day I hope to put together something less specific to our environment incorporating the lessons learned about what works and what doesn’t into something I can publish.
I am very glad to meet someone sharing similar pain points and managed to solve that using proper tools.
I am also interested in that “ArgoCD plugin”. What does it do in your pipeline?
Argo CD normally looks for plain manifests in a Git repo. Since there are no plain manifests in the repo, what the plugin does is take a flake output reference like .#prod.ingress-nginx, build the derivation and spit out the yaml for Argo CD to work with.
This might be of interest as well:
Perhaps efforts can be consolidated.