#I was looking into various containerd
jolly meadow
So people can build, run CI/CD via Dagger and deploy using the same stack . All sharing the same cache and having the ability to lazy pull efficiently with low latencies,etc.
Totally agree with this sort of vision. We've discussed the possibilities around integrating with estargz/nydus previously, it's pretty exciting especially in combination with easy-to-use cloud caching.
In reality , it does not look easy to get people to migrate to the new shiny thing, maybe the build/CI is doable but deployment runtimes doesn't seem to be an easy task.
That's spot on too. I agree that it's currently hard to imagine a world where everyone agrees on a single format for this sort of thing. There are too many tradeoffs between the different approaches to make it obvious how everyone could agree on one format.
For example, estargz has file-level granularity and uses FUSE, while nydus has block-level granularity and uses a newer in-kernel filesystem called EROFS. All of that has implications on use-case-specific performance, complexity of setup, kernel version requirements, host configuration, etc.
Personally, the block-level granularity and use of in-kernel filesystems seems most appealing to me, so the ideal path in my mind would be that those approaches get fleshed out, integrated with other features of container runtimes (e.g. rootless containers) and the kernel versions required become old enough that it becomes a safe assumption that "pretty much everyone" is running a kernel with all the required features.
- Honestly there's also room for entirely different approaches to emerge too. There's so much being added to the kernel in recent years like ebpf, better support for high-performance intercepts of process syscalls w/ ptrace, etc. All of which feel perhaps underexplored as options for implementing container filesystems.
The problem is that the above is at minimum many years away from being plausible 🙂 This feels like the type of thing that would take 5-10 years to come to fruition.
However, I think in the meantime Dagger could and should explore integrating with the current remote snapshotters. It would just require that when exporting images for use with external container runtimes the user has the option to convert to whatever format they need. Which is less ideal but can serve as a bridge of sorts.
carmine robin
Here’s my take on all those ideas for improving the standard. Imagining a better standard is easy, which is why there are so many candidates. The hard part is the delivery vehicle to get it adopted. You need to get so many people to adopt your new thing, that it can become a “trojan horse” for a new standard. That’s what Docker did.
Dagger has an opportunity to do the same, because it wraps OCI across your entire software supply chain, and it can be retrofit into so many stacks. The missing pieces are 1) zenith (to make Dagger directly usable to app teams) and 2) better marketing. Then our top of funnel will be large enough to get critical mass. THEN we get a chance to push sn improved standard.
Setting technical standards is rarely just a technical thing 🙂
The magic trick to leveraging Dagger’s scale to improve OCI, is that once you use Dagger end-to-end, OCI becomes less important. Still important but not the critical load-bearing source of truth that it has become today.
dull sentinel
All of that has implications on use-case-specific performance, complexity of setup, kernel version requirements, host configuration, etc.
yeah, its mostly the runtime that'll take a while. The idea of "continuous building" is pretty much an adoption problem at this point, as people are realising its the fastest way to fix vulnerabilities too and its really good that these formats are a first class citizen of Buildkit.
while nydus has block-level granularity and uses a newer in-kernel filesystem called EROFS.
They also had a FUSE variant in previous version. Really like where the project is heading tho- pluggable storage backends and potential to integrate with package managers.
This feels like the type of thing that would take 5-10 years to come to fruition.
yeah, it'll take a while for general compute workloads to adopt it.
Lot of it depends on cloud vendors, feels like a catch22 almost.
Although there are use-cases emerging where people are already tweaking their containerd configs (ex: WASM workloads) so it needs enough hype to be a thing
that it can become a “trojan horse” for a new standard.
I like that analogy 😄
Dagger has an opportunity to do the same, because it wraps OCI across your entire software supply chain,
Makes sense.
Thanks both for sharing your thoughts, really appreciate it 🙂
I think in the meantime Dagger could and should explore integrating with the current remote snapshotters. It would just require that when exporting images for use with external container runtimes the user has the option to convert to whatever format they need.
Would it also require a different build of Dagger engine? As I see Buildkit does- https://github.com/moby/buildkit/blob/master/docs/nydus.md
I think the tar variants(stargz, socci, etc) might just work out of box as they're "OCI" compaitable if we can configure Dagger engine with containerd.
Both Nydus and OverlayBD seem to rely on the compression flag and having oci-mediatypes=true : https://github.com/data-accelerator/buildkit