Развертывание Django с gunicorn и nginx

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

virtualenv-это способ изолировать среды Python; как таковой, он не имеет большой роли в развертывание - однако в течение развитие и тестирование это a требование, если не очень рекомендуется.

значение, которое вы получите от virtualenv, заключается в том, что оно позволяет вам убедиться, что для приложения установлены правильные версии библиотек. Так что не имеет значения, где вы придерживаетесь самой виртуальной среды. Просто убедитесь, что вы не включаете его в систему управления версиями исходного кода.

макет файловой системы не является критическим. Вы увидите много статей, восхваляющих достоинства макетов каталогов и даже скелетные проекты, которые вы можете клонировать в качестве отправной точки. Я чувствую, что это скорее личное предпочтение, чем жесткое требование. Конечно, его приятно иметь; но если вы знаю, почему, это не добавляет никакой ценности в ваш процесс развертывания - так что не делайте этого, потому что некоторые блоги рекомендуют его, если это не имеет смысла для вашего сценария. Например - нет необходимости создавать setup.py файл, если у вас нет частного сервера PyPi, который является частью рабочего процесса развертывания.

как я могу настроить вещи таким образом, что позволяет размещать несколько сайтов на одном сервере?

есть две вещи, которые вам нужно сделать несколько настроек сайта:

1. сервер, который прослушивает общедоступный IP-адрес на порту 80 и / или порту 443, если у вас есть SSL.
2. куча "процессов", которые работают с фактическим исходным кодом django.

люди используют nginx для #1, потому что это очень быстрый прокси, и он не приходит с накладными расходами комплексного сервера, такого как Apache. Вы можете использовать Apache, если вам это удобно. Нет требования, что "для нескольких сайтов используйте nginx"; вам просто нужна служба, которая прослушивает этот порт, знает, как перенаправить (прокси) на ваши процессы, работающие с фактическим кодом django.

для #2 есть несколько способов запустить эти процессы. gevent / uwsgi являются наиболее популярными из них. Единственное, что нужно помнить здесь не использовать runserver в производство.

это абсолютные минимальные требования. Обычно люди добавляют какой-то менеджер процессов для управления всеми запущенными "серверами django" (#2). Здесь вы увидите upstart и supervisor упоминается. Я предпочитаю supervisor, поскольку ему не нужно брать на себя всю систему (в отличие от выскочки). Однако, опять же - это не жесткие требование. Вы могли бы прекрасно запустить кучу screen сеансы и отцепить их. Недостатком является то, что если ваш сервер перезагрузится, вам придется перезапустить сеансы экрана.

лично я бы порекомендовал:

1. Nginx для #1
2. выберите между uwsgi и gunicorn - я использую uwsgi.
3. руководитель для управления внутренними процессами.
4. отдельные системные учетные записи (пользователи)для каждого приложения, которое вы размещаете.

причина I рекомендация №4-изолировать разрешения; опять же, не является требованием.

почему некоторые люди предлагают использовать gunicorn_django-b 0.0.0.0: 8000 и другие предлагают gunicorn_django-b 127.0.0.1: 8000? Я проверил последнее в экземпляре Amazon EC2, но он не работал, пока работал первый без проблем.

0.0.0.0 означает "все IP-адреса" - это мета-адрес (то есть адрес-заполнитель). 127.0.0.1 - это зарезервированный адрес, который всегда указывает на локальный компьютер. Именно поэтому его называют "localhost". Он доступен только для процессов, работающих в одной системе.

обычно сервер переднего плана (#1 в списке выше) прослушивает общедоступный IP-адрес. Ты должен явно привязать сервер к один IP-адрес.

однако, если по какой-то причине вы находитесь на DHCP или не знаете, какой IP-адрес будет (например, его недавно подготовленная система), вы можете сказать nginx / apache / любой другой процесс для привязки к 0.0.0.0. это должно быть временная остановка временная мера.

для производственных серверов у вас будет статический IP. Если у вас есть динамический IP (DHCP), то вы можете оставить в 0.0.0.0. Однако очень редко у вас будет DHCP для ваших производственных машин.

привязка gunicorn/uwsgi к этому адресу не рекомендуется в производстве. Если вы привязываете свой бэкэнд-процесс (gunicorn / uwsgi) to 0.0.0.0, он может стать доступным "напрямую", минуя ваш интерфейсный прокси (nginx/apache/etc); кто-то может просто запросить http://your.public.ip.address:9000/ и получить доступ к приложению напрямую особенно если ваш сервер переднего плана (nginx) и ваш внутренний процесс (django/uwsgi/gevent) работают на одной машине.

вы можете сделать это, если вы не хотите иметь хлопот с запуском прокси-сервера переднего плана, хотя.

какова логика конфигурационного файла nginx? Есть так много учебники, использующие совершенно разные файлы конфигурации, которые я путают, на какой лучше. Например, некоторые люди используют "псевдоним /path/to/static /folder" и другие "root/path/to/static / folder". Возможно, вы можете поделиться своим предпочтительным файлом конфигурации.

Первое, что вы должны знать о nginx является то, что это не сервер как Apache или IIS. Это прокси-сервер. Так вы увидите разные термины, такие как "вверх по течению"/ "вниз по течению" и несколько "серверов". Потратьте некоторое время и сначала просмотрите руководство nginx.

есть много различных способов настроить nginx; но вот один ответ на ваш вопрос о alias и root. root является явной директивой, которая связывает корень документа ("домашний каталог") nginx. Это каталог, который он будет смотреть, когда вы даете запрос Без пути, как http://www.example.com/

alias означает "сопоставить имя с каталогом". Каталоги с псевдонимами не может быть подкаталог корня документа.

почему мы создаем символическую ссылку между сайтами-доступными и сайтами-включенными в / etc / nginx?

это что-то уникальное для debian (и debian-подобных систем, таких как ubuntu). sites-available список файлов конфигурации для всех виртуальных хостов / сайтов в системе. Символическая ссылка от sites-enabled to sites-available "активирует" этот сайт или виртуальный хост. Это способ разделить файлы конфигурации и легко включить/выключить хозяев.