AWS Lambdaへのconda環境
Python関数をAWS Lambdaで作成しました。これは、すでに収集したPythonライブラリの束に依存する関数です。 a conda環境 。
これをLambdaで設定するには、この環境をZipで圧縮することになっていますが、 Lambda docs は、pip/VirtualEnvを使用してこれを行う方法の手順のみを提供します。誰もがこれを経験していますか？
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フラグは現在機能していませんが、次のリリースで修正される予定です。そのため、yqjqの代わりに使用する必要がありました。 pip install yqを使用してyqをインストールできます。これはjqのラッパーにすぎず、yamlファイルでも機能します。
心に留める
Lambdaデプロイコードのサイズは50MBのみです。環境が大きすぎてはいけません。
私はserverless + serverless-python-packagingとそのように作成されたrequirements.txtを使用してラムダをデプロイしようとしたことがなく、機能するかどうかわかりません。
condaを使用する主な理由は、さまざまなバイナリパッケージ（numpy、matplotlib、pyqtなど）を自分でコンパイルしたり、それほど頻繁にコンパイルしたりしないオプションです。 pythonの特定のバージョン（uwsgiなど）用に何かを自分でコンパイルする必要がある場合、gcc環境内のpythonがコンパイルされたのと同じcondaバージョンでバイナリをコンパイルする必要があります-ほとんどの場合、同じgcccondaは現在、conda install gxx_linux-64とともにインストールする必要があるgccの最新バージョンを使用しているため、OSが使用しています。
これにより、次の2つの状況が発生します。
すべての依存関係は純粋にpythonであり、
pip freezeを使用してそれらのリストのリストを実際に保存し、virtualenvに記載されているようにバンドルできます。いくつかのバイナリ拡張があります。その場合、conda環境のバイナリは、pythonで動作しません。残念ながら、実行について説明している page にアクセスする必要があります。環境（AMI：amzn-AMI-hvm-2017.03.1.20170812-x86_64-gp2）、環境を設定し、特定のバージョンの組み込みのバイナリをビルドしますpython別のディレクトリ（純粋なpythonパッケージ）だけでなく、Zipアーカイブにバンドルします。
これは質問に対する一般的な回答ですが、主な考え方は、バイナリパッケージを再利用することはできず、それらのリストのみを再利用することです。
Conda環境を圧縮してもうまくいかない理由は、私には思いつきません。
anaconda2/envs/またはanaconda3/envs/ディレクトリに移動して、アップロードするenv-ディレクトリをコピー/ Zipできると思います。 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環境変数を変更することで機能します。これにより、シェルに~$ pythonを入力したときにpythonインタープリターが呼び出されるものを決定します。インタプリタが何かにimportを指示されたときに表示されるすべてのモジュールを含むディレクトリのリスト。これが#!/usr/bin/env pythonではなく/usr/bin/pythonと表示される主な理由です。