skopeo: Image format docker-archive is not equivalent to docker save

The format of an image copied from the Docker Hub to docker-archive://my-image is not what is produced by docker save. docker save produces a image that follows this spec. Basically, the image layout is such as:

├── 47bcc53f74dc94b1920f0b34f6036096526296767650f223433fe65c35f149eb.json
├── 5f29f704785248ddb9d06b90a11b5ea36c534865e9035e4022bb2e71d4ecbb9a
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── a65da33792c5187473faa80fa3e1b975acba06712852d1dea860692ccddf3198
│   ├── VERSION
│   ├── json
│   └── layer.tar
├── manifest.json
└── repositories

While the format of the image produced by Skopeo only contains tar.gz file and a manifest.json such as:

sha256:5a132a7e7af11f304041e93efb9cb2a0a7839bccaec5a03cfbdc9a3f5d0eb481
sha256:fd2731e4c50ce221d785d4ce26a8430bca9a95bfe4162fafc997a1cc65682cce
sha256:28a2f68d1120598986362662445c47dce7ec13c2662479e7aab9f0ecad4a7416
sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
sha256:07c86167cdc4264926fa5d2894e34a339ad27f730e8cc81a16cd21b7479e8eac
manifest.json

What is this format? Is there a spec somewhere? Or would it be possible to be compliant with docker save ?

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 32 (15 by maintainers)

Most upvoted comments

The dir: format is something completely different from docker-archive:, this is not expected to work at all. If you need interoperability with docker load, use docker-archive:.

mtrmac on Jun 2, 2022

(Also, seconding the suggestion to use OCI formats for transport in the future. They have their own interoperability problems, but not as big as this, and the OCI formats benefit from a few more years of experience in the design. Of course that does not help all that much if there already is an ecosystem of tools which accept docker save-like archives.)

mtrmac on Oct 9, 2017

IMO, what really matters is whether docker load supports it, which it does.

The context for this discussion to be that there are other tools which can process the output of docker save but not the files generated by docker-archive:. I guess that’s an unexpected use case but it makes enough sense, if someone cares enough to implement this.

Not to mention I believe it would break signing, no?

Not quite for docker-archive:, which can not represent signatures. For docker-daemon: I do care about the ability to preserve signatures, but in that case the daemon decompresses and throws away the original blob anyway, so this would not be an extra obstacle. (Still, docker-daemon: should not do the decompression, we might just as well send the smaller compressed version over the socket, and let the daemon process deal with that.)

And if the format did grow support for signatures, if the decompression happened in the generic copy.Image code (possible in principle, at the cost of making copy.copyBlob even more complex), that code could decide based on the presence of signatures to skip the decompression, or refuse to decompress and fail, just like we disable compression when copying signed images.

mtrmac on Oct 9, 2017