Open cyphar opened 6 years ago
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>
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
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
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?
TLDR: LLB is to Dockerfile what LLVM IR is to C.
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)?
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: https://github.com/moby/moby/issues/32925
Tonis's presentation https://www.slideshare.net/mobile/Docker/state-of-builder-and-buildkit
Also, could you open github issue about README readability? https://github.com/moby/buildkit/issues
Maybe we should have FAQ section?
opened https://github.com/moby/buildkit/pull/293 for clarifying LLB
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. You can take a look at https://github.com/cyphar/orca-build (which is a rootless image builder I wrote quite a long time ago) to see how it works in practice.(Also, as an aside, now that we have
img
andorca-builder
and Akihiro'sPRoot
plans andBuildKit
and ..., maybe we should start consolidating some of these projects at some point? Re-implementing Dockerfiles isn't something that should be burning 5+ projects worth of development time IMHO.)