Support V2 Manifest Lists

[StarGate01]

I implemented support for v2 manifest lists (https://docs.docker.com/engine/reference/commandline/manifest/).
This enables the proper display of multi-arch images, such as those generated by Docker BuildX or manually.

Tag view for multi-arch image:

Detail view of sub-image:

[roman-vynar]

Docker image format becomes super-confusing. Manifest v1, Manifest v2 and now Manifest List v2 😐

Thanks, I will take a look shortly.

[StarGate01]

Yes, the protocol keeps on expanding... However, multi-arch images are here to stay, even all the official images by Docker are using it since 2017: https://www.docker.com/blog/multi-arch-all-the-things/

[StarGate01]

I added a small fix to support the special manifest lists generated by the BuildX build cache. I also modified the manifest list display to show extended attributes in a table.

Display of cache-image:

Display of extended attributes:

[roman-vynar]

I will merge it but I am thinking to make some more refactoring afterwards.
Thanks!

[roman-vynar]

@StarGate01 Hello, can you please try the latest release 0.9.0 if it works with your multi-arch / BuildX images?

[StarGate01]

Everything seems to be in working order. Nice work! I like the addition of the "Manifest Formats" row.

If you wanted to, you could include a specialcase for Cache Images, which are images that just have a v2 manifest list with special entries. As of now, they do not carry a creation date (thus the field in the image details section is empty), and the digests of their sub-manifests are not tags/manifests, but hashes of tarballs (check the mediaType, for a sub-image it is application/vnd.docker.distribution.manifest.v2+json, and for a cache entry it is application/vnd.docker.image.rootfs.diff.tar.gzip, the same as blobs in the regular v2 manifest).

This means that the links on the digests will take the user to the tag overview for the current image because they are not valid tags. But I think this is not really a problem and could be kept as-is.

For example, a cache-type manifest list v2 begins like this:

{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "manifests": [
        {
            "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
            "digest": "sha256:19a861ea6baff71b05cd577478984c3e62cf0177bf74468d0aca551f5fcb891c",
            "size": 849,
            "annotations": {
                "buildkit/createdat": "2020-02-14T21:51:33.280494466Z",
                "containerd.io/distribution.source.ref": "[redacted-fqdn]/cache/move2docker:latest",
                "containerd.io/uncompressed": "sha256:1d0dfb259f6a31f95efcba61f0a3afa318448890610c7d9a64dc4e95f9add843"
            }
        },
        { ...

Note the missing config and the different mediaType in the sub-manifests.

If you want to reproduce those types of images, you can use Docker BuildX, like this: docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 --cache-to=type=registry,ref=your.registry.example/thecachedir/thecachename,mode=max --cache-from=type=registry,ref=your.registry.example/thecachedir/thecachename --output=type=image,push=true -t your.registry.example/theactualdir/theactualname .
The platform argument depends on what architectures you have available and want to include, but you can use Qemu binfmt really easily to create the support:

docker run --rm --privileged docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64
docker buildx create --use --name crosscomp
docker buildx inspect --bootstrap

In conculsion, thank you for upstreaming the changes and keeping the repo up-to-date. I think you could leave it as-is, because cache images are a relatively novel edge-case, but if you want to you can implement support - I dont think it would be much work. If you want to, I could also implement it in a pull request.

Edit: After theading the docs, it seems that regular manifests and cache manifests can be mixed together in a manifest list (--export-cache type=inline). So your best guess would be to only enable the hyperlink if the mediaType of the current sub-manifest is not a blob.

[roman-vynar]

I understand what you mean. So we need to do 3 things:

1. hide create date for manifest v2 only when v1 is missing (cache image, that's currently the only case now looks like) and say something like "Sub-images" instead of "Multi-arch Sub-images.
2. Return mediaType row for a sub-image section.
3. If mediatype == application/vnd.docker.image.rootfs.diff.tar.gzip does not display a link on sha256.

I will try to do this until I forgot, you have probably seen my comments in README etc. about this mess with manifests.

[StarGate01]

hide create date for manifest v2 only when v1 is missing

I would just hide the creation date if it is absent in the JSON (found in neither manifest), in that way we cover all cases where it could be absent.

Return mediaType row for a sub-image section.

Yes, that would be a useful information for the user.

If mediatype == application/vnd.docker.image.rootfs.diff.tar.gzip does not display a link

Or you could do it the other way round and only display a link if the mediaType is application/vnd.docker.distribution.manifest.v2+json. Who knows what exotic mediatypes the community thinks of next.

this mess with manifests.

Definitely. The way docker keeps on expanding makes maintenance of tools rather hard. But that is the way of such a huge open source project, new needs arise and people implement them. Just like us.

[roman-vynar]

Agree on everything, thanks!

[roman-vynar]

Can you give quiq/docker-registry-ui:0.9.1 a try please?

[StarGate01]

Everything works as expected. Thank you for your continued effort!