Open v0lat1le opened 4 years ago
Many many packages and binaries and libraries exist on the build-* containers that don't exist on the runtime containers (or Lambda itself). This is the nature of the build containers – they need software like gcc, etc to make sure that ppl can build their software. As well as python packages like AWS SAM CLI, etc so that ppl can deploy from their build containers.
How are you building your Lambda functions? Are you using sam build
?
Ah, that makes perfect sense. I think there's a bit of confusion on our part as to the purpose and distinction between the run
and build
containers.
For the record we are trying to do docker run -v ${PWD}:/var/task lambci/lambda:build-python3.7 bash -c "pip install --prefix=dist .; cd dist/lib/python3.7/site-packages/; zip -r9 ../../../${PWD##*/}.zip ."
to only include packages that will not be available within the execution environment.
Thank you!
pip
is a little bit annoying in this regard with the way it deals with packages installed at the system level. I'd use pipenv/virtualenv instead – I think that's a better way of creating a reproducible environment
lambci/lambda:build-python3.7
container containsrequests
module while AWSpython3.7
execution environment doesn't seem to. This causes our build system to skip bundlingrequests
module along side the lambda code.The quick workaround we used was
Some info on past and upcoming changes to
requests
package within AWS env https://aws.amazon.com/blogs/compute/upcoming-changes-to-the-python-sdk-in-aws-lambda/ with might be relevant here