The smallest Docker image - less than 1000 bytes

Note trans. : The author of this material is the architect at Barclays and the Open Source-enthusiast from Great Britain Ian Miell. It aims to make a convenient Docker image (with a “sleeping” binary), which does not need to be downloaded, but rather simply copied via copy & paste. By the method of trial, error and experiments with the Assembler-code, it achieves the goal by preparing an image smaller than a kilobyte in size.

How did I come to this?

Once a colleague showed a Docker image that he used to test Kubernetes clusters. He did nothing: just ran under and waited for you to kill him.

“Look, it takes only 700 kilobytes! Its really fast to download! ”

And then I was curious what kind of minimal Docker image I can create. I wanted to get one that could be encoded in base64 and sent literally anywhere by simple copy & paste. Since the Docker image is just a tar file, and a tar file is just a file, everything should work out.

Tiny Binary

First of all, I needed a very small Linux binary that doesn't do anything. It will take a bit of magic - and here are two wonderful, informative and worthy articles about creating small executable files:

• Smallest x86 ELF Hello World ;
• " A Whirlwind Tutorial on the Really Teensy ELF Executables for Linux ."

I didn’t need “Hello World”, but a program that just sleeps and works on x86_64. I started with an example from the first article:

  SECTION .data msg: db "Hi World",10 len: equ $-msg SECTION .text global _start _start: mov edx,len mov ecx,msg mov ebx,1 mov eax,4 int 0x80 mov ebx,0 mov eax,1 int 0x80 

Run:

 nasm -f elf64 hw.asm -o hw.o ld hw.o -o hw strip -s hw 

It turns out the binary is 504 bytes .

But still, not “Hello World” is needed ... First, I found out that the .data or .text sections are unnecessary and no data loading is required. In addition, the upper half of the _start section deals with text output. In the end, I tried the following code:

 global _start _start: mov ebx,0 mov eax,1 int 0x80 

And he compiled already in 352 bytes .

But this is not the desired result, because the program simply completes its work, but we need it to sleep as well . As a result of additional research, it turned out that the mov eax command fills the processor register with the corresponding Linux system call number, and int 0x80 makes the call itself. This is described in more detail here .

And here I found the desired list. Syscall 1 is exit , and the one we need is syscall 29:pause . The result was such a program:

 global _start _start: mov eax, 29 int 0x80 

We saved another 8 bytes: the compilation produced a result of 344 bytes , and now it is a suitable binary that does nothing and waits for a signal.

Delving into hexes

It is time to get a chainsaw and deal with the binary ... For this, I used a hexer , which is essentially vim for binary files with the ability to directly edit hexes. After lengthy experiments, I got from this:



… this:



This code does the same thing, but notice how many lines and spaces are gone. In the course of my work, I was guided by such a document , but by and large it was a way of trial and error.

So, the size has decreased to 136 bytes .

Less than 100 bytes?

I wanted to know if it was possible to go further. After reading this , I assumed that it would be possible to reach 45 bytes, but - alas! - not. The tricks described there are designed only for 32-bit binaries, but for 64-bit ones they did not work.

The best that I managed to do was to take this 64-bit version of the program and embed it in my system call:

 BITS 64 org 0x400000 ehdr: ; Elf64_Ehdr db 0x7f, "ELF", 2, 1, 1, 0 ; e_ident times 8 db 0 dw 2 ; e_type dw 0x3e ; e_machine dd 1 ; e_version dq _start ; e_entry dq phdr - $$ ; e_phoff dq 0 ; e_shoff dd 0 ; e_flags dw ehdrsize ; e_ehsize dw phdrsize ; e_phentsize dw 1 ; e_phnum dw 0 ; e_shentsize dw 0 ; e_shnum dw 0 ; e_shstrndx ehdrsize equ $ - ehdr phdr: ; Elf64_Phdr dd 1 ; p_type dd 5 ; p_flags dq 0 ; p_offset dq $$ ; p_vaddr dq $$ ; p_paddr dq filesize ; p_filesz dq filesize ; p_memsz dq 0x1000 ; p_align phdrsize equ $ - phdr _start: mov eax, 29 int 0x80 filesize equ $ - $$ 

The resulting image is 127 bytes . At this point, I stopped trying to reduce the size, but accept the offers.

Tiny Docker Image

Now, when there is a binary that implements endless waiting, it remains to put it in the Docker image.

To save every possible byte, I created a binary with a file name of one byte - t - and placed it in the Dockerfile , creating an almost empty image:

 FROM scratch ADD t /t 

Note that there is no CMD in the Dockerfile , as this would increase the size of the image. To run, you will need to pass a command through the arguments to the docker run .

Then the docker save created a tar file, and then compressed it with maximum gzip compression. The result is a ported Docker image file of less than 1000 bytes in size:

 $ docker build -tt . $ docker save t | gzip -9 - | wc -c 976 

I also tried to reduce the size of the tar file by experimenting with the Docker manifest file, but in vain: because of the specifics of the tar format and the gzip compression algorithm, such changes only increased the final gzip. I tried other compression algorithms, but gzip turned out to be the best for this small file.

PS from translator

Read also in our blog:

• “The Linux distribution from scratch for building Docker images is our experience with dappdeps ”;
• " Statistics on basic operating systems in images on the Docker Hub ";
• “ We assemble Docker images for CI / CD quickly and conveniently along with dapp (report review and video) ”;
• “ Play with Docker - an online service for practical acquaintance with Docker ”;
• " Cheat Sheet with Docker teams ";
• " Overview of GUI Interfaces for Managing Docker Containers ."