Static building, as mentioned by others, also works for Rust. Portier builds this way:

https://github.com/portier/portier-broker/blob/master/Docker...

This uses the awesome clux/muslrust Docker image as a build environment, then copies the result into a new ‘from scratch’ layer.

Yes.

Works great with Haskell statically compiled binaries. Running the binary through UPX i've managed to get small HTTP microservices down to a 2MB docker image with just Scratch.

Works just as well for Go binaries. It's pretty much the recommended base image for distribution of Go apps on Docker. I assume that it would be just as effective for any statically compiled binary.

Edit: I really should have read the article first. It uses Go binaries as the example. Good to know Haskell folks are also using it.

Massive downside: You run your app as root or you have to do nasty mounts of /etc/passwd and /etc/group from your host

You don't have to mount the host versions - you can create container-specific ones.

See https://medium.com/@lizrice/non-privileged-containers-based-...

You can run a Docker container as a particular user.

https://docs.docker.com/engine/reference/builder/#user

You can use `setcap` to grant capabilities to the binary or the `pam_cap` module if you need to do capabilities per user.

I haven't run across the need to run most containers as root for a while now.

Yup, in the end it´s an OS process and all rules apply. I did not care too much about Dockerfile best practices in my article. Good point, should at least have used "user <!root>".

I used FROM scratch to build a docker container for AppFS, which just has 2 files: init, and appfsd

http://appfs.rkeene.org/web/artifact/42acc0ed9e8f4327

init comes from: http://appfs.rkeene.org/web/artifact/ecb8eda1cfb32ecc

And just sets up some symlinks and starts appfsd, followed by running bash (which is cached and run transparently).

Thx! See me comment above on why you would want to put static binaries in "scratch", i.e. use "scratch" to deploy apps and not just for building base layers as you suggest.

You can however compose micro services with scratch

For example I created a cntlm base image (linked in another comment)

From there I can do

FROM my_base_image COPY whatever

and then add layers of services

first one is proxy

second one could be queue service (for example http://nsq.io)

then a message server, that just sends notifications

etc. etc. etc.

The same could be achieved downloading and configuring the static binaries, but Docker packaging, security and network separation makes evrything a little bit easier

I have a sidecar pod in kubernetes that runs "kubectl proxy" so the image just has the kubectl binary.

I use it as base image for docker-compose.