search

GoogleContainerTools / distroless

🥑 Language focused docker images, minus the operating system.
Apache License 2.0
18.17k stars 1.11k forks source link

Request for Distroless Image Supporting GLIBC-2.39 #1618

Open albertxos opened 5 days ago

albertxos commented 5 days ago

Hello Distroless Team,

I am currently working on a project that heavily relies on the Distroless images for deploying lightweight containers. Our application, specifically requires GLIBC version 2.39 to run properly. However, we've encountered compatibility issues due to the GLIBC version available in the current Distroless images.

Given the importance of GLIBC for many applications and the potential for similar issues across various projects, I kindly request the addition of a Distroless image variant that includes support for GLIBC-2.39. This update would greatly benefit not only our project but also other developers facing similar challenges.

The need arose when deploying our Rust application using the gcr.io/distroless/cc-debian12 image. We encountered runtime errors indicating that the required GLIBC version (2.39) was not found. This version mismatch prevents our application from running in the desired lightweight and secure environment that Distroless images provide.

We appreciate the effort and dedication that goes into maintaining these images and understand that supporting a new GLIBC version might require careful consideration and testing. Nonetheless, we believe that updating the GLIBC version could enhance the compatibility and usability of Distroless images for a wider range of applications.

Thank you for considering this request. We look forward to any updates or suggestions on how we might work around this issue in the meantime.

Best regards, Albert

loosebazooka commented 5 days ago

We follow debian to keep our maintenance burden minimal. So a glibc version upgrade is probably unlikely until debian13 (2025 sometime?). I believe canonical and chainguard might have some options for you especially if you're looking for commercial support.

You can continue to use a debian based base image if you like by trying rules_distroless to build it on your own using bazel?

albertxos commented 5 days ago

After further investigation and experimentation, I've identified a workaround for the GLIBC version discrepancy issue encountered with our application in the Distroless container environment. The core of the problem lies in the mismatch between the GLIBC version available in our devcontainer environment and the version present in the gcr.io/distroless/cc-debian12 image, which is older.

Here are the approaches considered and the chosen workaround:

  1. Downgrade the Devcontainer Environment: Align the devcontainer GLIBC version with that of debian12 by downgrading. This ensures compatibility but may not be feasible or desirable due to the dependencies of other applications or development tools that require a newer GLIBC version.

  2. Build our application Directly from the Dockerfile: Instead of copying the built our application from the devcontainer build environment, we can modify the Dockerfile to build our application directly within the context of the Docker build process. This ensures that our application is compiled against the GLIBC version available in the build environment, matching the Distroless image's GLIBC version. While this approach increases the build workload and potentially duplicates efforts in the DevOps pipeline, it guarantees compatibility without waiting for external updates.

  3. Wait for Distroless to Support GLIBC-2.39: Submitting an issue to the Distroless project and waiting for an update that includes GLIBC-2.39 is another option. However, this depends on the project's update timeline and may not be a viable short-term solution.

Chosen Workaround: We decided to go with the second option: modifying our Dockerfile to build our application directly within the Docker build process. This decision was made to ensure immediate compatibility and control over the build environment without the need to downgrade our development tools or wait for external updates. It does increase our build workload, but it's a trade-off we're willing to accept for ensuring that our application runs smoothly in our Distroless container environment.

This workaround may be revisited in the future as external dependencies and environments evolve. For now, it offers a viable path forward for our project.

I hope this insight helps others facing similar issues. Adjusting the build process to align with the target runtime environment can often resolve such compatibility challenges.