Installing chromium on alpine3.18 gocd docker agent causes crash loop about gocd HOT 3 CLOSED

If you are trying to install more complex native dependencies (such as browsers) onto your agent images, I'd strongly recommend you choose anything but Alpine. In short, this is because the GoCD agent images currently mix musl libc and glib in ways that are typically a Bad Idea and create problems like this. The saga is more completely summarised at #11355 because it also prevents us producing arm images for Alpine right now.

As a result I am contemplating abandoning Alpine images altogether and choosing another "compact" base image which is glibc-based.

Anyway, back to your actual problem.

It's quite possible that the problem is caused as a result of the chromium install adding eudev-libs (3.2.11-r8). What is likely happening is that the agent is loading a native library (OSHI) which looks for udev as part of collecting limited information on the OS/hardware of the agent. If OSHI finds udev, it tries to load it. Due to the constraints in the linked issue, the JRE is running via a glibc build in a way that is not normal for Alpine. udev is loaded from a musl libc linked library. Bang.

Anyway, for the earlier DIND image, the workaround was essentially to forcibly remove udev to workaround this. While that was fine for the usage of Docker within GoCD, I've no idea how Chromium relies on it or what might happen.

I'd suggest you can try and remove it, then see if the GoCD Agent starts. if it does, see if Chromium still works. If this all sounds a bit horrifying, use a non Alpine agent image (Debian, Ubuntu, CentOS), or create your own

from gocd.

Thanks @chadlwilson - I did run into further problems with software building on the alpine agent even after it started using alpine3.17 so reverted back to using ubuntu already

Happy to close this issue unless you think there's further work off the back of it..?

from gocd.

The maintainer of the library that is loading udev here seems open to adding a software level opt-out which I’ve raised at oshi/oshi#2562 so I’ll keep this open unless that one is rejected. Would be better than my hack of rming libudev for the existing DIND images anyway.

Still can’t guarantee that it’d leave the Alpine image in a fundamentally stable state for running arbitrary apk-installed software as part of builds, but at least would leave the GoCD-agent better protected in the short term.

from gocd.