Add Docker exporter

[tonistiigi]

buildctl build ... --exporter=docker --exporter-opt name=myimage | docker load

The exported tarball is compatible with Docker v1.10 and newer. Older versions that only accept the v1.0 tarball will not work.

The tarball is also fully compatible with OCI. We can figure out later if containerd upstream is also interested of any of this code and in what way and what packages should contain what code(related to #215). My current thinking is that special package for exporter/oci is not needed and different variants can all be under containerimage.

based on #227

[AkihiroSuda]

SGTM, but containerd/CRI-containerd Docker v1 importer does not support loading this manifest yet: https://github.com/kubernetes-incubator/cri-containerd/blob/b88315707238082397a9475af0663bd1c432b7a3/pkg/containerd/importer/importer.go#L55-L65

[tonistiigi]

@AkihiroSuda We should create an issue to get this fixed. v1.1 does not specify any mandatory paths for these files, they are only in certain locations if v1.0 compatibility is needed.

[AkihiroSuda]

This PR sets "org.opencontainers.image.ref.name" to "docker.io/library/myimage:latest", but AFAIK most implementation does not expect docker.io/library/myimage: portion to be included here.

[AkihiroSuda]

For Docker v1 manifest.json, can we allow setting multiple repotags?

[tonistiigi]

This PR sets "org.opencontainers.image.ref.name" to "docker.io/library/myimage:latest", but AFAIK most implementation does not expect docker.io/library/myimage: portion to be included here.

Don't they expect a valid reference there? I'd think myimage itself is not a valid reference but rather than erroring, we support expanding it to a valid reference if the user only typed a short version that is common in docker UI.

For Docker v1 manifest.json, can we allow setting multiple repotags?

The format supports them but we would need a way to pass that with exporter opts. Is it a common use case?

[AkihiroSuda]

Don't they expect a valid reference there? I'd think myimage itself is not a valid reference but rather than erroring, we support expanding it to a valid reference if the user only typed a short version that is common in docker UI.

Having a valid reference is 100% correct, but not "common": https://github.com/opencontainers/image-spec/blob/7c889fafd04a893f5c5f50b7ab9963d5d64e5242/image-layout.md

Implementor's Note: A common use case of descriptors with a "org.opencontainers.image.ref.name" annotation is representing a "tag" for a container image. For example, an image may have a tag for different versions or builds of the software. In the wild you often see "tags" like "v1.0.0-vendor.0", "2.0.0-debug", etc. Those tags will often be represented in an image-layout repository with matching "org.opencontainers.image.ref.name" annotations like "v1.0.0-vendor.0", "2.0.0-debug", etc.

So, having a reference value is likely to cause compatibility issues with other OCI implementations. (Such implementations should be blamed though 😄 )

[tonistiigi]

I think I misunderstood the meaning of org.opencontainers.image.ref.name. By my definition it doesn't make any sense to have a ref name that is v1.0. This is a version (a tag) not a name. Do I revert this(and #227) and only leave Docker RepoTags?

[tonistiigi]

Updated