Here is a docker scratch file:
ADD ca-certificates.crt /etc/ssl/certs/
ADD bin/HelloWorldOnce /HelloWorldOnce
Here is an acbuild script:
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
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:
- the app in the container is a database client. It connects to a remote and public database using a published DNS address.
- In order to get my application to connect to the DB using docker I needed to add the ca-certificates during the build.
- In order to get my application to connect to the DB using rkt I needed to add /etc/resolv.conf to the container.
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.