Deepfactor intercepts libc (C Standard Library) functions in your running application. Two popular implementations of libc are glibc and musl libc. glibc is used in most linux distributions such as Ubuntu, CentOS, SUSE etc, where Alpine base images use musl libc.
You can read about musl libc and the differences between the two implementations in the following articles
musl libc – Functional differences from glibc
Based on the container image OS distribution, Deepfactor injects the right interception code compatible with glibc or musl into your container. Glibc and musl require a different version of the Deepfactor interception library. However, there are scenarios where your container may have both glibc and musl implementations of libc.
Example: You are launching a java[1] spring boot application in your alpine container using a script. In this case, the shell will use the musl libc present on the OS, but java spring boot application uses glibc which is packaged along with the application.
In order to address such scenarios, we have built in an auto detection mechanism.
For containerized workloads, if the libc required by the entrypoint does not match the OS distribution libc then it can be specified with the following instructions
- Docker workloads
Add the –entrypoint-libc “glibc” or “musl” option in the dfctl run command - Kubernetes workload
Add the annotation df.k8-app.entrypoint.libc: “glibc” or “musl” in your pod spec
OR
Enable the Webhook image manifest and entrypoint analysis service.
See 5. Tech Preview: Namespace Instrumentation
[1] – There are java-glibc and java-musl openjdk apk packages for alpine. A java-musl openjdk in alpine does not require enabling Deepfactor automatic multilibc support.