What's A Better Docker Tag Than :latest?
What’s a better naming scheme for Docker image tags than the tricky :latest tag? What naming schemes can help you have an easier time handling your Docker images, and make it harder to run into unexpected errors?
Let’s look at a few options!
The Thing With “Reusing” Tags
If you use another tag than :latest, you might still run into issues if you end up “reusing” the same tag for different images.
Imagine tagging your staging images with :staging. If you’re using an orchestration tools, it might just look at the tag and refuse to download a new version of the image, because “there’s a :staging image right here, I don’t need another one”.
Of course, you can configure your orchestration tool to work around that - Kubernetes for example can be configured to “always try pulling” an image. (That’s the default behaviour if you tell it to use a :latest image by the way). However! Using such a imagePullPolicy: always policy can make deploys unnecessary slow. You’d have to try pulling a new image version each time after all.
Tags As Artifact Names
In some way, the names of Docker images are very similar to build artifacts in the 12-factor kind of way. You can read about them here. Build artifacts are only based on a certain version of the codebase, and can be “named” according to a commit or semantic version of the application being packaged.
Tags As Release IDs
If you’re using Docker images to produce releases (bundling up configs as well as code), then it could even make sense to name them in a similar fashion as releases. Here’s the relevant part: “Every release should always have a unique release ID, such as a timestamp of the release (such as 2011-04-06-20:32:17) or an incrementing number (such as v100)”.
So What’s A Good Tag?
Whether you prefer a commit hash as name, a semantic version or a steadily increasing number depends as much on personal taste as it does on your other deployment workflows.
You could tag your images with a “semantic version” of your app, you could tag them with a commit hash, you could tag them with an incrementing number or the date & time…
You can also decide to reuse tags (if you’re careful), but it can make some other things tricky: if you want to “go back” (aka roll back) to a previous image version overwriting previous image names isn’t handy.
In Conclusion
There is no “one correct way” to do it, but multiple options which are all fine if you are fine with them. You can choose your own adventure and do what suits your taste and needs best.
If you need some more inspiration, you can check out how naming is handled in other ecosystem - on Heroku for example. Docker is just one of many tools for packaging up and shipping your code after all :)