And that tag is a relative free formed string that points to a specific image. Images in docker are referred to by a reference, the most common being an image repository and tag. It seems typical to reuse the same tag for this: for instance, ubuntu:18.04 gets updated every week or two.)
#DOCKER TAG SOFTWARE#
(The one special case that comes to mind is a software package that changes rarely and so might need to be rebuilt if there are upstream fixes or security updates. You could then run something like imagename:1.2.3 with some confidence. You would probably expect the first two images to be fairly constant, but the latter two to change routinely. This combination of things could mean the same image is tagged imagename:g1234567, :1.2.3, :master, and :latest, and your CI system would need to do four docker pushes. Avoid using latest and other tags that you expect to change when referring to built images (in docker run commands, Dockerfile FROM lines, Kubernetes pod specs.Given its prominence it's probably useful to tag something as latest (maybe the most recent release).If it's useful for your development workflow, also tag builds that are the tips of branches with their branch name.(More generally, if the current source control commit is tagged, tag the Docker image with the source control tag.) If and when you do official releases, also tag builds of that release with the release number.Give every build a unique identifier, something like a source control commit ID or a timestamp.Similarly, pulling an image tag, if it's a duplicate of an image you already have, is all but free, but there's no easy way to find out all of the tags for a given image. The expensive part of the push is the layer content and so this will mostly just push the fact of the alternate tag on an existing image. Mechanically, you can give the same image multiple tags, but you need to docker push all of them. The only special tag value is that if you just say imagename in a docker pull or docker run command, it is automatically interpreted as imagename:latest. A tag can be any string value at all, and tags can be reused. Moreover, using git's short version ID might be a good solution for internal use, but when publishing docker image for public consumption, it then might not be the best solution.ĭocker gives no semantic meaning at all to tag values. And both miss the pushing/publishing part from the answer.Īs I do need to push/publish my docker image to Docker repository, and from here it hinted that not using latest will give you trouble when pulling the latest, if you go with specific ID tagging.
#DOCKER TAG HOW TO#
So, how to properly versioning Docker Images (both locally and when pushing/publishing to docker hub)?
Docker image versioning and lifecycle management, because IMHO it did not address versioning Docker Images properly:
0 kommentar(er)
