- 我希望整个项目的所有依赖都安装在本地代码的单个virtualenv中,这样IDE可以一次性索引所有内容。这是通过项目级别的pyproject.toml和poetry.lock来完成的。
- 我希望每个Lambda函数只安装最小的依赖关系。这是通过为每个Lambda函数使用Poetry“extras”,并仅在打包每个Lambda函数时安装相关的extras来完成的。
- 我希望通过将共享文件放入它们的共同父目录中,在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)
- 使用
poetry export
将 Poetry 中相关条目转换为 pip requirements.txt 格式,并使用pip install --target=/asset-output
进行安装(因为 Poetry 不支持安装到特定目录),然后 - 将
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 的(我看到同一软件包在不同目录下的两次安装之间存在很多差异)。