-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graal/native compiled spring cloud function for aws requires GLIBC at Runtime #972
Comments
I am also facing the same issue. It seem like AWS Lamda environment is using older of ldd (GNU libc) 2.26 while our build environment is using something much newer ldd (Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35 (Github action). I am thinking if we could use older ldd version to build the project or use something like customer layer to run the project and see if it's working? |
I have tried building the native image on Docker and upload it to AWS Lambda and it's working! @cforce, you may try run this docker image and then build the native image from the inside of the container and upload the file you got to AWS. Plz also change arm64v8 -> amd or sth as your environment. |
Yes, of course i could dockerize my complete build env, this way i am reimplementing a concept like buildpacks which brings setting up the build env out of the box by intension, however the spring-boot-maven plugins which does only comes with builder images based on recent images which won't fit to the execution runtime of aws lambda (being to far behind) Spring boot maven plugin uses buildpacks to provide build and runtime for native image compilation and execution in a docker image. The stack is a name for the build and run images. These are the base images for the builder and your application image. A builder is an image that contains three components:
The builder is the image that forms the container environment when you run the actual build. It includes the build image plus all the buildpacks. The stack provides a glibc . At build time, it's the build time and at run time, it's the run image. Below a list of used buildpacks which come out of the box with spring boot (>3.x)
libc vesions per env: docker run --interactive --tty --entrypoint /bin/sh amazon/aws-codebuild-local:latest
docker run --interactive --tty --entrypoint /bin/sh amazonlinux:2
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
docker run --interactive --tty --entrypoint /bin/sh bellsoft/liberica-runtime-container:jdk-17-stream-glibc-20221019
docker run --interactive --tty --entrypoint /bin/sh bellsoft/liberica-runtime-container:jdk-11-stream-glibc-20221019
The full list of builders: https://paketo.io/docs/reference/builders-reference/ It looks like aws lambda execution runtime is still based on glibc which comes with Ubuntu 18.04, while spring boot maveb builder already used 22.04 and a provides a glibc at runtime which is not compatible with the lambda glibc from execution runtime. So either
or
|
Closing it as it appears that it has nothing to do with spring-cloud-function |
OS: Linux
JDK: OpenJDK 17
Spring Boot: 3.0.0
Spring Cloud Function: 4.0.0-SNAPSHOT
Using todays (SNAPSHOT) graalvm-reachability-metadata
Step to reproduce:
Above GLIBC issue is not reproduceable locally by just executing the native compiled linux exe on ubuntu 22.04.
As i don't yet have a glue howto call the same function from e.g. cmd line instead via deployed lambda i can not rile out that it would also and only also happen when run my function triggered by an event like done on aws console.
I suspect that the Linux which is used as base for lambda is providing only GLIBC <2.32The aws lambda website mentioned above pretends to use this image to run amazon/amzn-ami-hvm-2018.03.0.20220802.0-x86_64-gp2 which I was not able to download yet somewhere but initial release year 2018 sounds pretty old. I found this docs for it
• https://aws.amazon.com/amazon-linux-ami/2018.03-release-notes/?nc1=h_ls
• https://aws.amazon.com/amazon-linux-ami/?nc1=h_ls
The last update seems to be some months ago and is Amazon Linux 2018.03.0.20220419.0
Updated Packages:
• glibc-2.17-324.189.amzn1.x86_64
I will try to build with amazonlinux and same or lower glibc version. However a buildpack which is sync with lambda execution environment ants its GLIBC versions where i can build a fully compatible lambda native executable without setting up own docker container would make sense especially for spring cloud function aws adapter.
Another approach would be to get independent of dynamic lib loading.
https://github.com/orgs/paketo-buildpacks/discussions/58#discussioncomment-4419519
The text was updated successfully, but these errors were encountered: