Ответ 1
Это хорошая запись в которой рассматривается развертывание Django с использованием Nginx и Gunicorn. Я дам вам краткое изложение того, что важно для всех различных технологий:
Git
Git или любая другая система управления версиями, безусловно, не требуется. Почему он приспосабливается к развертыванию проектов Django, так это то, что вы обычно распространяете свое приложение по источнику, т.е. Не компилируете его или не упаковываете в него как яйцо. Обычно вы организуете репозиторий Git таким образом, чтобы обновление вашего приложения на сервере требовало только выполнить проверку последних источников - ничего.
virtualenv и pip
Это опять же не строгое требование, но я настоятельно рекомендую вам потратить время на ознакомление с virtualenv и pip, если вы уже этого не сделали, поскольку он собирается развернуть ваши приложения Python по разным среда выполнения, локальная или удаленная, легкий ветерок.
В принципе, ваш проект должен иметь, по крайней мере, Django и Gunicorn, доступные на пути Python, возможно, даже драйвер базы данных. Это означает, что каждый раз, когда вы пытаетесь развернуть ваше приложение, вам нужно будет установить Python и танцевать easy_install на всем протяжении.
virtualenv будет распространять установку Python, что, в свою очередь, означает, что новый экземпляр Python по умолчанию будет иметь собственную конфигурацию пути Python относительно установки. pip похож на easy_install на стероиды, поскольку он поддерживает проверку зависимостей Python непосредственно из репозиториев кода и поддерживает формат файла требований, с помощью которого вы можете установить и настроить все ваши зависимости одним махом.
С virtualenv и pip все, что вам нужно сделать, это простой текстовый файл со всеми вашими зависимостями, которые могут быть проанализированы с помощью pip и установленным дистрибутивом Python на машине. Оттуда вы просто git checkout repo /app/path; easy_install virtualenv; virtualenv /app/path; ./app/path/scripts/activate; pip install -r /app/path/requirements.txt. Voila, Gunicorn, Django и все другие зависимости затем устанавливаются и доступны немедленно. Когда вы запускаете Gunicorn Django script с экземпляром Python в /app/path/scripts, тогда script немедленно получит доступ к источникам Gunicorn, и он сможет найти ваш проект Django, который будет иметь доступ к Django и другим зависимостям также.
Nginx
Веб-серверы будут в основном использоваться для статических носителей сервера. Все остальное проксируется на ваш экземпляр Gunicorn, который управляет вашим экземпляром Django, поскольку его основная цель - размещать приложения WSGI Python и не выступать в роли веб-сервера общего назначения, и, наоборот, ваш веб-сервер не должен обрабатывать приложения Python.
Почему Nginx часто используется, так это то, что он легкий и точно подходит для обслуживания статических медиа и запросов проксирования. Это происходит с меньшим количеством звонков и свистков, чем, скажем, Apache, что делает его еще проще в настройке и обслуживании, тем более, что это будет более эффективным с точки зрения ресурсов, если вы уже напрягаете.
Gunicorn
Это фактическое приложение Python, которое будет управлять вашим экземпляром Django и предоставлять HTTP-интерфейс, который предоставляет его HTTP-клиентам. Он запустит несколько рабочих процессов, которые будут отличаться от виртуальных машин Python, загруженных источниками вашего приложения и его зависимостей. Основной процесс Gunicorn, в свою очередь, возьмет на себя ответственность за управление тем, какие рабочие процессы управляют запросами на максимальную пропускную способность.
Основной принцип подключения Nginx и Gunicorn
Самое главное наблюдать, что Nginx и Gunicorn - это отдельные процессы, которыми вы управляете самостоятельно.
Веб-сервер Nginx будет публично открыт, т.е. он будет напрямую доступен через Интернет. Для запросов к статическим средам, таким как фактические изображения, таблицы стилей CSS, источники JavaScript и файлы PDF, доступные через файловую систему, Nginx возьмет на себя ответственность за возврат их в тело ответа на HTTP-клиенты, если вы настроите его на поиск файлов по пути, вы настроили свой проект на сбор статического носителя.
Любые другие запросы должны быть проксированы на ваш экземпляр Gunicorn. Он будет настроен на прослушивание HTTP-запросов на определенном порту в интерфейсе loopback, поэтому вы используете Nginx в качестве обратного прокси-сервера для http://127.0.0.1:8080 для запросов к вашему экземпляру Django.
Это основное изложение для развертывания ваших проектов Django в производстве, которое должно удовлетворять потребностям 95% проектов Django. Хотя я упоминал Nginx и Gunicorn, это обычный подход, когда речь заходит о создании любого веб-сервера для работы в качестве обратного прокси-сервера на сервере Python WSGI.