What does HackerNews think of nix2container?
An archive-less dockerTools.buildImage implementation
Language:
Go
#48
in
Docker
Definitely check out nix2container— it's fundamentally oriented around asserting state on the remote container registry rather than your local store, so it not only won't push layers that already exist remotely, it won't even pull the contents necessary to assemble them, which can be a huge time savings for incremental building of these things:
FYI, the nix2container [1] project (author here) aims to speedup the standard Nix container workflow (dockerTools.buildImage) by basically skipping the tarball step: it directly streams non already pushed layers.
For a more modern iteration of that idea, check out https://github.com/nlewo/nix2container
It has all the benefits of OP but produces the images much faster, and with less on-disk usage.
I've been using nix2container[1] for awhile now. It looks like this depends on Docker, have you guys considered removing that dependency? It shouldn't be necessary to create an OCI compliant image with Nix.
With https://github.com/nlewo/nix2container, I'm trying to make a more standalone tool. Basically, a Go binary takes a reference graph and produces a JSON file describing a container image. This JSON file is then ingested by a Skopeo fork (it adds a new `transport`) to produce images (to file, registries,...).
Currently, it supports the dockerTools layering algorithm and is designed to work with Guix [1] as well;)
[1] https://github.com/nlewo/nix2container/blob/065e5b108650ee4c...