kubenix support

[blaggacao]

Some things are just better (more stably) deployed in kubernetes.

Acknowledging this statement, it would be extremely nice to integrate or at least have a pathway to deploy kubernetes applications on devos hosts (presumably through kubenix).

Broader context: I feel while targeted at individual's uses, this repository can have a perfect second life to structure small business / company environments.

Even broader context: nickel is explicitly designed as a general purpose configuration language. And divnix/devos has already done an excellent job at integrating complex, but genious, stuff.

Feel very free to close, if this is off-direction. 😉

Further resources:

• https://zimbatm.com/deploying-k8s-apps-with-kubenix/
• https://www.tweag.io/blog/2019-03-07-configuring-and-testing-kubernetes-clusters/
• https://github.com/xtruder/kubenix
• https://github.com/gilligan/kind-kubenix
• Kubenix refactoring xtruder/kubenix#9 (comment) — but sadly Kubenix refactoring xtruder/kubenix#9 (comment)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[nrdxp]

It's tough to draw a line between personal and professional when you manage them in the same way. I think the scope of the original vision does include professional work. I Just wasn't 100% positive of that in the beginning. I think this would be remarkably useful, although perhaps the work on Arion would be a better nix-first approach?

Of course, there is nothing wrong with supporting both, since the bulk of the implementation and maintanence is left to the user.

[blaggacao]

although perhaps the work on Arion would be a better nix-first approach?

Indeed, arion might be a better intermediate approach, though it doesn't come with the same distributed self healing capabilities of k8s.

For the reference, some prime useful applications that I would find interesting to deploy that way (since they are "k8s-native"):

• https://openintegrationhub.github.io/
• https://zeebe.io/
• https://spiffe.io/
• https://www.keycloak.org/ or https://dexidp.io/
• I can potentially contribute a k8s version of https://ae-dir.com/ for LDAP
• but there is also: https://github.com/jefferyb/k8s-jitsi-meet or a similar HA version of a matrix home server

(

we could eventually put together a secured company template environment on a business branch to help the start-ups out there moving faster with nix 😄

You can see the computer age everywhere but in the productivity statistics.
Robert Solow (1987)

)

[blaggacao]

Even further reference:

• https://discourse.nixos.org/t/kubenix-call-to-rejuvenate/11603 (call for renewed maintainership of kubenix)
• Rejuventate with kustomize White Box Application concept xtruder/kubenix#26 (strategically hook into the emerging — potentially massive — White Box Application configuration database)

[tgunnoe]

if there is to be a remote deployment solution, I would prefer this type of repository to remain nix-only configurations. I don't think its a good idea to deviate from that, after all this is supposed to be a gateway into nixos.

If a deployment system does come to exist here, I've been meaning to combine my fork with nixus, a 100% nix-lang deployment system. Mostly to run nixos-rebuild switch and my nixflk config builds and deploys to my local machines (desktop, laptop, arm device etc) simultaneously with a complete matching config, and no more need to do the same thing in multiple places.

[blaggacao]

if there is to be a remote deployment solution, I would prefer this type of repository to remain nix-only configurations. I don't think its a good idea to deviate from that, after all this is supposed to be a gateway into nixos.

Given nix's excellence, I totally understand the desire to favour nix-centric technologies and keep out it's direct competitor (which happen to also get a lot more attention — unfairly so because of huge marketing budgets). Let's split this issue's proposal into it's components though: There is NixOS and nix-lang (a configuration management language). NixOS shines at almost anything, except for self healing capabilities. nix-lang shines at everything.

K8s brings not only those self-healing capabilities, but also has a huge ecosystem for us to leverage, where we should read the word ecosystem as being a reified massive existing configuration database. Combining k8s with nix-lang (later nickel) and complement where nixOS falls short is — in my opinion — a match made in heaven.

[nrdxp]

if there is to be a remote deployment solution, I would prefer this type of repository to remain nix-only configurations. I don't think its a good idea to deviate from that, after all this is supposed to be a gateway into nixos.

@tgunnoe, I agree with this sentiment. Though, as long as the implementation remains unobtrusive and completely optional, I'm okay with kubenix support as well. I just don't want it to be mandatory.

[blaggacao]

I think though kubenix needs some overhauling in its current state. I'll be trying to support @adrian-gierakowski — who agreed to adopt maintainership of kubenix — in this endeavor in any way I (usefully) can.

... maybe divnix/devos might result as a good fit for their use case, as well. 🤷‍♂️