container_image_tag_known_issues

container_image_tag_known_issues.md

container image tags known issues

• tags are normally used to discribe versions

• working mostly like git tags

• BUT have the same issue like git tag as that it is a changeable reference, although normally one should not change such tag reference

  • in reality though we have observed it multiple times that the underlying image to a tag changed
  • assumption in some cases was, that a fixup or similar was applied backwards
  • but this broke enough deployments for us to show an issue

• a possible solution:

  • the so called DIGEST
  • works like a git hash, it is an unique identifier for exactly that image with all the exact things in the image
  • works like any other hash over content
  • it is the most exact way to pin a version for an image
  • disadvantage: as it represents the exact content of an image it so also does for the architecture
    • means DIGEST are architecture specific

• best case you can use both, e.g.

    # note: digest for linux/amd67 arch
    busybox:1.36.0@sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754
  

  • this combines tag + digest
  • the underlying image to the tag still could change BUT as the digest is specified the image with this digest would be used instead

the @sha256... part is called DIGEST and works like a git hash would, it represents the content of the specific image, that also means the digest is architecture specific (e.g. amd64 or arm) and it is the most exact way to pin a version for an image.

In general I hold the view that it is good to use the digest, as like a git tag is just a reference to a git hash, which could, even so it should not, but could be changed to another git hash... and the same goes for container tags... we observed multiple times that an underlying image to a container tag changed, which caused issues. That can be avoided using the digest.

best case you can use both tag for intend and human readability & digest for exact version, e.g.

# note: digest for linux/amd67 arch
busybox:1.36.0@sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754

It boils down to how much you trust your tag version to really never change...

As mentioned before as the digest is arch specific, that becomes an issue for local development bec people using different machines (linux amd64 / osx arm)

So in a pipelines and for the target deploy systems (e.g. prod envs) using tag+digest makes a lot of sense for reliability/reproducibility and for local development using the tag only approach would be my recommended way of working with container tags