Conda для AWS Lambda

Ответ 1

Вы должны использовать serverless framework в сочетании с serverless плагин -python-requirements. Вам просто нужен requirements.txt, и плагин автоматически упаковывает ваш код и зависимости в zip файл, загружает все на s3 и развертывает вашу функцию. Бонус: поскольку он может выполнять эту операцию, он также может помочь вам с пакетами, которые нуждаются в бинарных зависимостях.

Посмотрите здесь (https://serverless.com/blog/serverless-python-packaging/) для справки.

Из опыта я настоятельно рекомендую вам изучить это. Каждый бит ручной работы для развертывания и т.д. - это то, что мешает вам развивать вашу логику.

Изменить 2017-12-17:

Ваш комментарий имеет смысл @eelco-hoogendoorn.

Однако, на мой взгляд, среда conda - это просто инкапсулированное место, где живет куча пакетов python. Итак, если вы поместите все эти зависимости (от вашего conda env) в requirements.txt (и используйте сервер без сервера +), который поможет решить вашу проблему, нет? IMHO, по сути, будет таким же, как застежка всех пакетов, которые вы установили в своем 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. Флаг --json не работает прямо сейчас, но предполагается, что он будет исправлен в следующей версии. Вот почему мне пришлось использовать yq вместо jq. Вы можете установить yq с помощью pip install yq. Это всего лишь обертка вокруг jq, чтобы позволить ей работать с файлами yaml.

ХРАНИТЬ В РАЗНООБРАЗИИ

Код развертывания Lambda может быть только размером 50 МБ. Ваша среда не должна быть слишком большой.

Я не пробовал использовать lambda с serverless + serverless-python-packaging и requirements.txt, созданный таким образом, и я не знаю, будет ли это работать.

Ответ 2

Я не могу придумать вескую причину, по которой не удалось закрепить среду вашей конды.

Я хочу, чтобы вы вошли в каталог anaconda2/envs/ или anaconda3/envs/ и скопировали /zip каталог env, который вы хотите загрузить. Конда - это просто версия виртуального виртуального пользователя, плюс другой и несколько необязательный пакет-менеджер. Основная причина, по которой я думаю, это нормально, так это то, что среды конды инкапсулируют все свои зависимости в своих конкретных каталогах .../anaconda[2|3]/envs/$VIRTUAL_ENV_DIR/ по умолчанию.

Использование нормального выражения virtualenv дает вам немного больше свободы, подобно тому, как у пещерных людей была больше свободы, чем у современных людей. Лично я предпочитаю автомобили. С virtualenv вы в основном получаете полупустую переменную $PYTHON_PATH, которую вы можете заполнить тем, что хотите, а не более надежный, предварительно заполненный env, который вырывает Conda. Ниже приведена справочная таблица: https://conda.io/docs/commands.html#conda-vs-pip-vs-virtualenv-commands

Конда превращает команду ~$ /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 в этот каталог clone bin/. $VIRTUAL_ENV_ROOT_DIR/bin/activate script работает, изменяя текущую переменную среды $PYTHONPATH, которая определяет, какой интерпретатор python вызывается при вводе ~$ python в оболочку, а также список каталогов, содержащих все модули, которые интерпретатор увидит, когда сказано import что-то. Это основная причина, по которой вы увидите #!/usr/bin/env python в коде людей вместо /usr/bin/python.

Ответ 3

Основная причина, по которой я использую conda, - это вариант не для компиляции разных бинарных пакетов (например, numpy, matplotlib, pyqt и т.д.), или их компиляции реже. Когда вам нужно что-то скомпилировать для конкретной версии python (например, uwsgi), вы должны скомпилировать двоичные файлы с той же версией gcc, что python в вашей среде conda скомпилирован с - скорее всего, это не та самая gcc, которую использует ваша ОС, поскольку conda теперь использует последние версии gcc, которые должны быть установлены с помощью conda install gxx_linux-64.

Это приводит нас к двум ситуациям:

• Все ваши зависимости находятся в чистом питоне, и вы действительно можете сохранить список их списков с помощью pip freeze и расслоить их, как указано для virtualenv.

• У вас есть двоичные расширения. В этом случае двоичные файлы из среды conda не будут работать с питоном, используемым AWS lambda. К сожалению, вам нужно будет посетить страницу описывающую среду исполнения (AMI: amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2), настроить среду, создать двоичные файлы для конкретной версии встроенного python в отдельном каталоге (а также чистые пакеты python), а затем связать их с zip-архивом.

Это общий ответ на ваш вопрос, но основная идея заключается в том, что вы не можете повторно использовать свои двоичные пакеты, а только их список.