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

Question

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

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

Обычно я создаю один каталог для каждого проекта. Проект определяется как весь веб-сайт.

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

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

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

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

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

<VirtualHost *:80> 
    ServerAdmin you@example.com 

    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 

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

Понимаю, что сервер db, db, таблицы и т. Д. Должен быть настроен на рабочем компьютере для соответствия. Я просто сосредотачиваюсь на 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'd в ... и сайт хорош, чтобы идти?

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

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

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

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

Answer 2

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

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

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

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

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

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