There are images on docker registry which have names like ubuntu or redhat. Do these images run the complete operating system or do they only contain the utilities that come with the operating system? I thought the operating system is always of the host and the docker image should not be running the operating system. Kindly clarify.
Usually, the operating system images in the registry are a ‘slimmed down’ version of a full blown OS. If you look at the size of the Ubuntu image for example, you’ll see it is only a couple of hundred meg in size.
So is it an OS at all? Does it have a kernel that interfaces with the
The Dockerfile for each will provide what is in it and what is not.
For example, the Ubuntu ‘trusty’ image manifest is located here
This appears to be a bunch of utilities that typically come with a Ubuntu
distribution, and not really the OS. Am I right in understanding that such
images are just a collection of utilities but not the OS itself?
I guess it depends on what you define as the “OS”. It is a lighter-weight OS. The Ubuntu image is running a kernel, but doesn’t have the kernel .deb files. It can interact with devices that are included - but it is a whole lot less than a full blown Ubuntu.
Docker images (including the ubiquitous
debian images) don’t contain kernels, and containers based on them don’t run kernels; they always share the host kernel. You need to go through special setup to be able to use host devices, regardless of what
/dev special files exist in a container.
You can make an argument that the
ubuntu image has unnecessary components that aren’t used in typical Docker setups (an init system, a DHCP client) that make it closer to a “full OS image”; or you can make an argument that, since
ubuntu doesn’t have its own kernel, it’s “not an OS”. I’m not really sure how “operating system” is defined these days.
The operating system of the host is not the operating system running in the container. That is the beauty of using containers. For example: the OS of the host could be RedHat and the OS of the container could be Ubuntu. The only thing that the host and container share is the kernel of the host. The filesystems and everything else are of their respective operating systems. Applications running in an Ubuntu container are running on Ubuntu. Applications running in an Alpine container are running on Alpine. It doesn’t matter that the host might be CentOS or any other Linux distro. Every container is running some linux distro that does not have to be the host distro. Hopefully that helps to clarifiy things for you. If not, ask more questions.
The only thing that the host and container share is the kernel of the host…
if host operating system kernel has corrupt than what about docker…
Then the Docker containers will be affected too because they share the same kernel.
There is no magic. A “container” really isn’t a “thing”. It’s a concept. The process that is supposedly “inside” the container is actually running on the host in it’s own namespace, control group (
cgroup), and union filesystem overlay. A cgroup limits a process to a specific set of resources.
Here is an example of running
ps and grepping for
redis and then running Redis in a container and running
root@test:~$ ps -aef | grep redis root 9652 8764 0 17:58 pts/0 00:00:00 grep --color=auto redis root@test:~$ docker run -d redis:alpine 10e3b5825260dacb6821157c3b20d0480f1558cd7c545d767cb469a62bb6b64a root@test:~$ ps -aef | grep redis systemd+ 9771 9734 1 17:59 ? 00:00:00 redis-server root 9837 8764 0 17:59 pts/0 00:00:00 grep --color=auto redis
This first time we run
redis we just see our grep command running. Then we start a Redis docker container and look at
ps again and see that
redis-server is actually running on our host with pid
Processes running in a container are sharing the same kernel as the host so if the kernel becomes corrupt, it is corrupt for every process running on the host including those running in Docker containers.