Get default repo tag from docker-archive

[CMCDragonkai]

I used docker save to create a docker archive.

I've noticed that when using skopeo copy, it doesn't copy the default tag that's in the archive? My default tag is something like rshk0jallj0pnnriby0f1lm022fibglp, yet skopeo copy copies it as the latest tag with:

skopeo --insecure-policy copy docker-archive:/path/to/archive.tar.gz docker://$CONTAINER_REPOSITORY

On the ECR registry, I see only latest tag got updated. This is the same if I used docker://$CONTAINER_REPOSITORY:latest.

But the archive already has a default tag, as can be seen by:

[nix-shell:~/Projects/js-polykey]$ skopeo list-tags docker-archive://$(nix-build release.nix -A docker)
{
    "Tags": [
        "polykey-1.0.0:rshk0jallj0pnnriby0f1lm022fibglp"
    ]
}

Is there a way to get skopeo to push using the default tag, the tag that's already in the archive?

Right now I have to fetch the tag out of skopeo list-tags or by extracting the output of docker load before being able to use it in the skopeo copy command.

[mtrmac]

Thanks for your report.

This is working as designed: Skopeo is, mostly, a dumb wrapper around the c/image library, and skopeo copy directly exposes the underlying copy operation — with the flexibility to arbitrarily mix sources and destinations. That also means that it gives up on any heuristics for interactions between sources and destinations. The docker://repo syntax for a destination has exactly the same meaning regardless of the source.

(Apart from some theoretical cleanliness, this is necessary for such a flexible design: Otherwise, we when adding a new transport, we would have to immediately figure out all the relevant heuristics for all the relevant interactions; if we didn’t do that, any future changes to heuristics would break users.)

It is, of course, possible to design any heuristics you like, and implement that either on top of Skopeo or on top of the underling containers/image library. Podman is one tool that has a fairly extensive set of convenient commands and such heuristics.

[CMCDragonkai]

I see, ok, well I used the list-tags command to extract the container archive tag to use. But it kind of slow to run a command to extract a tag then copy. It has to unpack the archive twice.

[mtrmac]

True, a Golang application using c/image could do both with a single extraction, via https://github.com/containers/image/blob/44e127c892b7291c66f47b9735ae48a573deadfb/docker/archive/reader.go#L71 .

Integrating that into the generic copy implementation seems a bit non-obvious.

We also tend to discourage using the docker-archive format in the first place; it is inherently costly to both create and consume, especially if any kind of compression is involved. I appreciate that the available Nix tooling is what it is.

[djpbessems]

We also tend to discourage using the docker-archive format in the first place; [...]

I'm curious; what other format can I use that is compatible with ctr image import?

[mtrmac]

That command seems to only consume tar archives, so they are all going to be, at least to an extent, inefficient.

In that case, write images to a registry, and pull from a registry instead of importing; even if that meant running a single-purpose registry just for that process. As long as the same compression choices are made, it’s likely to end up being more efficient.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mtrmac]

Closing: this is working as currently designed.

Alternatively, as far as design goes, it seems reasonable to support docker-archive as a source or destination in skopeo sync; skopeo sync necessarily does name mapping between sources and destinations (although, currently, not very well), so that would fit. OTOH the performance issues of existing docker-archive are such that it’s really not worth it: I think any effort spent to teach skopeo sync about docker-archive would be better used modifying consumers to use a registry. (Maybe there are performance improvements to be had in the code that consumes docker-archive… at a pretty high cost in effort, again.)

Specialized users can write a small wrapper on top of the underlying containers/image library instead of using the generic Skopeo CLI.