Richard Bucker

scratch containers

Posted at — Nov 20, 2015

I’m going to keep this real short. A scratch container is a base image that has nothing in it. It’s effectively an empty file. Both Docker and rkt have scratch-like base images.

Here is a docker scratch file:

FROM scratch
ADD ca-certificates.crt /etc/ssl/certs/
ADD bin/HelloWorldOnce /HelloWorldOnce
CMD [“/HelloWorldOnce”]


Here is an acbuild script:

acbuild begin 
acbuild set-name myreg/helloworldonce
acbuild copy bin/HelloWorldOnce /bin/HelloWorldOnce
acbuild copy ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
acbuild copy resolv.conf /etc/resolv.conf
acbuild set-exec /bin/HelloWorldOnce
#acbuild port add www tcp 5000
acbuild label add version 0.0.1
acbuild label add arch amd64
acbuild label add os linux
acbuild annotation add authors “Richard  <richard@……net>“
acbuild write –overwrite HelloWorldOnce-0.0.1-linux-amd64.aci
acbuild end


Why scratch? (see minimal containers and docker scratch official image) And for comparison read the bullshit justification for the Phusion baseimages.

I have long-since forgotten the official story but as memory serves the container developers that I know have endorsed statically linked applications running in a minimal container; like scratch. There are a few reasons that jump out at me. The first is fewer moving parts and so less heat. 2nd fewer dependencies if any. Finally; with fewer moving parts there are fewer attack vectors. For example if there is no ssh server in the container then one cannot attack the container through ssh.

Here are some notes that I discovered as I was trying to get parity between my docker and rkt containers:

I suppose I could have mounted the the host’s resolv.conf volume in rkt but that might create different issues. By putting /etcd/resolv.conf in the container it cannot be spoofed at that level.