2012-02-18 13 views
70

私は環境を隔離しており、安全に新しいパッケージのリリースをテストできるので、私はlocalhostで自分のアプリケーションをテストするために常にvirtualenvを使用してきました。djangoプロダクションサーバにはvirtualenvが推奨されていますか?

今、私はプロダクションサーバーにアプリケーションをデプロイする必要があります。私は、プロダクションサーバにvirtualenvを使うべきか、それとも通常のインストールで行うべきなのか疑問に思っています。それはプロダクションサーバーなので、私がdev_server(virtual-envの下で)でテストした正しいバージョンを常に使うことができます。

+3

公式のDjangoのドキュメントでは、本番環境でvirtualenvを使用していることに注意してください。https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/#using-a-virtualenv –

+0

私は@ bartek [nginxとuWSGIのデプロイメントの美しさ](http://bartek.im/blog/2012/07/08/simplicity-nginx-uwsgi-deployment.html) –

+0

Herokuはhttps:// devcenterを推奨しています。 heroku.com/articles/deploying-python –

答えて

42

Webサーバー上で複数のプロジェクトを実行すると思います。 2つのプロジェクトがあるとすぐに、他のサイトを破壊するPythonパッケージの将来のアップグレードのリスクを冒します。

+1

これは、このサーバが単独のアプリケーションを提供するためだけに存在することを知っているときにvirtualenvを使用する必要があるかどうかという疑問を招きます。 –

+4

DevOpsがPythonの依存関係を必要とするものをロールアウトしないことを保証することはできません。常に分離している必要があります。 –

9

はい、私はあなたが生産にそれを展開するvirtualenvを使うべきだと思います。特に、複数のサービスを展開する予定がある場合など、多くのことが簡単になり、きれいになります。 djangoベースのウェブサイトや他のpythonプロジェクト。彼らはそれぞれがパッケージでグローバルなpython環境を汚染したくないと思っています。

私はvirtualenvがすべての依存関係をきれいに管理するのに役立つと思います。

すべてを行う必要がにある本番のenvを更新するには:私は生産にvirtualenvsを使用して、Webサーバーとしてチェロキーと、アプリケーションを提供するためにuWSGIを使用することができます

pip -r name_of_your_requirements_file.txt 

本番環境でvirtualenvを使用するには、パスをPYTHONPATHに追加する必要があります。例えば

あなたENVは、パス「/ホーム/ www /のMY_PROJECT/ENV /」を持っている場合、追加するためのパスは次のようになります。

/home/www/env/lib/python2.7/site-packages/ 

あなたはさまざまな方法でこれを設定しますが、もしすることができますあなたは、単に(休憩前に)あなたのmanage.pyの最上部に以下を追加し、manage.pyを通して、あなたのFCGIやuWSGIインターフェイスを生成している:

import os 
my_virtualenv_path = "/home/www/my_project/env/lib/python2.7/site-packages/" 
# Add it to your PYTHONPATH 
os.path.append(my_virtualenv_path) 

をあなただけで、あなたのセットアップにこれを適応させることができますシェルで次のようにすることもできます:

export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/ 

また、settings.pyファイルを含むディレクトリをPYTHONPATHに追加して、Djangoがそれを検出できるようにする必要があります。そうするために同様の方法で進むだけです。

14

djangoプロダクションサーバにはvirtualenvをお勧めしますか?

はい、プロジェクトをシステム環境の特定の側面に依存しないようにします。また、展開プロセスをより明確かつ構成可能にすることができます。

私はすべての私のDjangoプロジェクトを展開するためにfabric、pip、およびvirtualenvを使用します。

+0

私はあなたが望む言葉が「不扶養」ではないと思っています(システムはあなたのプロジェクトに依存できません)。明確な言語。 –

3

ほとんどの場合、最初にサーバーをセットアップしたときに必要と思われなくても、virtualenvを持っていることをお勧めします。それは、ある種のクラウドサービスを使用していて、短時間の間、特定のタスクのためにサーバを回転させているのであれば、virtualenvを使用する点は見当たりません。

0

開発者用と運用用の両方のDockerコンテナを使用することは非常に一般的です。この傾向に従うことを検討している場合は、もうvirtualenvは必要ありません。

関連する問題