Thanks for the write up. Did you consider using the AWS SAM/LambCI "build" variant containers to avoid installing developer tools? Everyone has this and it follows the "lambci/lambda:build-" naming convention. SAM uses these build variants too. I make heavy use of them not only for layers building (github.com/customink/ruby-vips-lambda) but for local development/test too.
Also, have you seen Michael Hart's yumda project (github.com/lambci/yumda) on LambCI? In some cases it can be useful. I tend to put layer building into 3 buckets.
Dont use a layer. Build the package for the target. Examples in Node are Sharp.JS. In ruby, here is a MySQL2 gem for Lambda. I think this is the best option for common things.
Highly optimized libs, headers, shared object, etc for a specific package using Lambda Layers. Packages are different. Sometime they need to compile or link to things differently. The Ruby libvips link is a good example of this.
Alejandro has been involved with the Node.js project and its community for some time, helping to grow its community in latam. He enjoys speaking on web security, Node.js performance and serverless.
Thanks for reading! I did knew the build images from lambci but wanted to illustrate that for some cases you won't get all the necessary tools and that you could still craft your way into a build image that suits your needs.
It's the first time I read about yumda but sounds exactly what I was after originally. I had a similar experience with what you mention about not using layers for code, it was kind of a pain and limits your tree-shaking possibilities in real world projects. It's a super interesting conversation on when it's worth to use a layer and I think binaries are one of those use-cases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the write up. Did you consider using the AWS SAM/LambCI "build" variant containers to avoid installing developer tools? Everyone has this and it follows the "lambci/lambda:build-" naming convention. SAM uses these build variants too. I make heavy use of them not only for layers building (github.com/customink/ruby-vips-lambda) but for local development/test too.
Also, have you seen Michael Hart's yumda project (github.com/lambci/yumda) on LambCI? In some cases it can be useful. I tend to put layer building into 3 buckets.
Hope that helps!
Thanks for reading! I did knew the build images from lambci but wanted to illustrate that for some cases you won't get all the necessary tools and that you could still craft your way into a build image that suits your needs.
It's the first time I read about
yumdabut sounds exactly what I was after originally. I had a similar experience with what you mention about not using layers for code, it was kind of a pain and limits your tree-shaking possibilities in real world projects. It's a super interesting conversation on when it's worth to use a layer and I think binaries are one of those use-cases.