web-dev-qa-db-ja.com

pipenv：展開ワークフロー

Pip＆virtualenvからpipenvに切り替えることを考えています。しかし、ドキュメントを調べた後、pipenvの作成者が展開ワークフローをどのように構成したかについて、私はまだ迷っています。

たとえば、開発では、環境を定義するPipfileとPipfile.lockがあります。展開する展開スクリプトを使用する

  1. git pull Github経由で運用サーバーに
  2. pipenv installは、展開ユーザーのホームディレクトリ内の環境を作成/更新します

しかし、systemdまたはスーパバイザですでに設定されているspecificディレクトリにvenvが必要です。例：command=/home/ubuntu/production/application_xy/env/bin/gunicorn module:app

pipenvは/home/ultimo/.local/share/virtualenvs/application_xy-jvrv1OSiなどの場所にenvを作成します

pipenvでアプリケーションをデプロイするための意図されたワークフローは何ですか？

pythonpipenv
14
caliph

そこにはいくつかのオプションがあります。

  1. pipenv runでgunicornを実行できます：

    pipenv run gunicorn module:app

これによりわずかなオーバーヘッドが発生しますが、$PROJECT_DIR/.env（または他の$PIPENV_DOTENV_LOCATION）から環境をロードするという利点もあります。

  1. PIPENV_VENV_IN_PROJECT環境変数を設定できます。これにより、pipenvのvirtualenvがグローバルな場所ではなく$PROJECT_DIR/.venvに保持されます。

  2. 既存のvirtualenvを使用して、そこからpipenvを実行できます。 Pipenvは、それから実行される場合、独自のvirtualenvを作成しようとしません。

  3. 奇妙なpipenvが作成したvirtualenvパスを使用できます。

13
rczajka

展開のためにpipenvに切り替えたところ、ワークフローはおおよそ次のようになりました（ ansible で管理）。 「project」と呼ばれる架空のプロジェクトの場合、動作中のPipfile.lockがソース管理にチェックインされていると仮定します。

  1. Gitリポジトリのクローンを作成します。

    git clone https://github.com/namespace/project.git /opt/project

  2. そのディレクトリに移動します

    cd /opt/project

  3. ターゲット参照（ブランチ、タグなど）をチェックアウトします。

    git checkout $git_ref

  4. ターゲットPythonバージョン（3.6、2.7など）を使用して、どこかにvirtualenvを作成します。

    virtualenv -p"python$pyver" /usr/local/project/$git_ref

  5. そのvirtualenvのコンテキストでpipenvを呼び出すと、独自のインストールは行われません。

    VIRTUAL_ENV="/usr/local/project/$git_ref" pipenv --python="/usr/local/project/$git_ref/bin/python" install --deploy

    --deployは、Pipfile.lockがPipfileと一致しない場合にエラーをスローします。

  6. Virtualenvのpipを使用してプロジェクト自体をインストールします（Pipfileにまだない場合にのみ必要です）。

    /usr/local/project/$git_ref/bin/pip install /opt/project

  7. 新しいインストールディレクトリへのシンボリックリンクを設定します。

    ln -s /usr/local/project/$git_ref /usr/local/project/current

その後、私のアプリケーションは呼び出し可能です/usr/local/project/current/bin/project_exec --foo --bar、たとえば supervisor で構成されます。

これらはすべて、タグがリモートにプッシュされるとトリガーされます。

以前のバージョンのvirtualenvsはそのままであるため、ロールバックはcurrent-symlinkを以前のバージョンに戻します。つまりタグ1.5が壊れていて、1.4に戻りたい場合は、ln -s /usr/local/project/1.4 /usr/local/project/currentおよびsupervisorctlを使用してアプリケーションを再起動します。

10
karlson

Pipenvは依存関係の管理には非常に優れていると思いますが、あまりにも遅く、扱いにくく、自動展開に使用するにはまだ少し不安定です。

代わりに、ターゲットマシンでvirtualenv（またはvirtualenvwrapper）とpipを使用します。

  • 開発マシンでは、requirements.txtを使用してpipenv lock -r互換のテキストファイルを作成します。

    $ pipenv lock -r > deploy-requirements.txt

  • デプロイ中に、virtualenv内で次を実行します。

    $ pip install -r deploy-requirements.txt
2
Udi

プロジェクトと同じディレクトリに仮想環境を作成するには、次の環境変数を設定します doc

PIPENV_VENV_IN_PROJECT=true

これにより、プロジェクト内の.venvディレクトリに依存関係がインストールされます。 PipEnv v2.8.7から入手可能

2
salmanulfarzy

これを行うだけです：

mkdir .venv
pipenv install

説明：

pipenvは、プロジェクトディレクトリで.venvという名前のサブディレクトリを確認します。見つかった場合は、pipenvはローカル仮想環境を作成します（その後、自動的にPIPENV_VENV_IN_PROJECT=trueを設定するため）

そのため、必要に応じて、次の方法で仮想環境をアクティブ化できます。

source .venv/bin/activate

または、次のようにgunicornのapp.confを構成します。

exec /path/to/.venv/bin/gunicorn myapp:app
1
saitam