Open joshtriplett opened 3 days ago
Thanks @joshtriplett. That's an interesting request. We'd like to understand your motivation better. What advantage/benefit would this bring you? What problem are you trying to solve?
Also, would you need certificates to be included in the runtime, or would you also bundle those with the binary?
@jtuliani My bootstrap
is a statically linked Rust binary, and has zero dependencies on anything on the system. I'd like to keep it self-contained, and ensure that it can't possibly have any unexpected dependencies on anything installed. (This would also simplify migrations when al2025 arrives.)
I'd also like to minimize cold start time, by not loading anything that isn't needed (e.g. the libraries needed to run a /bin/sh
script, or the dynamic linker). The entire cold start time is currently ~14ms, and a substantial fraction of that comes from things like the dynamic linker.
I would not expect certificates or anything else to be included in the runtime; my bootstrap
would include the certificates it needs.
Effectively, the only things in the image should be the bare minimum rapid
needs, the contents of the user-provided zip, and the mount points for mounted filesystems and bind mounts.
(I'm leaving out the perhaps-someday-wishlist item of being able to bring-your-own-rapid
. :) )
For self-contained binaries that need no runtime environment whatsoever, please consider providing a
provided.empty
runtime, which contains absolutely nothing in it other than whatever files and empty directories are expected by the bits outside the runtime that invoke the runtime (e.g. mount points for mounted filesystems), and whose entry point is directly/var/runtime/bootstrap
rather than/lambda-entrypoint.sh
(to avoid needing even the tools to execute/lambda-entrypoint.sh
).Or, if invoking
/lambda-entrypoint.sh
is hardcoded elsewhere,provided.empty
could ship a symlink/lambda-entrypoint.sh
pointing to/var/runtime/bootstrap
.