4 ms·

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

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.

nerdbaggy 3y ago
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 https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
- TechBro8615 3y ago
  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.
  - thraway23432 3y ago
    It's a solved problem, use scratch, distroless, or buildpacks.
dharmab 3y ago
If you want to minimize inage size Alpine isn't the best choice anyway. Something like Distroless is usually a better choice.
franga2000 3y ago
> 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.
- dharmab 3y ago
  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.
vogon_laureate 3y ago
> 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.

nerdbaggy 3y ago

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 https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode

TechBro8615 3y ago
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.
- thraway23432 3y ago
  It's a solved problem, use scratch, distroless, or buildpacks.

dharmab 3y ago

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

franga2000 3y ago

> 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.

dharmab 3y ago
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.

vogon_laureate 3y ago

> 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.