support docker commit

[ghost]

Support packing writable layer of an existing container into sgz blob format. this may be very useful for migrating containers across machines.

See also containerd/nydus-snapshotter#232

[dmosdallas]

This is an idea that I'm very interested in as well.

With the stargz-snapshotter configured & running a container that is already formatted in eStargz, I can run a docker commit and have it create a new image that retains the eStargz-format for the base layers, but not for the newly-created one.

If I'm understanding correctly, you're asking for the newly-committed layer to also be in eStargz format?

[ktock]

As of now you can do something like the following for converting the commited image but yes it would be great if docker commit natively support this.

cat <<EOF | docker buildx build -t newimage -o ...(omit)...compression=estargz,force-compression=true -f - /tmp/emptydir
FROM your-commited-image
EOF

[dmosdallas]

@ktock, yep! I was just trying out this approach and it sort-of works. Two things I've noticed:

1. The committed image needs to be pushed to my repo. For some reason, the buildx builder is unable to find the committed image if it's just stored locally. Not a huge deal to me, I'm assuming it's another issue of the flavor of docker & stargz-snapshotter looking at different local repos?
2. Repeatedly doing this trick fails. To reproduce:
   a. Create a new estargz image.
   b. Run a container using that image.
   c. Run docker commit && docker push && docker buildx build to create a new estargz-formatted image using the newly-committed content.
   d. Launch a new container using the new image created in c.
   e. Attempt doing (c.) with this new container. During the docker push, I get an error like: content digest sha256:4995b2a4e3208e54e262024d707e4ef39a4ee0f8b3aaf277c3ffb7c81bd592ce: not found

[dmosdallas]

Should have mentioned, when I do an inspect on the image I'm trying to push in 2e., no layer has the digest that it's complaining about.

[dmosdallas]

I've been investigating this more today and I think a docker commit with the stargz-snapshotter is less functional than I originally thought.

When I do a docker commit on a container that was launched using this snapshotter, the full container is pulled down as part of the commit process. Is that how it is currently expected to work? I'm not familiar enough with the internals of how a docker commit pulls a container's base layers vs how a docker run does to understand if this discrepancy is surprising.

If this is currently working as expected, is it clear how much effort would be required to teach docker commit to use this snapshotter instead of pulling the full base image? And if this is reasonably well-scoped, I'd be happy to contribute work to make this functional.

Thanks!

[ktock]

@dmosdallas

If this is currently working as expected, is it clear how much effort would be required to teach docker commit to use this snapshotter instead of pulling the full base image? And if this is reasonably well-scoped, I'd be happy to contribute work to make this functional.

Thanks. Though I haven't look deeper into docker's implementation of commit, I guess first we need to make sure that creating the uppermost layer tarball from the written container doesn't cause full scan on the rootfs data. IIRC the default layer creation logic (differ) of containerd is that it compares the entier rootfs contents between the old image and the updated container and it can cause large download of the rootfs data. Rather than fully-comparing the rootfs contents, we should create the uppermost layer tarball simply from the overlayfs upperdir written by the container if stargz-snapshotter or other overlayfs-based snapshotter is used (this is how BuildKit achieve layer creation without fully downloading the base image contents).

[ghost]

we should create the uppermost layer tarball simply from the overlayfs upperdir written by the container if stargz-snapshotter or other overlayfs-based snapshotter is used

will this be supported soon?