Как настроить Python с помощью virtualenv локально и на реальном сервере Linode (или аналогичном)?

Question

Используя PyCharm в Windows, я хотел бы лучше понять, как настроить мою локальную среду так, чтобы она как можно точнее транслировалась на мои серверы на Linode (или на любой другой Linux-модуль).

У меня есть физический диск, отведенный для разработки. В моем случае это диск Z:,

Я обычно создаю один каталог для каждого проекта. Проект определяется как целый сайт.

В настоящее время я также выбрал каталог, Z:\virtualenvгде я создаю свою виртуальную среду. Один на проект. Я полагаю, что несколько проектов могут использовать один и тот же virtualenv, но я не уверен, что это разумно для разработки или производства.

Я подумал о том, чтобы виртуальный проект для каждого проекта был включен в соответствующий проект. Это привлекает меня, потому что тогда каждый проект будет монолитным. Например, если мы говорим о приложении Flask под PyCharm:

d    z:\flask_app
d         .git
d         .idea
d         static
d         templates
d         virtualenv
          main.py

Как тогда вы настраиваете производственный сервер с учетом вышеизложенного?

Давайте предположим, что один использует одну машину для размещения более одного сайта через виртуальный хостинг, это один из них:

<VirtualHost *:80>
  ServerAdmin [e-mail]

  ServerName   example.com
  ServerAlias  example.com *.example.com
  DocumentRoot /var/www/example/public_html
  ErrorLog     /var/www/example/logs/access.log
  CustomLog    /var/www/example/logs/error.log combined

  <Directory   /var/www/example>
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
  </Directory>
</VirtualHost>

Настроить ли я virtualenv на глобальном уровне сервера? Я думаю, что это глобальное "да". Это не могло работать по-другому. Я не думаю

ОК, это означает, что вся структура файла под

z:\flask_app

теперь может быть FTP'd в

/var/www/example/public_html

а на сайт хорошо идти?

Я понимаю, что сервер БД, БД, таблицы и т. Д. Должны быть настроены на рабочей машине, чтобы соответствовать. Я просто сосредотачиваюсь на Python на переходе Python с помощью virtualenv из среды разработки для настольных компьютеров во внешнюю версию Linux.

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

Я буду использовать виртуальную машину с Ubuntu 14.04 LTS, чтобы разобраться с этим по мере продвижения вперед.

Я также подумал об использовании 14.04 Desktop для разработки на виртуальной машине, чтобы обеспечить соответствие сред и выход из Windows.

Answer 1

1) Настольная виртуальная машина 14.04 для того, чтобы просто разобраться и разобраться с вещами перед передачей в сценарии и командную строку для вашего сервера - отличная идея.

2) Вам может понравиться инструмент / проект virtualenvwrapper. Он почти точно соответствует вашему текущему рабочему процессу, но с некоторыми удобными удобствами (весь смысл). По сути, он содержит центральную папку virtualenvs для разных имен (/ папок). Его наиболее удобные команды mkproject (создайте новую папку и virtualenv с тем же именем) и workon (активировать проект с таким именем).

3) К счастью, учитывая, что 14.04 не слишком старый, в его пакетах уже присутствует virtualenv, python-virtualenv (1.11.4). Я бы установил это, а затем использовал его для создания сред на вашем сервере для запуска проектов Python, как вы предлагаете.

Хорошо, это значит, что вся файловая структура в... теперь может быть передана в FTP... и сайт хорош?

Нет, потому что вы пытаетесь перенести virtualenv, созданный для Python, на компьютер с Windows и надеетесь, что он будет работать под Python в Linux / Ubuntu.

4) Чтобы сохранить список управляемых пакетов, необходимых для каждого проекта, перечислите их в файле require.txt. Затем с новым активным virtualenv вы можете просто запустить pip install -r requirements.txt и все необходимые пакеты будут установлены для него.

5) Для запуска ваших приложений на одном сервере я бы предложил запустить локальный WSGI-сервер, такой как Chaussette (возможно, под Circus) или uWSGI, на котором размещено ваше приложение Python WSGI под сокетом локального порта / unix; затем настройте Apache или Nginx на обратный прокси-сервер всего необходимого динамического трафика на этот сервер (см. этот ответ SO в качестве примера).

6) Некоторые элементарные ноу-хау сценариев bash могут очень помочь, если у вас есть вещи с возможностью повторной загрузки:) Если это становится еще сложнее, вы можете использовать продукт управляемой конфигурации, такой как Salt.

Answer 2

Учтите это: ваш репозиторий Git должен содержать исходный код, файлы данных и другие файлы, относящиеся к разработке этого проекта. Он не должен содержать virtualenv, так как он представляет собой смесь исполняемых файлов (Python, pip), заголовочных файлов и зависимостей, установленных из различных источников. Должна быть возможность стереть virtualenv и восстановить его без особых хлопот.

Хотя вы можете иметь источник и virtualenv в одном каталоге, вам необходимо обновить .gitignore файл в любом случае, который указывает, что имеет смысл найти все virtualenvs в другом месте. Дело не в том, чтобы FTP помещал весь каталог в другой: вы должны отделить понятие обновления кода от понятия установки virtualenv (в котором могут быть установлены другие пакеты, отличные от вашей машины для разработки).

Например, вы будете разрабатывать на компьютере с Windows и развертывать на компьютере с Linux, что может привести к использованию разных пакетов. Поэтому важно отделить "исходный код проекта" от "зависимостей и конфигурации, необходимых для запуска".

Аналогично, на производственных серверах вы можете назначить одно местоположение для ваших virtualenvs, и все проекты (где их код установлен где-то в выбранной вами структуре каталогов) будут активировать virtualenv и затем запускаться. На самом деле не существует неправильного или правильного способа сделать что-то, если у каждого процесса есть достаточные разрешения для его выполнения.

В зависимости от того, сколько автоматизации вы хотите поместить в развертывание, вам следует хотя бы немного подумать об автоматизации, чтобы убедиться, что она работает правильно. Все сводится к настройке структуры каталогов, разрешений, извлечению кода из git, настройке virtualenv, установке зависимостей и любой другой оставшейся конфигурации, чтобы все работало. Вы можете сделать эти задачи с помощью Ansible, например.

В общем, лучше не думать о вашем приложении как об одной монолитной вещи, потому что со временем вещи могут перемещаться в другие места. Статические файлы? Возможно, им когда-нибудь понадобится зайти в сеть доставки контента. Установка базы данных? Возможно, когда-нибудь нужно будет перейти на другую машину. И так далее.