Imagine I have docker-compose.yml
for adding mongo
as a container, is it a good thing to set verion in front of image name or let it to be the latest by default?
version: '3.8'
services:
mongo:
image: mongo:4.0
ports:
- "27017:27017"
Actually what is the pros and cons for application in development and production realeses?
image: mongo:4.0
VS image: mongo
2
Answers
I think it’s a good thing to put version in front of the image name, you can manage them more easily, but you have to be careful to pass the update regularly to avoid loopholes.
Including a version number as you’ve done is good practice. I’d generally use a major-only image tag (
mongo:4
) or a major+minor tag (mongo:4.4
) but not a super-specific version (mongo:4.4.10
) unless you have automation to update it routinely.Generally the Docker Hub images get rebuilt fairly routinely; but, within a given patch line, only the most-recent versions get patches. Say the
debian:focal
base image gets a security update. As of this writing, themongo
image has4
,4.4
, and4.4.10
tags, so all of those get rebuilt, but e.g.4.4.9
won’t. So using a too-specific version could mean you don’t get important updates.Conversely, using
latest
means you just don’t care what version you have. Your question mentionsmongo:4.0
butmongo:latest
is currently version 5.0.5; are there compatibility issues with that major-version upgrade?The key rules here are:
image:tag
locally, launching a container will not pull it again, even if it’s updated in the repository.mongo:4.4
will continue to get updates as long as they are supported, but you may need todocker-compose pull
to get updates.mongo:4.4.9
will stop getting updates as soon as there’s a newer patch version, even if youdocker pull mongo:4.4.9
....:latest
or a minor-version tag could mean different systems get different builds of the image, depending on what they have locally. (Your coworker could have a differentmongo:latest
than you; this is a bigger problem in cluster environments like Kubernetes.)