|
|
|
|
|
by lewo
173 days ago
|
|
I think this is really close to the way nix2container works (https://github.com/nlewo/nix2container). nix2container generates metadata at build time and streams the required data at runtime. At build time, it generates a JSON file describing the image metadata and the layers data location.
At runtime, it consumes this JSON file to stream layer data and image configuration to a destination. This is implemented by adding a new transport to Skopeo. Thanks to this implementation, nix2container doesn't need to handle all various destrination since this is managed by Skopeo itself. Recently, we introduced a mechanism to also produce such kind of JSON file for the base image (see https://github.com/nlewo/nix2container?tab=readme-ov-file#ni...). I'm pretty sure the added (not usptreamed yet) transport could be useful in some other close contexts, such as Bazel or Guix. I'm the nix2container author and i will be glad to discuss with you if you think this Skopeo transport could be useful for you! (btw, your blog post is pretty well written!) |
|