patterndockerMinor
Dockerfile base image
Viewed 0 times
dockerfileimagebase
Problem
I have a Python application that I want to containerize with Docker. Should I use
Does the
I could not find a clear answer to these questions in the official documentation.
FROM python:3 or FROM python:3.7?Does the
python:3 tag automatically use the latest minor version of Python? Would there be a practical reason to pin to version 3.7 explicitly?I could not find a clear answer to these questions in the official documentation.
Solution
Generally, when referencing 3rd party packages (Docker base images, Maven dependencies, Ruby Gems etc.) it is worthwhile to be as specific as possible. You want to avoid randomly upgrading dependencies at a later time, just because there's a newer version out there, just because you only specified a prefix of the actual 3rd party release number.
I personally would do whatever it takes to make sure that I get the same upstream version on every build, forever, and that upgrading always is an activity I have to d, that is never done for me. For example, in Ruby, the
The reasoning is very simple - we use tools like Docker specifically to get out of the upgrade/version hell we had in the past; to make sure that we have the same versions on all environments, and to make changes visible (in the form of
There is really nothing elaborate like that Ruby
For your particular example, to pick at random, a version like
I personally would do whatever it takes to make sure that I get the same upstream version on every build, forever, and that upgrading always is an activity I have to d, that is never done for me. For example, in Ruby, the
bundler keeps specific versions in the Gemfile.lock. While the Gemfile can specifiy vague versions (like "~> 3.1" giving you anything ">= 3.1 and < 4.0"), whenever a version is picked by the automatic resolving, the actual immutable version is fixed in the Gemfile.lock and will never change on its own.The reasoning is very simple - we use tools like Docker specifically to get out of the upgrade/version hell we had in the past; to make sure that we have the same versions on all environments, and to make changes visible (in the form of
git commits etc.). Introducing the same all over, by having "floating" upstream version numbers, would really be a shame.There is really nothing elaborate like that Ruby
Gemfile.lock, for Docker base images, so in this case you have to look at the images you are pulling; they should document which tags are considered permanent. Then just specify those. And stay clear of latest, obviously.For your particular example, to pick at random, a version like
3.6.6-alpine3.7 seems to be pretty fully specified. I'd expect not much more than bugfixes from upstream. But if I were especially paranoid on that day, I might specificy a @digest for the FROM (I'm not that paranoid normally...).Context
StackExchange DevOps Q#4454, answer score: 2
Revisions (0)
No revisions yet.