Using umoci as a backend? about img

[jessfraz]

CBI: Container Builder Interface sounds super interesting too :) ya I mostly just wanted docker build but without docker, a daemon, or privileges. And I wanted the build cache as well so I just started with buildkit and am working my way backwards. A lot I would hope to get upstream in buildkit after so this is more like a glorifed cli in the future :) cc @tonistiigi

[AkihiroSuda]

I was wondering if you were interested in using umoci as a backend, so that you don't have to use the "dodgy" FUSE backend or overlayfs (which requires either root or an Ubuntu kernel + user namespaces). umoci unpack --rootless works on effectively everything I've tried it on.

How do you compare it with BuildKit's (more accurately, containerd's) naive snapshotter?
https://github.com/moby/buildkit/blob/40212c5fcdb3fdebe492ef80a2e237155028e62f/worker/runc/runc.go#L31

Either way, I think we can implement umoci-based implementation of containerd Differ & Applier interface, and use it in all containerd-based projects.

Re-implementing Dockerfiles isn't something that should be burning 5+ projects worth of development time IMHO

Isn't it BuildKit LLB? https://github.com/moby/buildkit/blob/master/solver/pb/ops.proto
If we can universally adapt LLB, we just need the single dockerfile2llb implementation.
LLB also allows us to adopt non-Dockerfile as well very easily.

<off-topic>
I also have an rough idea of CBI: Container Builder Interface, which would work as a Kubernetes API extension to provide buildjob CRUD objects and build context API for img/buildkit/orca/buildah/whatever...
</off-topic>

[jessfraz]

I am fine with whatever works :) I mostly used buildkit because it had a lot of what I needed :) I didn't reimplement the LLB buildkit had already done that

[cyphar]

How do you compare it with BuildKit's (more accurately, containerd's) naive snapshotter?
https://github.com/moby/buildkit/blob/40212c5fcdb3fdebe492ef80a2e237155028e62f/worker/runc/runc.go#L31

Well, umoci has been around for longer, and just uses standardised components like mtree. I'm also not sure that they have sorted out all the corner cases of rootless unpacking (but I admit I haven't taken a closer look because I'd written umoci quite a while before containerd had support for that -- so I might be wrong).

There's also a question of adoption, but I'm not sure how many people use BuildKit at the moment. I know that several projects and companies have been using umoci for a while though (nstack and Cisco for instance).

Either way, I think we can implement umoci-based implementation of containerd Differ & Applier interface, and use it in all containerd-based projects.

Though of course, it should be noted, that not everyone uses containerd as a base for everything (LXC/LXD use umoci for their OCI support -- for instance).

Isn't it BuildKit LLB?

I don't know what LLB stands for, can someone give me a tl;dr?

[AkihiroSuda]

TLDR: LLB is to Dockerfile what LLVM IR is to C.

• Low level
• Protobuf
• Vendor-neutral
• Has DAG structure (cache-efficient and concurrently executable)

[cyphar]

But does it still have the same drawbacks as Dockerfiles (in other words, is it just another representation or is it actually something new?). Is there a document online about it somewhere (I couldn't find it after a bit of Googling)?

[AkihiroSuda]

I consider LLB is new and anyone can implement new languages that might solve Dockerfile drawbacks. e.g. Build secret, INCLUDE, UNSETENV, ..., and whatever.
(Personally I would hope someone to design more helm-friendly language...)
If LLB lacks a feature, you can open PR.
Proposing new features to LLB would be significantly easier than to (Docker inc's) Dockerfile.

Design doc: moby/moby#32925

Tonis's presentation https://www.slideshare.net/mobile/Docker/state-of-builder-and-buildkit

[AkihiroSuda]

Also, could you open github issue about README readability? https://github.com/moby/buildkit/issues

Maybe we should have FAQ section?

[AkihiroSuda]

opened moby/buildkit#293 for clarifying LLB