2 ms·
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 sa
by hinshun 3y ago
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 from source dynamically (and a mix of caching) if you are doing `kubectl apply -f ${podSpec}` as a full deployment Nix expression. See the README's asciinema and this file as an example: https://github.com/pdtpartners/nix-snapshotter/blob/v0.1.0/examples/declarative-k8s.nix#L47-L70 https://github.com/pdtpartners/nix-snapshotter/blob/v0.1.0/e...
- alex_hirner 3y agoI 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!
- hinshun 3y agoHi Alex, I’ve updated the README with a bit more information. 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.
- 0x457 3y agoOh, I see. Thank you for explaining. I misunderstood how this works.