从 s3 部署包结构问题上传 cloudformation lambda 函数

Posted 2023-03-28

【中文标题】从 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 命令的行为。