What is docker's scratch image?

32k views Asked by At

I'm new to docker and I was trying out the first hello world example in the docs. As I understand the hello-world image is based on top of the scratch image. Could someone please explain how the scratch image works? As I understand it is essentially blank. How is the binary executed in the hello-world image then?

3

There are 3 answers

4
yamenk On BEST ANSWER

The scratch image is the most minimal image in Docker. This is the base ancestor for all other images. The scratch image is actually empty. It doesn't contain any folders/files ...

The scratch image is mostly used for building other base images. For instance, the debian image is built from scratch as such:

FROM scratch
ADD rootfs.tar.xz /
CMD ["bash"]

The rootfs.tar.xz contains all the files system files. The Debian image adds the filesystem folders to the scratch image, which is empty.

As I understand it is essentially blank. How is the binary executed in the hello-world image then?

The scratch image is blank.The hello-world executable added to the scratch image is actually statically compiled, meaning that it is self-contained and doesn't need any additional libraries to execute.

As stated in the offical docker docs:

Assuming you built the “hello” executable example from the Docker GitHub example C-source code, and you compiled it with the -static flag, you can then build this Docker image using: docker build --tag hello

This confirms that the hello-world executable is statically compiled. For more info about static compiling, read here.

0
Joe.wang On

In a short, The official scratch image contains nothing, totally zero bytes. But the container instance is not what the container image looks like. Even the scratch image is empty. When the container like runC run up a instance from a image built from scratch, It need more things (like rootfs etc.) than what you can see in the dockfile.

0
telefoontoestel On

A bit late to the party, but adding to the answer of @yamenk.

Scratch isn't technically an image, but it's merely a reference. The way container images are constructed is that it makes use of the underlying Kernel providing only the tools and system calls that are present inside the kernel. Because in Linux everything is a file you can add any self-contained binary or an entire operating system as a file in this filesystem.

This means that when creating an image from Scratch, technically refers to the Kernel of the host system and all the files on top of it are loaded. That's why building from Scratch is no also a no-op operation and when adding just a single binary the size of the image is only the size of that binary plus a bit of overhead.

The resources that you can assign when executing an image in a container is by leveraging the cgroups functionality and the networking makes use of the linux network namespacing technique.