conda 环境到 AWS Lambda

Question

我想设置一个我在 AWS Lambda 上编写的 Python 函数，该函数依赖于我已经在conda 环境中收集的一堆 Python 库。

要在 Lambda 上进行设置，我应该压缩此环境，但Lambda 文档仅提供有关如何使用 pip/VirtualEnv 执行此操作的说明。 有没有人有这方面的经验？

Answer 1

您应该将serverless 框架与serverless-python-requirements 插件结合使用。 您只需要一个requirements.txt ，插件会自动将您的代码和依赖项打包到一个 zip 文件中，将所有内容上传到 s3 并部署您的函数。 奖励：由于它可以通过 dockerized 来执行此操作，因此它还可以帮助您处理需要二进制依赖项的包。

看看这里 (https://serverless.com/blog/serverless-python-packaging/)的操作方法。

根据经验，我强烈建议您研究一下。 部署的每一点体力劳动都会阻止您开发逻辑。

编辑 2017-12-17：

你的评论是有道理的@eelco-hoogendoorn 。

然而，在我看来，conda 环境只是一个封装了一堆 python 包的地方。 因此，如果您将所有这些依赖项（来自您的 conda 环境）放入一个requirements.txt （并使用无服务器 + 插件）来解决您的问题，不是吗？
恕我直言，它本质上与将您安装在 env 中的所有包压缩到部署包中是一样的。 话虽如此，这是一个片段，它基本上是这样的：

conda env export --name Name_of_your_Conda_env | yq -r '.dependencies[] | .. | select(type == "string")' | sed -E "s/(^[^=]*)(=+)([0-9.]+)(=.*|$)/\1==\3/" > requirements.txt

不幸的是conda env export仅以 yaml 格式conda env export环境。 --json标志现在不起作用，但应该在下一个版本中修复。 这就是为什么我必须使用yq而不是jq 。 您可以安装yq使用pip install yq 。 它只是jq一个包装器，允许它也可以处理 yaml 文件。

记住

Lambda 部署代码的大小只能为 50MB。 你的环境不应该太大。

我还没有尝试过使用serverless + serverless-python-packaging和这样创建的requirements.txt部署 lambda，我不知道它是否会起作用。

Answer 2

我使用conda主要原因是选择不自己编译不同的二进制包（如numpy 、 matplotlib 、 pyqt等）或不那么频繁地编译它们。 当您确实需要为特定版本的python （如uwsgi ）编译某些东西时，您应该使用与您的conda环境中的python编译时使用的gcc版本相同的gcc版本编译二进制文件 - 很可能它与您的gcc操作系统正在使用，因为conda现在正在使用最新版本的gcc ，该版本应该与conda install gxx_linux-64一起conda install gxx_linux-64 。

这导致我们出现两种情况：

1. 您所有的依赖项都在纯 python 中，您实际上可以使用pip freeze保存它们的列表，并按照virtualenv规定捆绑它们。

2. 你有一些二进制扩展。 在这种情况下，您的 conda 环境中的二进制文件将无法与 AWS lambda 使用的 Python 一起使用。 不幸的是，您需要访问描述执行环境的页面（AMI：amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2），设置环境，为特定版本的内置python构建二进制文件单独的目录（以及纯 python 包），然后将它们捆绑到一个 zip 存档中。

这是您问题的一般答案，但主要思想是您不能重用二进制包，只能重用它们的列表。

Answer 3

我想不出一个很好的理由为什么压缩你的 conda 环境不起作用。

我认为您可以进入anaconda2/envs/或anaconda3/envs/目录并复制/压缩要上传的 env 目录。 Conda 只是一个加强版的 virtualenv，加上一个不同的、有点可选的包管理器。 我认为没问题的一个重要原因是 conda 环境默认将所有依赖项封装在它们特定的.../anaconda[2|3]/envs/$VIRTUAL_ENV_DIR/目录中。

使用普通的 virtualenv 表达式会给你更多的自由，就像穴居人比现代人拥有更多的自由一样。 我个人更喜欢汽车。 使用 virtualenv，你基本上会得到一个半空的$PYTHON_PATH变量，你可以用你想要的任何东西来填充它，而不是 Conda 吐出的更强大、预先填充的 env。 下面是一个很好的表供参考： https : //conda.io/docs/commands.html#conda-vs-pip-vs-virtualenv-commands

Conda 将命令~$ /path/to/$VIRTUAL_ENV_ROOT_DIR/bin/activate变成~$ source activate $VIRTUAL_ENV_NAME

假设您想以老式的方式制作virtualenv 。 您将选择一个目录（我们称之为$VIRTUAL_ENV_ROOT_DIR ，）和名称（我们称之为$VIRTUAL_ENV_NAME 。）此时您将输入：

~$ cd $VIRTUAL_ENV_ROOT_DIR && virtualenv $VIRTUAL_ENV_NAME

python 然后创建它自己的解释器库的副本（加上我认为的 pip 和 setuptools）并将一个名为activate的可执行文件放在这个克隆的bin/目录中。 $VIRTUAL_ENV_ROOT_DIR/bin/activate脚本通过更改您当前的$PYTHONPATH环境变量来工作，该变量决定了当您在 shell 中键入~$ python时调用的 Python 解释器，以及包含解释器将在何时看到的所有模块的目录列表它被告知要import一些东西。 这是您将在人们的代码中看到#!/usr/bin/env python而不是/usr/bin/python主要原因。

Answer 4

在https://github.com/dazza-codes/aws-lambda-layer-packing 中，pip 轮子似乎适用于许多软件包（纯 pip 安装）。 很难将大量包捆绑到一个紧凑的 AWS Lambda 层中，因为 pip Wheel 不使用共享库并且往往会变得有些臃肿，但它们可以工作。 根据 github 中的一些讨论，conda 与 pip 的挑战并非微不足道：

• https://github.com/pypa/packaging-problems/issues/25
• 试试https://github.com/conda-incubator/conda-press
• AFAICT，AWS SAM 使用https://github.com/aws/aws-lambda-builders并且它似乎是基于 pip 的，但它在https://anaconda.org/conda-forge/aws_lambda_builders 上也有一个 conda 包