4 ms·

Specifically in container space, when I chatted with other developers regarding reasons of choosing Alpine, the top one answer is the size of the base image com

by zzyzxd 5y ago

Specifically in container space, when I chatted with other developers regarding reasons of choosing Alpine, the top one answer is the size of the base image comparing to other popular Linux distro images like Ubuntu or Debian. Smaller size => faster rollout + minimal CVE exposure, right? What I feel fundamentally wrong about this is, in many cases they probably shouldn't put a full OS in a container in the first place. Take Google's distroless as an example, if you only put necessary stuff in your container, even a debian based image can be reasonably small enough that you never need to worry about image size. Also, dealing with DNS issues in Alpine based containers (which was caused by musl implementation, iirc) was one of my biggest nightmare at work. Just search for "Alpine+DNS" on Google and you can see what a mess it had brought.

stonogo 5y ago
I think these points aren't really fair, since Alpine predates a lot of the work that went into making the alternatives possible. Alpine predates Distroless by over a decade, for example. As for DNS, it's extremely unfair to blame musl for properly implementing the POSIX standards for name resolution. It's not Alpine's fault that so many people wrote software which explicitly depended on specific glibc quirks. If anything, it's a good lesson on the dangers of monocultures, and how even FOSS software is at risk.
- zzyzxd 5y ago
  I agree with you that it is not Alpine's fault for not being as good as today's Distroless 10 years ago. In fact it is still my favorite tool for several use cases (e.g., injecting a sidecar container for adhoc debugging). What I was trying to say, was that many people choose it for wrong reasons without fully understanding the implications. This included us. It was a nightmare to me because at that time I didn't know it has different behavior in DNS resolution. And our developers expected their code, which ran fine on their workstations and in CI (Ubuntu/Debian environments), to behavior the same when running in an alpine container in production.

by zzyzxd 5y ago

stonogo 5y ago

I think these points aren't really fair, since Alpine predates a lot of the work that went into making the alternatives possible. Alpine predates Distroless by over a decade, for example. As for DNS, it's extremely unfair to blame musl for properly implementing the POSIX standards for name resolution. It's not Alpine's fault that so many people wrote software which explicitly depended on specific glibc quirks. If anything, it's a good lesson on the dangers of monocultures, and how even FOSS software is at risk.

zzyzxd 5y ago
I agree with you that it is not Alpine's fault for not being as good as today's Distroless 10 years ago. In fact it is still my favorite tool for several use cases (e.g., injecting a sidecar container for adhoc debugging). What I was trying to say, was that many people choose it for wrong reasons without fully understanding the implications. This included us. It was a nightmare to me because at that time I didn't know it has different behavior in DNS resolution. And our developers expected their code, which ran fine on their workstations and in CI (Ubuntu/Debian environments), to behavior the same when running in an alpine container in production.