Do all docker images have minimal OS?

Question

I am trying to learn Docker and for that referring to online materials. I came to know that there is official hub of images which we can pull, and run a container.

The repos are available at https://hub.docker.com/ , part of screen shot:

In this diagram we can see the official images of ubuntu, httpd, mysql (and so on).

My question is:

Do all these images have "minimal OS" on which they run. For example, if we consider httpd image, does it have the needed OS on which it runs?

Answer 1

I think a lot of these answers miss the point. Explaining what you can or may do does not answer the question: do all docker images need an OS?

After a bit of digging, the answer is no.

https://docs.docker.com/develop/develop-images/baseimages/

FROM scratch
ADD hello /
CMD ["/hello"]

There's no OS defined in this Dockerfile. Only a precompiled binary hello world app

Also here https://hub.docker.com/_/scratch

Also in this question:

https://serverfault.com/questions/755607/why-do-we-use-a-os-base-image-with-docker-if-containers-have-no-guest-os

An answerer makes this statement:

why do we base the container on an OS image? Because you'd want to use some commands like (apt, ls, cd, pwd).

So often the OS is just included because you might want to use some bundled low level tools or SSH into it to do some things.

Answer 2

Here's the answer: "Containers," in all their many forms, are an illusion!"

Every process that is "running in a container" is, in fact, running directly on the host operating system. But it is "wearing rose-colored glasses." It thinks that it knows what its user-id is ... but it doesn't. 🤷‍♂️ It thinks it knows what the network looks like. What the filesystem looks like. ... ... ...

And, it can afford to think that way, because nothing that it is able to see would tell it otherwise.

... But, nothing that it sees is actually the physical truth.

"Containerization" allows us to achieve the essential technical requirement – total isolation – at very-considerably less cost than "virtualization." The running processes see what they need to see, and so "they need be none the wiser." Meanwhile, the host operating system, which is aware of the actual truth, can very-efficiently support them: it just has to maintain the illusion. The very-expensive "virtual machine" software layer is completely gone. The only "OS" that actually exists is the host.

Answer 3

From my understanding images are built in a layered architecture from a parent image. So we have a parent image and then the changes for this image is one more layer above parent image. If you see dockerfile for an image you can see something like this

FROM node:6.11.5

This node:6.11.5 is a parent image for our current image.

If you check dockerfile of parent images you will find they are somewhere in the hierarchy follow from base image.

This base image is basically an OS without kernel but has only userland software based on the different linux distributions(eg, centos, debian). So all the images uses the host OS kernel. Hence, you cannot install a Windows container on a Linux host or vice-versa.

So basically all images are layered changes on the base image which is an OS without kernel.

Please find below links for further information:

https://serverfault.com/questions/755607/why-do-we-use-a-os-base-image-with-docker-if-containers-have-no-guest-os

https://blog.risingstack.com/operating-system-containers-vs-application-containers/

If you need to create a base image you can see the steps here.

https://docs.docker.com/develop/develop-images/baseimages/

Please correct me if i am wrong.

Answer 4

The whole idea is that the whole image is completely stand-alone running on hardware/virtualization layer. And thus (the pro:) also cannot be influenced by anything else than that is part of the image.

Every image contains an complete os. Special docker made OS's come with a few mega bytes: for example linux Alpine which is an OS with 8 megabytes!

But bigger OS like ubuntu/windows can be a few gigabytes. Both have their advantages since docker cuts an image up in layers so when you use anbase image twice (FROM command, see N20 Answers) then you will only download this layer once.

Smaller OS has the pro of only needing to download a few megabytes. but for every (linux) Library you want to use, you will have to download & include yourself. This custom made layer then is only used in your own image and thus is not re-used in other images and thus creates a customer extra download layer & megabytes people will have to download to run your image.

If you want to make an image from nothing you can start your dockerfile with:

FROM scratch

But this is not advised, unless you really know what your are doing and/or you are hobbying around.

Answer 5

Most images are based on a distribution as you can see it in their Dockerfiles. Except for the distribution images themselves. They have a different base-image, which is called scratch.

You can review the images they are based on when you visit the project's page on DockerHub, for example https://hub.docker.com/_/httpd/

Their Dockerfiles are referenced and you can review them by clicking on them, e.g. the first tag "2.2" refers to this file. The first line in the Dockerfile is FROM debian:jessie and shows, that it is based on a Debian image.

It is widely used to have a separated tag with the postfix -alpine in it to indicate, that alpine linux is used, which is a much smaller base-image than the Debian image. This leads to a smaller image of the httpd image, because the base-image is much smaller.