Support for shared r/o images similar to CRI-O and podman "additionalimagestore"

[macaoidh88]

Our development teams would like to converge to a single runtime engine - there is currently a mix of podman, CRI-O and containerd - and one of the roadblocks in convergence is that a feature in CRI-O and podman is being used that is quite advantageous, and I was wondering if there's a way to do the same in containerd - maybe with nerdctl?

It is additionalimagestore, which allows us to set up an NFS share with overlay container images and share them with container engines running on diskless servers via the NFS mount. We don't have a lot of time to pull down huge images from a repository, so we use the image on the NFS store and start the container that way.

I saw that containerd has a beta image store feature, but it's not clear that it could be backed by an NFS mount. Understanding that this may not be a current feature, ready for production, is there a roadmap for this kind of capability?

Thanks for any help/feedback!

[estesp]

In containerd, this would be achieved via a snapshotter which knows to look for layer content in a shared/custom filesystem. An example of specifically what you are describing is implemented at Cern via the CVMFS external snapshotter[1] for containerd. Note in their official docs the usage guide for the CVMFS snapshotter[2] is listed just before their description of how to use a similar feature with podman via the additionalimagestore setting, as you mention above.

The missing link here is that no one has written a snapshotter that supports NFS as the backing store that I'm aware of. To get this support, you would need to develop this snapshotter or find one if it exists and I'm unaware of it.

[1] https://github.com/cvmfs/cvmfs/tree/devel/snapshotter
[2] https://cvmfs.readthedocs.io/en/latest/cpt-containers.html#how-to-use-the-cernvm-fs-snapshotter

[macaoidh88]

Thanks! That at least frames the possible solution. I know we've looked at snapshotter in the past as a possible way to get around repository fetch performance issues. Building something backed with NFS or maybe gluster/ceph could be a smaller investment in the end than supporting multiple runtime engines in the longer term.