从 s3 部署包结构问题上传 cloudformation lambda 函数
Posted
技术标签:
【中文标题】从 s3 部署包结构问题上传 cloudformation lambda 函数【英文标题】:cloudformation lambda function upload from s3 deployment package structure issues 【发布时间】:2021-12-26 08:57:01 【问题描述】:我正在使用 cloudformation 创建我的 lambda 函数。我选择从 S3 中提取代码。
但是,当创建 lambda 函数时,它似乎创建了一个嵌套结构,并且我无法导入我的包,除非我将 lambda
和关联的库包移动到 lambda 函数的根级别。
代码段的Cloudformation值:
Code:
S3Bucket: youll_never_guess-bucket-12345
S3Key: python_data_collector.zip
它在 lambda、aws 控制台中的显示方式:
控制台中处理程序的完整路径:
我试过了:python_data_collector/lambda.lambda_handler
和 python_data_collector.lambda.lambda_handler
错误信息:
Unable to import module 'python_data_collector/lambda': No module named 'requests'"
【问题讨论】:
【参考方案1】:Python 依赖项应位于 lambda 部署包的根级别。您确实可以将嵌套文件作为函数的入口点,但这不会改变函数的依赖行为。
但是,您的 lambda 代码的结构与您的 zip 文件在 S3 存储桶中的位置无关。据推测,当您创建 zip 文件时,您将在根级别添加一个文件夹,其中包含代码和依赖项。您不应该在 zip 文件中包含那个额外的文件夹,只需将代码(嵌套或不嵌套)和依赖项(不嵌套)放在 zip 包的根目录中。 Lambda 将简单地解压缩文件并将内容按原样放置在您的 lambda 函数中。
【讨论】:
有问题的 zip 文件夹 python_data_collector 在根级别具有所有依赖项和 lambda.py。底层文件夹中没有像 python_data_collector/python_data_collector 这样的子文件夹。所以这对我来说没有意义。 我在shell中的zip命令是这样的:zip -r artifact/code.zip python_data_collector/ 我猜该命令将递归地复制文件夹(给定 -r),这意味着它还将复制python_data_collector
文件夹本身。 zip -r artifact/code.zip python_data_collector/*
可能会让你的运气更好,但你应该测试和检查,因为我不知道 zip 命令的行为。以上是关于从 s3 部署包结构问题上传 cloudformation lambda 函数的主要内容,如果未能解决你的问题,请参考以下文章