Docker: What’s better image tag than latest, none, and versions?

Oct 4, 2020 · 2 min read · docker latest tag  ·
Share on:

In my opinion, and based on the experiences that I've operated our Kubernetes cluster on AWS EKS for my company's service, docker image tag should be date string like "yyyymmddHHMMSS". So, let me share why I'm thinking about it.

I know that most of the docker images of open source software like NGINX, MySQL, Go, PHP are version numbers or combined with base image names like Debian, Alpine. That’s why at first I put version number like "appname:1.0" but I realize that it’s not good because of the following reasons

  • Hard to understand when the currently running image was built
  • Need to concern about versioning rule when building the image
  • When using CI/CD pipeline, need to define the version numbering rule in advance
  • If somebody put a version manually, there's a possibility to make a mistake

So, I came up with using a date string as a tag. For example, if the current date and time is 20/Sep/2020 12:30 I put the "test-app:202009201230" tag to the image. But it's bothering to put it manually, so I make a script like this.

 1#!/bin/bash
 2export DOCKER_BUILDKIT=1
 3ECR_FQDN='000000000000.dkr.ecr.us-west-2.amazonaws.com'
 4VER_DATE=`date '+%Y%m%d%H%M'`
 5APP='test-app'
 6TAG="${ECR_FQDN}/${APP}:${VER_DATE}"
 7
 8docker build -t $TAG . \
 9&& docker push $TAG \
10&& sed -i "s;\(image: \).*;\1${TAG};g" ./deployment_prod.yml

Of course, it depends on the projects, if its release version is managed very strictly, the version number will be good for the tag. But the project is updated and released frequently, I think the date string is better. Also, I usually avoid using the "latest" tag because it's hard to grasp which version is running now. The other problem of the "latest" tag is when I deploy on the Kubernetes cluster, it will not be a trigger to renew pods.