Containers created with digest pinning won't show up

I've noticed that containers that got created with a specific digest won't show up in the UI and only give a warning about not being able to get a tag in the logs. For example:

09:17:45.807 WARN whats-up-docker/watcher.docker.local: Cannot get a reliable tag for this image [vaultwarden/server:alpine@sha256:a5fefd207e070177d1047ce35cd130b99a2127d6c12b074a06653893e61f1530]

You can quickly check this behavior by starting a container with a pinned digest like this for example:

docker run -d -e I_REALLY_WANT_VOLATILE_STORAGE=true vaultwarden/server:alpine@sha256:a5fefd207e070177d1047ce35cd130b99a2127d6c12b074a06653893e61f1530

Hi,

When the image is referring a sha256 digest and not an image, I try to inspect the image to get the matching tag using the RepoTags property.

Unfortunately, not all images are built in the same way so some images cannot provide a way to determine the tag corresponding to the digest.

For example, if I inspect the bitwarden image, I can see that only a Label is referring to the associated tag (org.opencontainers.image.version):

$ docker inspect vaultwarden/server:alpine@sha256:a5fefd207e070177d1047ce35cd130b99a2127d6c12b074a06653893e61f1530

[
    {
        "Id": "sha256:94daa1cedce9fde0da2e0d1cfefeab89d3d5ee67c613eb78ddc8366f0a0bcd74",
        "RepoTags": [],
        "RepoDigests": [
            "vaultwarden/server@sha256:a5fefd207e070177d1047ce35cd130b99a2127d6c12b074a06653893e61f1530"
        ],
        "Parent": "",
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2022-10-14T18:27:41.081467857Z",
        "Container": "",
        "ContainerConfig": {...},
        "DockerVersion": "",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {...},
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [...],
            "Cmd": [...],
            "Healthcheck": {...},
            "ArgsEscaped": true,
            "Image": "",
            "Volumes": {...},
            "WorkingDir": "/",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "org.opencontainers.image.created": "2022-10-14T18:11:06+00:00",
                "org.opencontainers.image.documentation": "https://github.com/dani-garcia/vaultwarden/wiki",
                "org.opencontainers.image.licenses": "GPL-3.0-only",
                "org.opencontainers.image.revision": "638766b346dc0e00c5db7935d21e48354d632335",
                "org.opencontainers.image.source": "https://github.com/dani-garcia/vaultwarden",
                "org.opencontainers.image.url": "https://hub.docker.com/r/vaultwarden/server",
                "org.opencontainers.image.version": "1.26.0"
            }
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 88410695,
        "VirtualSize": 88410695,
        "GraphDriver": {...},
        "RootFS": {...},
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

This is not a standard so I cannot implement it; it won't work for most other images 😞 .

Maybe I'm going crazy but looking at the inspect

        "Id": "sha256:94daa1cedce9fde0da2e0d1cfefeab89d3d5ee67c613eb78ddc8366f0a0bcd74",
        "RepoTags": [
            "vaultwarden/server:1.26.0-alpine",
            "vaultwarden/server:alpine"
        ],
        "RepoDigests": [
            "vaultwarden/server@sha256:a5fefd207e070177d1047ce35cd130b99a2127d6c12b074a06653893e61f1530"
        ],

and now it shows up in the UI after recreating the container. It does think that the next update would be the tag webauthn-arm32v6 but I'm a bit confused as to why it just gave an error a few days ago.

Meanwhile creating a redis container for example docker run -d redis:alpine@sha256:32f8cf4bf6412626b21273fed376182b6786b75182e4a19f90f3f57d01362fbb correctly identifies a new digest tag with sha256:d937dcf39e204d8c1d148544d94cb542a60bac0dfddb83b62939f7ec1ae9a865

You're not crazy but... 😂

Here is a simple test you can do:

Get rid of all previous vaultwarden images

$ docker rmi vaultwarden/server:alpine vaultwarden/server:1.26.0-alpine vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271

Pull & inspect vaultwarden/server:alpine

$ docker pull vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271
$ docker inspect --format='{{.RepoTags}}' vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271
[]

Pull vaultwarden/server:alpine and inspect vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271

$ docker pull vaultwarden/server:alpine
$ docker inspect --format='{{.RepoTags}}' vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271
[vaultwarden/server:alpine]

Pull vaultwarden/server:1.26.0-alpine and inspect vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271

$ docker pull vaultwarden/server:1.26.0-alpine
$ docker inspect --format='{{.RepoTags}}'  docker inspect --format='{{.RepoTags}}' vaultwarden/server@sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271
[vaultwarden/server:1.26.0-alpine vaultwarden/server:alpine]

So you can see that the RepoTags property of the sha256:d73b431499dfd9c916f5d820eccdb13752366b1fb5ecdbb2d9ed86119ebc9271 image is influenced by all other tags pointing to the same hash you've locally pulled.

I'm sorry but I think there is no reliable way to correlate a locally sha256 pulled version to a remote semver related tag.

getwud / wud

Containers created with digest pinning won't show up #190