Add Alpine compatibility

[nil-malh]

Alpine Compatibility: Static Linking with musl libc

Issue

When running the kafkactl native-image in Alpine Docker containers, it produces segmentation faults due to symbol incompatibilities between glibc and musl:

/# kafkactl
Error relocating /usr/local/bin/kafkactl: __strdup: symbol not found
Error relocating /usr/local/bin/kafkactl: __strtok_r: symbol not found
Error relocating /usr/local/bin/kafkactl: __isnan: symbol not found
Error relocating /usr/local/bin/kafkactl: __isnanf: symbol not found
Segmentation fault

Solution

This PR modifies our build process to create statically linked binaries with musl libc for Linux builds. This allows our application to run correctly in Alpine and other musl-based environments.

Specifically:

1. Updated GitHub Actions workflows to install the correct musl cross-compiler (version 10.2.1) for Linux builds
2. Modified the build commands to use --static --libc=musl options with GraalVM's native-image
3. Configured proper toolchain paths with --gcc-toolchain=/usr/local/musl/x86_64-linux-musl-native

Changes

• Updated Release workflow for static musl builds on Linux
• Updated Pull Request workflow for static musl builds on Linux
• Updated Push Main workflow for static musl builds on Linux
• Added environment variable configuration to ensure proper compiler usage

Testing

The changes have been tested by building the application and running it in an Alpine container to verify that the segmentation faults no longer occur.

References

• Fixes Kafkactl cannot be executed in a Alpine Docker image #129
• GraalVM documentation on static linking: https://www.graalvm.org/latest/reference-manual/native-image/guides/build-static-executables/
• Related musl compatibility issue in GraalVM: Static linking using musl doesn't work oracle/graal#4076

[loicgreffier]

@nil-malh Build is currently failing for Windows and MacOS. I think it is related to buildArgs.add("--static") and buildArgs.add("--libc=musl") from the build.gradle, isn't it?

Args are already defined in GitHub Actions: gradlew nativeCompile -PnativeArgs="--static --libc=musl --gcc-toolchain=/usr/local/musl/x86_64-linux-musl-native"

Do we need to have them in the build.gradle?

[loicgreffier]

@nil-malh Note that starting from Alpine v3.13, after installing apk add gcompat, I don't have issue running Kafkactl:

/test # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.12
PRETTY_NAME="Alpine Linux v3.13"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

/test # ./kafkactl-1.14.0-linux-amd64 -V
Version 1.14.0

[nil-malh]

Args are already defined in GitHub Actions: gradlew nativeCompile -PnativeArgs="--static --libc=musl --gcc-toolchain=/usr/local/musl/x86_64-linux-musl-native"

Do we need to have them in the build.gradle?

Absolutely it was some leftovers from my testing on my machine I'll remove it from the build.gradle :).

[nil-malh]

@nil-malh Note that starting from Alpine v3.13, after installing apk add gcompat, I don't have issue running Kafkactl:

Thanks for bringing this up ! I was unaware of gcompat thanks !
Regarding our approach, I believe both options are valid :

1. Native musl binary: Provides the best performance and alignment with Alpine's philosophy. It eliminates dependencies to the C library not matter the implementation. But changes the way we build Kafkactl at the moment.

2. Gcompat approach: Offers simplicity for users - they just install gcompat and run our existing binary. This is more pragmatic for users who may not be Alpine experts, though it adds runtime overhead and extra dependencies.

What do you want to do going forward ?

[loicgreffier]

@nil-malh It’s always better if the CLI works out of the box without additional installation. However I need to do some tests and answer the following questions:

• What is the cost of embedding Musl: how many additional KiB, MiB in the CLI
• With Musl embedded, does it still work fine on Ubuntu LTS (20, 22, 24) or would be need to provide an additional version of Kafkactl like kafkactl-1.14.0-linux-musl-amd64

[nil-malh]

• What is the cost of embedding Musl: how many additional KiB, MiB in the CLI
  The size impact of embedding Musl in the CLI is remarkably small - we're talking about an additional footprint of just a few hundred KiB in most cases. Musl is specifically designed to be lightweight and efficient

On the latest version of Kafkactl at date 0.14.0 : non musl-c : 87mb with muslc : 87.35mb

• With Musl embedded, does it still work fine on Ubuntu LTS (20, 22, 24) or would be need to provide an additional version of Kafkactl like kafkactl-1.14.0-linux-musl-amd64

AFAIK, I am currently using a static build of Kafkactl inside my Ubuntu WSL and I don't have any issues at all !

[loicgreffier]

@nil-malh

I've tested static linking to Musl on latest Alpine, latest Debian, latest Ubuntu, Ubuntu 22.04 LTS and Ubuntu 20.04 LTS. Looks good.

I've open #203 to guide you through my following suggestions:

• Our GraalVM GitHub Action can magically install Musl (Cf. https://github.com/marketplace/actions/github-action-for-graalvm#options native-image-musl option). Thus, we can omit the manual installation steps. It has to be activated only on Linux runners.
• Unless I miss something, the -PnativeArgs= option seems not working. I've set buildArgs in the build.gradle, conditioned by a property. Looks good and easier to run static Musl build on localhost.

I think we can keep providing a single Kafkactl, statically linked to Musl. Some other apps are doing this as well which confirms my decision.

👉 I let you do a first update of your PR

@ThomasCAI-mlv We might need to discuss about moving to Alpine:

kafkactl/build.gradle

Line 89 in 71582bb

baseImage("ubuntu:22.04")

(@nil-malh ignore this is this PR for now)