如何将共享文件和不同依赖项与Python Lambdas打包在一起？

Question

我在使用CDK部署Lambda函数时有一些看似矛盾的问题：

1. 我希望整个项目的所有依赖都安装在本地代码的单个virtualenv中，这样IDE可以一次性索引所有内容。这是通过项目级别的pyproject.toml和poetry.lock来完成的。
2. 我希望每个Lambda函数只安装最小的依赖关系。这是通过为每个Lambda函数使用Poetry“extras”，并仅在打包每个Lambda函数时安装相关的extras来完成的。
3. 我希望通过将共享文件放入它们的共同父目录中，在Lambda之间共享代码。

我目前的做法很笨拙：

bundling_options = BundlingOptions(
    image=aws_lambda.Runtime.PYTHON_3_8.bundling_docker_image,
    command=["backend/bundle.bash", directory],
)
return aws_lambda.Code.from_asset(path=".", bundling=bundling_options)

bundle.bash

1. 使用 poetry export 将 Poetry 中相关条目转换为 pip requirements.txt 格式，并使用 pip install --target=/asset-output 进行安装（因为 Poetry 不支持安装到特定目录），然后
2. 将 directory 及其父目录（共享文件）中的文件复制到 /asset-output。

我必须使用上面的 path="."，因为 Docker 容器需要从项目的根目录读取 pyproject.toml 和 poetry.lock。这似乎导致了另一个问题，即对整个存储库中的任何文件进行更改都会导致重新部署每个 Lambda 函数。这是我正在寻找替代方案的主要原因。

在 CDK 中，有更好的方法可以在具有不同依赖项的 Lambda 函数之间共享文件吗？

一些糟糕的选择：

• 我认为我不能使用 PythonFunction，因为它假设 requirements.txt 文件在根目录中（这是 Lambda 函数之间共享的）。
• 我不想复制软件包列表，因此将所有软件包放入根配置文件中，并在每个 Lambda 函数的 requirements.txt 文件中复制相关软件包是不可行的。
• 我不想在打包时进行任何可怕的代码重写，例如将所有共享代码移动到子目录中并更改从中导入的内容。
• 特定问题的解决方法是在 from_asset 中指定 asset_hash。不幸的是，这会增加相当多的脆弱性和复杂性（对每个可能相关的文件进行哈希），而不是简化。
• 手动在 Docker 外部进行打包。这也会有一定的复杂性（看起来与现在大致相同），并且比在 Docker 内部打包更加脆弱。我还必须对源文件进行哈希，而不是对生成的文件进行哈希，因为 Pip 安装通常是 not reproducible 的（我看到同一软件包在不同目录下的两次安装之间存在很多差异）。

- l0b0

Answer 1

从Node.js世界（NodejsFunction）来的，如果它们没有被使用，依赖项将被简单地从捆绑包中排除掉。我对我的解决方案不满意，但是这就是我的解决方案： 在我的存储库根目录下有一个pyproject.toml和poetry.lock文件，我在其中为所有的lambda函数定义了所有的依赖项。我的虚拟环境使用这些依赖项。然后，我在我的lambdas/文件夹中手动添加requirements.txt文件，只包含我需要的那个lambda函数的依赖项，并确保版本与pyproject.toml中的匹配。然后，我在整个CDK应用程序中使用PythonFunction。请参见下面的文件夹设置的屏幕截图。

- Ben Stickley

Answer 2

我建议您使用Lambda层，在其中应安装名为python的单个文件夹中的所有依赖项，还可以在该层中添加常见功能。
创建AWS Lambda层包的步骤如下 -

$ mkdir python
$ cd python
$ pip install -r requirements.txt -t .

一旦安装这些依赖项，将其制作为名为 python.zip 的zip文件。现在，您可以创建 Lambda Layer 并将此 python.zip 上传到那里。现在，您可以像通常一样导入Lambda函数中的软件包。
AWS Lambda Layers

- Suyog Shimpi

---

我已经有一个botocore层，但决定不采用这种方法，因为它违背了安装所需而非任何服务所需的标准建议。 - l0b0