Yeah I thought the whole point of Alpine was that it abandoned the insanity of glibc for the relative sanity of musl.
My only guess is that they like Alpine but want to run some binary software that links with glibc.
My only guess is that they like Alpine but want to run some binary software that links with glibc.
Among this rather large crowd, Alpine is popular for just one reason: it's small, and dealing with large images is more annoying, everything else being equal. But alpine and, say, ubuntu, aren't always equal. Those people then find one of the ugliest differences, often related to musl, or something they are using relying on glibc-like behavior, and then get to choose between a hack like this, or much larger images.
As an example my organization was moving everything to alpine, but as part of the switch we found out that some computationally heavy tasks were getting significantly worse performance under alpine than with a glibc-based distro, mainly due to the relatively well documented issues with memory allocation performance. It'd not be surprising that someone finding themselves in this kind of situation ends up just adding glibc to alpine, instead of switching back, or figuring out how to tweak the memory allocator.
[side note] I seem to recall there being something about the the way the musl header files are written that basically throws a wrench into any scientific computing code that's compiled with it. Might have something to do with security like those checks intended to prevent people from overlapping memcpy so someone should totally fix that.
There's also gcompat for that, although I don't know how comprehensive that is
Performance in real world applications is worse on musl vs glibc, at a level that can result in higher latencies and needing to spend more on compute resources to serve a given level of load.