Hacker News Reader

Comment by dharmab | Hacker News Reader

> If you have one image based on Ubuntu in your stack, you may as well base them all on Ubuntu, because you only need to download (and store!) the common base image once

This is only true if your infrastructure is static. If your infrastructure is highly elastic, image size has an impact on your time to scale up. A great example is using spot instances; in my line of work we need to create thousands of spot instances to run many millions of time-sensitive batch jobs at certain times and dates, then scale those instances down rapidly to reduce the bill.

Of course, there are better choices than Alpine to optimize image size. Distroless (https://github.com/GoogleContainerTools/distroless) is a good example.

View on HN

That's true. But the size difference between alpine and debian:*-slim (for example) is on the order of < 20mb. Datacenter hardware can download this in milliseconds. There may be some rare scenarios where this is a meaningful delay, but usually provisioning time is bottlenecked somewhere else. Heck, it probably takes longer to download the VM image (and if you're optimizing for provisioning speed, you shouldn't be downloading Docker images on boot anyway - you should be baking VM images ahead of time.)

Baking the VM images trades a lot of flexibility for some latency, and it doesn't apply to container-as-a-service infrastructure where you don't control the VM. My point is you can get most of the way there with slim/distroless without making the tradeoffs of Alpine, and that's probably enough for most use cases.

> But the size difference between alpine and debian:-slim (for example) is on the order of < 20mb.
compressed size(amd64): 17.59MB vs. 45.35MB ( > 2.5x ) uncompressed size(amd64):52.00MB vs. 130.00MB ( > 2.5x ) $ docker images python:3.12.1* REPOSITORY TAG IMAGE ID CREATED SIZE python 3.12.1-alpine3.19 0108959914c2 2 weeks ago 51.7MB python 3.12.1-slim-bookworm 7c5c05471c3a 2 weeks ago 130MB**

There is no difference in download time for 20mb vs 50mb in a datacenter, but the amount of time lost to alpine being "quirky" is incalculable.

The compressed size is what matters when discussing image download time- CPUs made after around 2010 can uncompress files ludicrously quickly.

Those are Python images.

The base Debian slim image [0] is 28mb, compared to 3mb from Alpine [1]. So that's a difference of 25mb, or "on the order of 20mb." A machine in the datacenter will probably spend more time opening the connection to the registry than it will downloading that extra 25mb.

[0] https://hub.docker.com/_/debian/tags

[1] https://hub.docker.com/_/alpine/tags

and check the "VULNERABILITIES"

   bookworm-slim : 0H 0M 19L VULNERABILITIES
   alpine 3.19.0 : No Vulnerabilities Found

   python:3.12.1-slim-bookworm : 0H 1M 22L  VULNERABILITIES 
   python:3.12.1-alpine3.19    : 0H 1M  0L  VULNERABILITIES

Distroless is Debian packages with worse security and without package management.

> without package management.

distroless is for the TERMINAL layer, you should already be done with the package manager prior to entering distroless.

Reply on news.ycombinator.com