Hacker News Reader

Comment by TechBro8615 | Hacker News Reader

Slightly off-topic rant about musl in the context of Alpine Docker images:

It's cool that we have an alternative to glibc, and it's cool that the popularity of Alpine Docker base images has caused developers to put the effort into expanding compilation support to a wide range of binaries. But personally, I got sick of how many hours I spent debugging a seemingly endless train of binaries that would fail in strange ways when running under Alpine, or that just didn't run at all because they were compiled with glibc. So I gave up and switched to using Ubuntu as a base image and never looked back.

I've never even understood the obsession with minimizing base image size, because it's not like it gets loaded into memory, and the fact that it's a base image means you share it with multiple images anyway, so you rarely even need to download or upload the layer over the network.

View on HN

If you want to minimize inage size Alpine isn't the best choice anyway. Something like Distroless is usually a better choice.

> I've never even understood the obsession with minimizing base image size

In theory image size shouldn't matter because of Docker's caching. In practice, however, many of the things we use around Docker (CI/CD, testing, orchestration and deployment tools...) don't take advantage of that cache.

A GitLab CI stage to build my container will still pull the base image and build up from layer 1 every time. The subsequent testing stages will do the same with the final image. The deployment stage will also need to pull it first, just to push it to the registry again, but with a tag this time.

The difference between the base image being a few dozen vs a few hundred megabytes translates directly into not just how much strain I'm putting on the network, but how long the pipeline takes. If I can reduce that by essentially just swapping the base image and search-replacing apt-get with apk, why not? Of course it isn't always that simple, but for most things where you're just something like Node or Python with minimal native extensions, it's definitely worth it.

Also if your infrastructure is elastic, image size can cause significant delay to scale-up and instance startup. At large scales it adds up to wasted money on provisioned resources spending time downloading the images. Very noticable with some domains that have multi-GB images.

> I've never even understood the obsession with minimizing base image size, because it's not like it gets loaded into memory, and the fact that it's a base image means you share it with multiple images anyway, so you rarely even need to download or upload the layer over the network.

Isn’t it also the case that less “bloat” can mean less code that potentially leads to fewer bugs? Reducing bloat can have other benefits sometimes.

I really like Alpine for making vm images. It is extremely easy to make the VM only run in memory or in data disk mode where the code is in ram but the files are persisted to disk with snapshots

https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode

That sounds like an interesting use case and a valid time to be concerned with image size. It's the cargo-culting optimization of Docker base images that I'm complaining about.

It's a solved problem, use scratch, distroless, or buildpacks.

Reply on news.ycombinator.com