Is there an easy way to see what operating system distribution a particular Docker Hub’s image tag uses?
To be more specific, I’m wanting to look at an images /tags URL in my browser and at a glance be able to tell which OS distribution to expect (ex. Debian bullseye, Debian buster, Alpine, CentOS 7 etc.)
For the “jenkins” image for example, on the tags page, I see:
But I have no idea what OS distribution each of them will give me if I have a line like this:
No, not before you pull the image and start at least a shell in the container to check the content of /etc/os-release. An image is not necessarily contain any distribution at all. A single binary could be copied to the image and start in the container.
Some tips that you could still try:
Click on the tag or one of the digests in the list of tags and if you find apt-get commands in the image history, at least you know that is a debian based image, but not whether it is Debian or Ubuntu or any oher Debian based distro.
Read the documentation mentioned in the image descriptions. That may mention the distribution.
Try to find the Dockerfile which was used to create the image and check the FROM keyword which may contain the name of the distro.
Many image descriptions has a list if tags too linking to the Dockerfile files.
If you can’t find it in the description, look for any link that leads you to a git repository and try to find the Dockerfile in the repo. There is a link to the documentation on GitHub and multiple Dockerfiles are available in the repo, but you still don’t know what distribution belongs to what tag.
Interesting. Is there a recommended practice for specifying your distro in your Dockerfile? Usually our Dockerfiles are running distro specific commands (such as package manager installs) that are specific to a specific distro (yum vs apt-get for example).
It would just be really nice to be able to look at a Dockerfile that a team member has made and know exactly what distro is being used.
Also, for a certain tag like “lts” in the example of the Jenkins image, the underlying distro may change over time with no indication to the user writing the Dockerfile (when pulling an update to the image / tag). Hoping there’s some easier way to lock this down and make this visible.
Other than using a base image like ubuntu:jammy, not really. A distribution in an image is not like a distribution on a host. A container image is for running one or a couple of processes. All you need is copy the necessary files in the image. Copying files similar to Linux distribution helps, but not required. So even if the distro is Debian, you can’t be sure it has any package manager. It usually has, but doesn’t have to.
If we are talking about official base images like ubuntu, centos, debian or almalinux, we already know what package manager they use. They could also add labels (inspectable by docker image inspect), but they don’t. . If you find an image which is just based on a distribution, the image maintainer’s job to properly document the image describing what distribution it is based on. Even if they don’t, it can be found out quickly after downloading the image and just using an image without learning more about it is a bad idea anyway.
“lts” is like “latest” Never recommended using it in a Dockerfile. You can pull it not thinking about what is the exact distribution when you don’t care since you just want to run a demo quickly. You can often find LTS in documentations because it is easier to refer to that than change the version every time a new bugfix comes out or a new LTS version is released but it works the same way as the previous LTS…
For jenkins I would use something like these
I couldn’t find the same version for all distributions and I don’t know whrere it is documented, but when there is no distribution in an image tag, it is not always, but often debian based as in this case.
In the official documentation which you can find starting from the image description mentions a more specific version than the github readme
To extend on @rimelek’s response: the key is that both are mutable tags. Today they point to a specific image that contains a specific x.y.z version today, but might point to an updated image with a x+1.0.0. version tomorrow. Breaking changes could take you by surprise, without giving you the chance to properly plan and test the migration.