What are the base layers of Docker's Python image-CodePudding

I've looked everywhere but it seems a complete breakdown of the actual layers isn't available (at least I can't find it).

I'm new to Docker and I'm trying to understand everything on how the system works. I've understood the layer system that Docker uses to create and store its images.

Now my issue is to understand exactly which layers are present inside the official Docker Python image. From my computer knowledge, I know that Python needs some sort of "foundations" to work. This thought has been partially confirmed by the fact that, on the Docker Python image webpage you can actually see the OS/ARC the image is based on.

For instance, if we take the slim-buster image, according to the webpage, I can count several operations executed.

My question is: are those operations the actual layer or, are the layers simply two? The OS/Kernel layer and the actual Python layer?

CodePudding user response：

The layers you can see on the web page you linked are the actual layers. So there are 15 layers in that image.

Some of the layers do a lot of work, like the first one which ADDed a tar ball and extracted it. That tar ball contains a lot of files.

Most commands in a Dockerfile result in the creation of a new layer.

You can usually trace the complete Dockerfiles back to the origin since a lot of them are open source.

The python:slim-buster Dockerfile is here: https://github.com/docker-library/python/blob/8d48af512dc58e9c29c9d4ee59477c195a29cbdc/3.10/buster/slim/Dockerfile

At the top, you can see that the base image is debian:buster-slim. With a bit of googeling, you can find the Dockerfile for that here: https://github.com/debuerreotype/docker-debian-artifacts/blob/d99a48edaa18ad2bbb260c388b274c8c093f2d32/buster/slim/Dockerfile

That image is based on scratch which is an empty image. So that's the end of the chain. The tar file in the ADD command in the debian:buster-slim image basically contains the complete Debian setup needed to run Debian.

Something interesting to note in the Python Dockerfile is that a lot of the RUN statements contain a lot of commands chained together with &&. That's done to reduce the number of layers. If each single command in those RUN statements were on it's own RUN statement, there'd be a lot more layers.