Я завжди використовував virtualenv для тестування свого додатка в localhost, оскільки маю ізольоване середовище і можу безпечно протестувати новий випуск пакетів.
Тепер настає час, коли мені доводиться розгортати свою програму на виробничому сервері. Мені цікаво, чи варто мені також використовувати virtualenv для виробничого сервера, чи просто звичайну інсталяцію. Оскільки це робочий сервер, я завжди можу використовувати правильну версію, яку я тестував на сервері розробника (під virtual-env)
Відповіді:
Я зробив би це так, якщо ви коли-небудь подумаєте, що запустите більше одного проекту на веб-сервері. Як тільки у вас є два проекти, ви ризикуєте в майбутньому оновити будь-який пакет python, що зламає інший сайт.
Чи рекомендується virtualenv для виробничого сервера django?
Так, це робить ваш проект не залежним від певних аспектів системного середовища, а також дозволяє зробити процес розгортання більш чітким та настроюваним.
Я використовую fabric, pip та virtualenv для розгортання всіх своїх проектів Django.
Так, я думаю, вам слід використовувати virtualenv для його розгортання у виробництві. Це робить речі набагато простішими та чистішими для вас, особливо якщо ви плануєте розгортати кілька служб, наприклад веб-сайти на основі django чи інші проекти на python. Ви не хочете, щоб кожен із них забруднював глобальне середовище python своїми пакетами.
Думаю, virtualenv допоможе вам чітко керувати всіма своїми залежностями.
Щоб оновити виробниче середовище, потрібно лише:
pip -r name_of_your_requirements_file.txt
Я використовую virtualenvs у виробництві, а ви можете використовувати uWSGI для обслуговування програм, а Cherokee є веб-сервером.
Щоб використовувати ваш virtualenv у виробництві, вам потрібно буде додати його шлях до вашого PYTHONPATH.
Наприклад, якщо у вашому env є шлях "/ home / www / my_project / env /", шлях для додавання буде таким:
/home/www/env/lib/python2.7/site-packages/
Ви можете налаштувати це різними способами, але якщо ви створюєте інтерфейс FCGI або uWSGI за допомогою manage.py, просто додайте наступне у верхній частині вашого manage.py (перед рештою):
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 зможе його виявити. Просто виконайте подібні дії, щоб зробити це.
У більшості випадків я б погодився, що найкраще мати virtualenv, навіть якщо здається, що він вам не потрібен під час першого налаштування сервера. Тим не менш, якщо ви використовуєте якусь хмарну службу і крутите сервери для певного завдання протягом короткого часу, то я не бачу сенсу використовувати virtualenv.
Я думаю, це є гарним свідченням того, що це повністю підтримуване виробниче рішення, коли uwsgi безпосередньо підтримує його за допомогою прапорця vhost: http://projects.unbit.it/uwsgi/wiki/VirtualHosting
Використання контейнерів Docker як для розробки, так і для розгортання виробництва є досить популярним зараз, тому, якщо ви плануєте слідувати цій тенденції, вам більше не буде потрібно virtualenv.