Just say no to :latest

2022-Mar-02 • by David Norton

Don’t specify latest in your Dockerfile! Or anywhere else! Do you want to
live in a van down by the river?

FROM alpine:latest

It breaks one of the core requirements of continuous delivery: reproducible, idempotent builds. This can cause problems
at best when trying to build your project, and at worst in a production failure.

Perhaps worse than specifying latest in a Dockerfile, we definitely don’t want to specify latest in a Kubernetes
Pod manifest. At least if you use the latest in your
Dockerfile to create a versioned image, you could roll back to your previous versioned image if something happened.

If your deployment manifest specifies a latest image, then it could update any time a new pod needed to roll out, and you would be
at the mercy of the maintainers to not break compatibility. This could happen on a weekend or the middle of the night,
when a node goes bad!

# BAD:
image: "nginx:latest"

# GOOD:
image: "nginx:1.21.6"

(This brings up an interesting side point, in that Docker Hub and most other registries allow mutable tags by default.
So nginx:1.21.6 might not be the same image today as it was yesterday. In reality, you probably need a mechanism to
enforce tag immutability: e.g., your own registry mirror, or referring to images by SHA).

Latest dependencies exist in most ecosystems

You can have unversioned dependencies in your installation script:

# BAD:
pip install awscli

# GOOD:
pip install awscli==1.22.60

Or in your package.json:

# BAD if you don't have a lock file
"depen