search

lambci / docker-lambda

Docker images and test runners that replicate the live AWS Lambda environment
MIT License
5.83k stars 431 forks source link

Usage of Docker Tags for Runtime Versioning #191

Closed metaskills closed 4 years ago

metaskills commented 5 years ago

During the recent upgrade for the execution environments (https://aws.amazon.com/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/) we noticed that would could not make a deterministic update because tags here are used for languages (https://hub.docker.com/r/lambci/lambda/tags) and not for versions of the execution environment. This means that once a new Docker image is pushed new local or CI builds will use that container.

Have y'all considered using extended tag names to help version containers' execution environment version? Also, I am not sure if this issue should be filed with AWS SAM CLI project or here?

mhart commented 5 years ago

This is definitely something that's been on my mind as AWS has made larger and larger changes to the execution environments over time.

Would likely require some coordination with the SAM team if such functionality were to be exposed through the CLI. Although I think they support specifying your own docker image, so that might suffice.

I think the main issue would be knowing when to bump the tag and when not to – the execution environments actually change quite regularly (eg, SDK / boto updates) and it'd be (arguably) risky for ppl to be stuck on an old dated tag without knowing there's a new one that reflects the latest runtime.

This is the first time Lambda has had two simultaneous choices via the layers mechanism, so that's a bit of a new one. It might suffice to just update tags whenever they do a change as large as this, where there's an opt-in period, etc.

Definitely something to consider, I'll keep this open until I've got a good resolution

metaskills commented 5 years ago

I think the main issue would be knowing when to bump the tag and when not to the execution environments actually change quite regularly

Fair point. If done, I would imagine that small updates like boto would be ignored and larger things like removal of ImageMagic, Ghostscript, or Linux runtime would be tagged.

It might suffice to just update tags whenever they do a change as large

Yea... like maybe there would have been a temporary 1803-ruby2.5 till it was rolled out and then that would get rolled into ruby2.5.

mhart commented 4 years ago

I've started doing this for large refactors - eg the most recent move to allow containers to "stay-open"

All the old runtimes were tagged with 20191117-<runtime>, eg lambci/lambda:20191117-dotnetcore2.1 so that people could switch back to that tag if they run into problems with the images.