Hacker News Reader

Comment by zwerdlds | Hacker News Reader

for anyone else interested in the actual stats, I grifted this from their pr on the image:

The minideb image currently weighs in at around 50MB uncompressed. For comparison the debian library image is 123MB, the alpine image is 5MB, and the newly released amazonlinuximage is 328MB.

View on HN

Current debian:stable-slim is 55.3MB and is already optimized for containers (see: https://gist.github.com/Zorbash/183b80d37bd0a09434e3a2b1a958...).

Good data point!

Anybody have experience with minideb vs. debian:stable-slim? Any pros/cons to either approach?

I can list some pros (comparing to debian:stable-slim) for Minideb: It is easy to build, has good documentation, has no blobs committed in the repo, is automatically built and tested on a daily basis.

Worth also mentioning it is the base image for ALL the Bitnami Containers that at the same time are also automatically built, updated and tested. You can take a look at all of them in Github. There are a ton of them

Once you do anything interesting (i.e. install Python) then Alpine and minideb size are basically identical

I guess it's a bit more specific than you meant it, but our standard Python image is ~20MB (alpine + python3, basically); that's still under half of minideb.

Does look interesting for things that need glibc compatibility though. There are some packages to help with that in Alpine but they only go so far.

Yep. I like alpine and use it for my images for preference, but some things like getting Ruby on Rails working with therubyracer can bascially hit a wall in alpine, so this could be pretty handy.

In my experience python in alpine is is sometimes 2x slower. How does ruby perform under Alpine?

Thanks, this is where I got the data from:

https://dzone.com/articles/minideb-a-minimalist-debian-based...

From looking at what I think is the Dockerfile for that image (https://github.com/docker-library/python/blob/b1512ead24c6b1...), that image is complex; it's downloading & building Python in it and adding & removing a dev toolchain, in a few different layers.

I'm not surprised that I got something a lot smaller from just running `apk add python3.6`, although as a result they are not comparing apples to apples; their minideb example does pretty much exactly the equivalent (i.e. downloading the distro-provided package, not compiling it within their image).

On the other hand if you don't need Python because it's a container running a service like Redis or Nginx you can keep entire Alpine-based image around 25-50% of the size or bare minideb image.

I know old school native code is looked down upon these days, but there are people that write code without bloated runtime dependencies.

You don’t need to add python “to do anything interesting.”

Your numbers are wrong. Here's the actual values for each of those images uncompressed:

    debian	101M
    alpine	4.1M
    amazonlinux	160M

These were determined with the following:

    for image in debian:latest alpine:latest amazonlinux:latest; do
        docker pull $image
        size=$(docker save $image | wc -c)
        echo "\n$image is $(echo $size | numfmt --to=iec)\n"
    done

Please note that it's important to only do this test with either a completely clean image store OR to save an exact sha256 image digest tag.

If you try to do a `docker save` on a store where you have multiple copies of an image, it's easy to mess up and save old layers too. I suspect that's what happened with your amazonlinux test above.

debian:stable-slim 56M

Sorry, not my numbers - as noted in the comment, I took them from the press release.

BusyBox image between 1-5mb.

Reply on news.ycombinator.com