Will you be at NixCon? Seems like good timing to post this!
Show HN: Nix Snapshotter – Native understanding of Nix packages for containerd
31–35 of 35 posts
Re: Show HN: Nix Snapshotter – Native understanding of Nix packages for containerd
#32Earlier quoted context omitted.
If you are pushing nix-snapshotter images to a Docker Registry, then it can only either use what's in your host nix store, or fetch from a binary cache. The same is true if you are using the special image reference like `nix:0/nix/store/f8b1hia3hcqwa5d46anzy3cszi3s6ybk-nix-image-redis.tar`, it just means that instead of fetching the image manifest from a Registry, you are using the Nix protocols. You will only build…
I think your usage example will be easier to understand, if it explains where nix:0 is setup as CRI image-service. Maybe I glanced over it. Awesome project!
0 is actually an unbindable port, so nix:0 is just an arbitrary string that is unlikely to have conflicts. The Kubelet needs to be configured with —image-service-endpoint to use the nix-snapshotter gRPC socket to handle the “PullImage” RPC. There we can take over resolving the image reference when it’s prefixed with nix:0.
Re: Show HN: Nix Snapshotter – Native understanding of Nix packages for containerd
#33Earlier quoted context omitted.
I assume that if the nix daemon is being started with each pod, then you're downloading a fresh copy of everything every time, so for large closures you give up a lot of the benefit of the cluster being able to cache layers (as in, say, a nix2container- or nixery-style image) and achieve very fast subsequent startups. I'm a k8s novice, but would there be a way to run the nix daemon/cache in a semi-persistent pod on e…
> I assume that if the nix daemon is being started with each pod, then you're downloading a fresh copy of everything every time I got the impression that it uses the node's nix daemon. From the project readme's FAQ https://github.com/pdtpartners/nix-snapshotter#faq > What's the difference between this and a nix-in-docker? > If you run nix inside a container (e.g. nixos/nix or nixpkgs/nix-flake) then you are indeed fe…
Re: Show HN: Nix Snapshotter – Native understanding of Nix packages for containerd
#34Earlier quoted context omitted.
So if the package isn't in cache, then suddenly k8s node is building it from source?
If you are pushing nix-snapshotter images to a Docker Registry, then it can only either use what's in your host nix store, or fetch from a binary cache. The same is true if you are using the special image reference like `nix:0/nix/store/f8b1hia3hcqwa5d46anzy3cszi3s6ybk-nix-image-redis.tar`, it just means that instead of fetching the image manifest from a Registry, you are using the Nix protocols. You will only build…
Re: Show HN: Nix Snapshotter – Native understanding of Nix packages for containerd
#35Earlier quoted context omitted.
> I assume that if the nix daemon is being started with each pod, then you're downloading a fresh copy of everything every time I got the impression that it uses the node's nix daemon. From the project readme's FAQ https://github.com/pdtpartners/nix-snapshotter#faq > What's the difference between this and a nix-in-docker? > If you run nix inside a container (e.g. nixos/nix or nixpkgs/nix-flake) then you are indeed fe…
Yeah, I think that's the "main" idea of it, but it was also mentioned that this can work in GKE/EKS if you start a new daemon each time.
I didn’t mean running nix-snapshotter as a Kubernetes resource because then there’s a chicken & egg problem. Kubernetes needs nix-snapshotter image service to resolve the nix-snapshotter image.