Since it's not using a multi-stage build, go dev tools are clogging up the image, losing the benefit of using alpine in the first place.

https://link.medium.com/S2z0PtVHQ1

If you're just running a go binary you can use distroless as the base for even smaller images.

Thanks for linking this. Will implement.

Also like the "tags" within the dockerfile for dev and prod - much cleaner than the multi-file solution currently in the repo.

I hadn't heard this before, also sold by small image sizes. What is the big performance weakness of mscl vs glibc?

Anything beyond binary size vs shared pages?

glibc has thread-local pools for malloc, afaik musl uses locks.

I'm very weak when it comes to stuff at this level but this sounds like it might be something I really want to know. If I want to run Python or Ruby, what is the practical downside to Alpine? Am I understanding correctly that Python or Ruby interpreters built to run on Alpine use musl instead of glibc, and that might have very noticeable performance impacts?

This thread is opening my eyes, I kind of assumed as long as I was running the right version of those interpreters, I was getting more or less the same thing. That feels like a very bad assumption now.

As always when it comes to performance, you should measure the difference yourself and see if it's a switch worth doing for your use case. "very noticeable performance impacts" depends so much on the context that it's hard to answer in a general way.

> also sold by small image sizes.

Out of curiosity, what sold you on this? Has caching of a docker image been considered in this conclusion as well?

I was just a casual local user, and didn't have any production use of it. At the time, if my memory serves, images easily got into many GB locally. This was before Ubuntu and others had produced smaller official images of their own.

Alpine has problems with its network stack that make it unsuitable for use in some contexts.

Footprint (ie. of the built container image which must be transferred back and forth to repos) and runtime performance are two different things you may care to optimize differently or not.

Thanks - will update the prod recipe.

I saved hundreds of MB on the front-end images switching to alpine so I want a little alpine crazy :)

Performance of what? Building an image?

Runtime performance. Musl has different performance characteristics to glibc (glibc uses thread-local pools for malloc, while musl uses locks).

> Starting with 1.1.9, musl’s dlerror state is thread-local and now matches the glibc behavior.

https://wiki.musl-libc.org/functional-differences-from-glibc...

dlerror is entirely irrelevant here.

In terms of what? Performance? Musl is more correct. Most people aren't serving Google or Facebook levels of requests. My only issue is with people choosing software purely based on performance.

No, it's just that dlerror and malloc are two different functions.

I think that's self-evident, thank you.

musl libc has been robust and fast in my experience. What performance issues have you encountered?