3 ms·

> AIUI that's only helps if everything uses exactly the same base image. Every time the base image gets updated, your images will diverge as they're rebuilt. Y

> AIUI that's only helps if everything uses exactly the same base image. Every time the base image gets updated, your images will diverge as they're rebuilt. Yes this is true. In our stack we pin all base images to a common hash, which makes builds fast and also increases reliability of CI pipelines since we don't get unexpected changes to builds. The tradeoff is you need to be deliberate about updating the pinned image with new security patches, but this feature is available out-of-the-box with update bots like Renovate. > the problems never materialized What about every hour you spent recompiling binaries to make them work with musl? That's what I meant by maintenance cost - every time you add a new binary into your minimalist image regime, you need to either pay the cost of making it work with musl, or abandon the effort, effectively nullifying the benefits of your other images using Alpine (since once you have one image based on a larger base image, you may as well base them all on it). This is a kind of Stockholm Syndrome where the cargo-culted optimization becomes forever embedded in your software requirements even when the options may have changed (for example, once debian-slim was introduced, there was little reason to continue using Alpine).

yjftsjthsd-h 3y ago
> What about every hour you spent recompiling binaries to make them work with musl? We were a mostly non-Python shop, and what Python images we did use, IIRC, either 1. didn't use libraries with native code so not a problem, 2. just `apk add`ed the Alpine-provided libraries, or 2. just used the Debian based image for that particular image. I will grant that if you're working in a Python-heavy environment the calculus is likely different. > That's what I meant by maintenance cost - every time you add a new binary into your minimalist image regime, you need to either pay the cost of making it work with musl, or abandon the effort, effectively nullifying the benefits of your other images using Alpine (since once you have one image based on a larger base image, you may as well base them all on it). IME it just wasn't that much cost, and it dropped off even more once musl wheels started becoming normal. And we had enough churn in images that basing everything on ex. a single static version of Debian was 1. never going to happen, and 2. wouldn't have reduced our image sizes since the base image wasn't constant anyways. > This is a kind of Stockholm Syndrome where the cargo-culted optimization becomes forever embedded in your software requirements even when the options may have changed Or, it's a perfectly reasonable rule of thumb and if actual evidence shows that something else is better you can pick it up then. I mean, the same thing goes in reverse, right? You've cargo culted "Alpine slow" and have embedded that in your stack even though the reasons for it no longer exist. > (for example, once debian-slim was introduced, there was little reason to continue using Alpine). Alpine is still smaller. Debian shipping slim images reduced the gap, but it's still there, and installing packages will exacerbate it (since Alpine packages also seem to be smaller than the Debian equivalents.

yjftsjthsd-h 3y ago

> What about every hour you spent recompiling binaries to make them work with musl? We were a mostly non-Python shop, and what Python images we did use, IIRC, either 1. didn't use libraries with native code so not a problem, 2. just `apk add`ed the Alpine-provided libraries, or 2. just used the Debian based image for that particular image. I will grant that if you're working in a Python-heavy environment the calculus is likely different. > That's what I meant by maintenance cost - every time you add a new binary into your minimalist image regime, you need to either pay the cost of making it work with musl, or abandon the effort, effectively nullifying the benefits of your other images using Alpine (since once you have one image based on a larger base image, you may as well base them all on it). IME it just wasn't that much cost, and it dropped off even more once musl wheels started becoming normal. And we had enough churn in images that basing everything on ex. a single static version of Debian was 1. never going to happen, and 2. wouldn't have reduced our image sizes since the base image wasn't constant anyways. > This is a kind of Stockholm Syndrome where the cargo-culted optimization becomes forever embedded in your software requirements even when the options may have changed Or, it's a perfectly reasonable rule of thumb and if actual evidence shows that something else is better you can pick it up then. I mean, the same thing goes in reverse, right? You've cargo culted "Alpine slow" and have embedded that in your stack even though the reasons for it no longer exist. > (for example, once debian-slim was introduced, there was little reason to continue using Alpine). Alpine is still smaller. Debian shipping slim images reduced the gap, but it's still there, and installing packages will exacerbate it (since Alpine packages also seem to be smaller than the Debian equivalents.