According to Itamar Turner-Trauring on Podcast.__init__[1] the issue with Alpine (at least in a Python context) is that the use of musl[2] instead of glibc (and I paraphrase) is an increased technical risk where corner cases that may not be as thoroughly tested are in view.
ITT counseled in favor of using containers based on ubuntu or centos.
I haven't done huge amounts of container work, but my light outings with Alpine have been fine. Maybe load and internationalization expose more personality in musl, or these concerns pertain to issues that have been fixed.
It's something to keep in mind when assessing risk.
I think of it as being like the "dash as /bin/sh" thing in Debian-derived distros. Software that's carefully done "by the book" or intended to be highly portable is unlikely to have a problem. But a lot of things depend on bash/glibc without anyone particularly intending or realizing it, simply because their sheer market share means that such dependencies will "just work" for the vast majority of users.
I had trouble installing basic packages like Sphinx (Py) due to some imaginary locking problem on the part of apk... and I couldn't find any info on how to make apk ignore the locks (or even just delete the locks, and then go on installing).
This was in container-world, so... a bit bizarre. It's very possible that I did something wrong or bizarre, but... that's of no consequence. Ubuntu/Debian works.
One issue is that they do not keep an archive of packages, and often you'll end up finding it really difficult to downgrade or use a different version that once existed.
