aws / aws-lambda-base-images

Apache License 2.0
647 stars 107 forks source link

AL 2023 support #92

Open GrahamCampbell opened 1 year ago

GrahamCampbell commented 1 year ago

Is Amazon Linux 2023 coming to Lambda? Is there a roadmap for this?

jayeye commented 1 year ago

Example of needed feature: the library and list of magic file numbers is way out of date; it thinks that a .docx file is really a zip file!

tmokmss commented 11 months ago

We need this; the bundled glibc is too old and some libraries does not work unless glibc is upgraded.

jtuliani commented 9 months ago

Today, we have published a preview AWS Lambda base container image for AL2023, named ‘provided.al2023’. You can use this image to build and deploy your Lambda functions using AL2023-based containers.

This image is tagged ‘preview’ and should not be used for production workloads. We invite you to provide your feedback on this preview image below. We are working on GA support for AL2023 in Lambda, as both a base container image and a managed runtime. This is scheduled to ship in the coming weeks.

The provided.al2023 is based on the AL2023-minimal image, which is available in public Amazon Linux ECR. It is a version of AL2023 containing the only essential components necessary to install other packages. In particular, it uses microdnf as the package manager (AL2023 replaces yum with dnf; AL2023-minimal uses a special version of dnf called microdnf, and dnf is a symlink for microdnf). Also, curl and gnupg2 are included as their minimal versions, curl-minimal and gnupg2-minimal.

The AL2023 image includes glibc version 2.34 (previously, version 2.26 was included in provided.al2).

Going forward, the provided.al2023 image will be used as the base for future runtime releases, including Node.js 20, Python 3.12, Java 21 and .NET 8.

piercefreeman commented 9 months ago

@jtuliani Thanks for all the work that's going on to support AL2023 in lambda, I know it's been a long road!

Does AWS treat these provided base images uniquely with any sort of internal caching or env warming? I'm judging from this analysis where generically speaking containers boot in 0.5s-1.25s whereas a vanilla function on a managed runtime are usually more like 0.25-0.6s. If we're trying to minimize bootup times, would we be advised to wait for the GA managed runtime?

GrahamCampbell commented 7 months ago

I can see that SDK support for AL 2023 on Lambda is now available.