Bring nix build to moby/buildkit (or leap-frog to a CRI shim for a rootfs composer drawing from a SAN-attached nix store)

blaggacao · August 29, 2020, 2:22am

Or maybe it’s enough/better to implement ~~nixc~~ nixd , a ~~runner~~ daemon (or rather containerd plugin!) that skaffolds containers upon reception of a manifest from something like ipfs-based nix store. See Nix, Containerization, and SquashFS - with some crfs features. One step further than what nixery does - just throwing in loose ideas - but since k8s is seeing RuntimeClass - why not take the shortcut? - would solve most of the interesting use cases in kind of a nix-native way. and smells a ton like “innovation”. CI output could be just used as “registry”. - Had I only the skills to do it

I just wonder what would have to go into the image: field (or instead of it?). A handle to a CRD-induced nix build which nixd knows how to intercept?

/cc @burke for the sqashfs input

Sure, if buildkit does the nix builds instead of nix itself that woudn’t hurt - as it would have previsously forced the nix instantiate and build implementations to become more composable.

EDIT: CRI protobuf api allows arbitrary metadata (read nix derivations or expressions) in the imageSpec. Checkpot!

github.com

kubernetes/cri-api/blob/0b6afe85c1f7b9416b1f612f005a4ee4c31d22a9/pkg/apis/runtime/v1alpha2/api.proto#L526-L534


      
          // ImageSpec is an internal representation of an image.
          message ImageSpec {
              // Container's Image field (e.g. imageID or imageDigest).
              string image = 1;
              // Unstructured key-value map holding arbitrary metadata.
              // ImageSpec Annotations can be used to help the runtime target specific
              // images in multi-arch images.
              map<string, string> annotations = 2;
          }