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 包