Hacker News Reader

Comment by avian | Hacker News Reader

Another example of a really small container that doesn't do much, but is made without using assembly directly is the Docker "hello-world". It's built from C without linking in libc:

https://github.com/docker-library/hello-world/blob/master/he...

I always thought this was a bit misleading. A "hello world" container is 1 kB, but the bare minimum container that does something useful in practice is rarely less than 100 MB in size.

View on HN

If you base off alpine, you can get useful containers quite a lot smaller than 100MB.

One example i use is an agent i deploy to kubernetes clusters to do some security scanning. The scripts are ruby and the image clocks in at 9MB compressed https://hub.docker.com/r/raesene/kaa-agent/tags/

Yes, I use Alpine for a lot of my other containers. I love the simplicity of the package manager as well.

Alpine's package manager has the great property that you don't need to update the index in order to fetch a package IIRC; the whole `apt-get update && apt-get install && <cleanup apt-cache>` dance is quite tedious in debian-based Docker containers.

No, you still need to, but there's a compact syntax for it that will update and discard the index in a single 'add' command. It's unavoidable - somewhere some querying is happening in order map the package name/ver to a download link.

I find the haproxy (alpine) Dockerfile a great example on how to tender to container file-size. It uses the syntax you're referring to, temporary build virtuals (should be multistage today I guess) and static linking: https://github.com/docker-library/haproxy/blob/2d393f2b59824...

Awesome example, thanks. We've been starting using different Dockerfiles for prod and dev. For prod we want tiny images, but for dev the caching of layers is more important for frequent rebuilds. Such balance all the time :sigh:

On the same note I did a mariadb container that is ~12mb: https://hub.docker.com/r/jbergstroem/mariadb-alpine/

If you're into go, it's not too hard to get very small (<5mb) shippables by statically compiling against musl and using upx. Here's a somewhat scrubbed Dockerfile for a gRPC/rest service I use at work: https://gist.github.com/jbergstroem/680cb7db6f90319dcd7666f3...

5mb still sounds like a lot, considering you could squeeze Linux 1.3 on a 1.44 mb floppy with a (compressed) rootfs... I mean does the runtime really do that much more than a full (although old) os kernel and a C library/runtime and apps?

The entirety of Debian 0.97 (kernel, userspace, packages) fit on two floppies back in 1994 :P

For that I reckon you'd have to file a bug with golang.

Well you can throw static builds of useful go programs which can very well be smaller than 100MB on docker scratch images. :)

> but the bare minimum container that does something useful in practice is rarely less than 100 MB in size.

I’ve made containers using code written in most common programming languages (python/go/ruby/c/rust/heck even PHP/etc) which were easily under 100mb, most significantly less. If your containers are frequently >100mb, I say you’re either using the JVM or are doing it wrong!

Actually, even the entire JVM is below 60MB without Jigsaw, with Jigsaw it can go as low as 10MB

Yeah, I can easily make JVM containers under 100mb too usually, but it’s not always that small, so I wanted to give a little benefit of the doubt there.

Interesting. I must confess, I didn't realize there was a way to make syscalls directly from C without resorting to inline assembly.

Reply on news.ycombinator.com