Run Nix Based Environments in Kubernetes
1–10 of 50 posts
Re: Run Nix Based Environments in Kubernetes
#2How does this differ from the tooling that lets you build containers from nix?
Re: Run Nix Based Environments in Kubernetes
#3How does this differ from the tooling that lets you build containers from nix?
seems similar to this
https://github.com/pdtpartners/nix-snapshotter
so kind of allowing pull images from nix store, mounting shared host nix store per node into each container, incremental fast rebuilds, generating basic pod configs are good things.
and local, ci and remote runs same flows and envs.
Re: Run Nix Based Environments in Kubernetes
#4When I worked on an enterprise data analytics platform, a big problem was docker image growth. People were using different python versions, different cuda versions, all kinds of libraries. With Cuda being over a gigabyte, this all explodes.
The solution is to decompose the docker images and make sure that every layer is hash equivalent. So if people update their Cuda version, it result in a change within the Python layers.
But it looks like Flox now simplifies this via Nix. Every Nix package already has a hash and you can combine packages however you would like.
Re: Run Nix Based Environments in Kubernetes
#5[flagged]
Re: Run Nix Based Environments in Kubernetes
#6When I worked on an enterprise data analytics platform, a big problem was docker image growth. People were using different python versions, different cuda versions, all kinds of libraries. With Cuda being over a gigabyte, this all explodes. The solution is to decompose the docker images and make sure that every layer is hash equivalent. So if people update their Cuda version, it result in a change within the Python l…
Yes, there were various attempts to do this in the container ecosystem, but there is a hard limit on layers on Docker images (because there are hard limits on overlay mounts; you don't really need to overlay all the Nix store mounts of course as they have different paths but the code is for teh geenral case). So then there were various ways of bundling sets of packages into layers, but just managing it directly through Nix store is much simpler.
Re: Run Nix Based Environments in Kubernetes
#7[flagged]
You can say what you want about Kube (it's a bit of a necessary evil for the people that need it), but keep Nix's name out yo damn mouth. It's for real.
Re: Run Nix Based Environments in Kubernetes
#8Too bad this isn't open source, I'm 3/4ths of the way through building pretty much this exact product in order to support my actual products.
Re: Run Nix Based Environments in Kubernetes
#9When I worked on an enterprise data analytics platform, a big problem was docker image growth. People were using different python versions, different cuda versions, all kinds of libraries. With Cuda being over a gigabyte, this all explodes. The solution is to decompose the docker images and make sure that every layer is hash equivalent. So if people update their Cuda version, it result in a change within the Python l…
Yes, there were various attempts to do this in the container ecosystem, but there is a hard limit on layers on Docker images (because there are hard limits on overlay mounts; you don't really need to overlay all the Nix store mounts of course as they have different paths but the code is for teh geenral case). So then there were various ways of bundling sets of packages into layers, but just managing it directly throu…
Re: Run Nix Based Environments in Kubernetes
#10Too bad this isn't open source, I'm 3/4ths of the way through building pretty much this exact product in order to support my actual products.
Is it not GPL?
The license file in their github seems to indicate that it is. https://github.com/flox/flox?tab=GPL-2.0-1-ov-file