have plan to support docker image pull?

[xujihui1985]

docker are still widely used nowadays, but it still use graphdriver instead of snapshotter to prepare image, do you have plan to support docker?

[ktock]

@xujihui1985 Yes, I really would love to integrate to Docker.

I've worked on moby/moby#41002 but it does not reach to the agreement. There are also on-going issue moby/moby#38043 and moby/moby#38738 for using containerd as the Docker's image backend but it not completed as well.

[AkihiroSuda]

@ktock Can we revisit the initial "bootfs" approach

[ktock]

Interesting. Mounting stargz as "bootfs"? I'll take a look.

[xujihui1985]

@ktock we have a similar approach as bootfs https://github.com/dragonflyoss/image-service which convert image with meta and blob, and we also have large scale deployment inside, would you like to have look at that :)

[xujihui1985]

stargz is the first choice when we evaluate the image lazyloading, and it is amazing, we need

1. file content aware approach instead of block level as we can analyze file access pattern
2. extreme fast image pulling speed

but we found something that not meet our requirement

1. flatten fuse mountpoint instead of multilayer with overlay
2. low memory footprint (the stargzindex file is quite large as the image we dealing is really large maybe 20GB)
3. daemon live upgade
4. separate snapshotter with control plane and data plane, (remote snapshotter as control plane, nydusd as data plane)

[ktock]

Thanks for the suggestion!

We agree with all of the following requirements. Just needs more time & help for implementing them.

1. flatten fuse mountpoint instead of multilayer with overlay
2. low memory footprint (the stargzindex file is quite large as the image we dealing is really large maybe 20GB)
3. daemon live upgade

Could you elaborate the following?

4. separate snapshotter with control plane and data plane, (remote snapshotter as control plane, nydusd as data plane)

[xujihui1985]

@ktock remote snapshotter will die for whatever reason, we can't afford the consequence that if snapshotter die, all the container that running on that just die, we hope snapshotter to become a control plane that just manage the fuse daemon, and when it die, it can restart and restore back to its state and container running on that will not affect by its crash

[AkihiroSuda]

nerdctl supports lazy-pulling with Docker-compatible CLI: https://github.com/AkihiroSuda/nerdctl

nerdctl --snapshotter=stargz run -it --rm ghcr.io/stargz-containers/fedora:30-esgz

[xujihui1985]

@AkihiroSuda thanks Akihiro, this looks promising