search

moby / buildkit

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
https://github.com/moby/moby/issues/34227
Apache License 2.0
8.21k stars 1.16k forks source link

wcow: support OCI-worker for Windows #4836

Open profnandaa opened 7 months ago

profnandaa commented 7 months ago

Currently, only containerd worker is supported and therefore there is a hard dependency on containerd for buildkitd to run. On the Linux end, you have a vanilla option where you can run buildkitd with only runc using the OCI worker. Actually, this is the default for Linux, you set --oci-worker=false --containerd-worker=true to use the containerd worker.

However, on Windows, containerd is the only supported worker, and therefore the default.

slonopotamus commented 5 days ago

What is an OCI worker? I believe that the only worker buildkit has besides containerd is heavily tied to runc (and, transitively, to Linux): https://github.com/moby/buildkit/tree/master/executor/runcexecutor

profnandaa commented 5 days ago

@slonopotamus -- perhaps it's just nomenclature, @iankingori had started looking at this, I'll let me him chime in. /cc. @billywr

jedevc commented 4 days ago

The runc worker is just using the underlying OCI spec (calling it via the runc go library, I guess that's the source of the naming). However, it should be completely possible to replace the runtime there from runc to any other OCI compliant runtime.

iankingori commented 4 days ago

Yeah, the goal here is to implement runhcs in place of runc for windows containers. The naming was from main_oci_worker.go.