| > why are Alpine docker images a dead end? That's the most controversial thing at work too. It comes up so often because it is a measurably good idea when you look at container sizes or startup times (gzip is terrible, terrible way to package container images). An engineer tries it out, it works great and it does because alpine is lean, fast and generally good. I work on performance, so any decision to make things slower gets routed through my desk - the perf buck stops at my desk. Now it's my thankless job to squash out her initiative and as gently as possible (there are lots of smart people in the industry, but being kind has a better ROI), so that it is not a "this is policy" form letter appeal to authority, but walk them through the entire list of tickets in my notes. Because we hit a bunch of SEGVs with the JVM and the JDK team basically closes them as WONTFIX when reported. And this sort of decision has a shelf life, I can be right for 18 months and wrong the week after - so this is not a hard line. This specific thing is definitely not a permanent thing, but a temporary headache - the JDK team is working on Portola and that'll fix any issues they had. https://openjdk.java.net/projects/portola/ If you're going to install glibc as a workaround then you're basically giving up the space savings anyway. We still break things in production, but counterintuitively I'm the happier when the problem is bang in the middle of code I can commit to, rather than deep inside musl -> jdk interactions on what happens with a longjmp on a SIGSEGV. Also the turnaround for the CVE reported was much faster across teams if everyone picked the exact same base image - standardizing on Redhat Universal Base worked out (& also AquaSec scans etc is easier if 6 different products have the same image down there). Amazon Corretto does have alpine images, so this is sort of a 2020 advice with rapidly declining value (I'm funemployed for 2022, so my current "weakly held" opinions are entirely about rust syntax). |