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

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

вот почему я ищу очень подробно и хорошо объяснил ответ для новичков. Я не хочу слишком много объяснять, что я знаю и чего не знаю, так как это может немного исказить ответы, и другие люди могут получить меньшую выгоду от ваших ответов. Тем не менее, некоторые вещи, которые я хотел бы видеть упомянутыми:

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

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

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

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

  • почему мы создаем символическую ссылку между site-available и sites-enabled на /etc/nginx?

  • некоторые лучшие практики, как всегда приветствуются : -)

спасибо

78
deployment django gunicorn nginx setup-deployment

4 ответов

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

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

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

макет файловой системы не критичен. Вы увидите много статей восхваляющих layouts и даже скелетные проекты, которые вы можете клонировать в качестве отправной точки. Я чувствую, что это скорее личное предпочтение, чем жесткое требование. Конечно, приятно иметь; но если вы знаю, почему, это не добавляет никакого значения в ваш процесс развертывания-поэтому не делайте этого, потому что некоторые блоги рекомендуют это, если это не имеет смысла для вашего сценария. Например - нет необходимости создавать 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) к 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. Это прокси. Так вы увидите различные термины, такие как "upstream"/ "downstream" и несколько "серверов". Потратьте некоторое время и сначала просмотрите руководство nginx.

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

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

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

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

104

я не гуру развертывания, но поделюсь некоторыми из моих практик для развертывания Django с gevent (должен быть похож на gunicorn).

virtualenv отлично по причинам, которые я не буду вдаваться. Однако я нашел virtualenv-wrapper (docs) очень полезно, особенно когда вы работаете над многими проектами, так как позволяет легко переключаться между различными virtualenvs. Это на самом деле не относится к среде развертывания, однако, когда мне нужно устранить неполадки на сервер, использующий SSH, я нашел это очень полезным. Другим преимуществом использования является то, что он управляет каталогом virtualenv, поэтому для вас меньше ручной работы. Virtualenvs предназначены для одноразового использования, чтобы в случае возникновения проблем с версией или любых других проблем с установкой вы могли просто сбросить env и создать новый. В результате рекомендуется не включать код проекта в virtualenv. Его следует держать отдельно.

что касается настройки нескольких сайтов,virtualenv довольно много ответов. У вас должен быть отдельный virutalenv для каждого проекта. Только это может решить многие проблемы. Затем при развертывании другой процесс Python будет запускать разные сайты, что позволит избежать возможных конфликтов между развертываниями. Одним из инструментов, который я особенно нашел очень полезным для управления несколькими сайтами на одном сервере, является supervisor (docs). Он обеспечивает простой интерфейс для запуска, остановки и перезапуска различных экземпляров Django. Он также способен автоматического перезапуска процесса при его сбое или при запуске компьютера. Так, например, если возникает какое-то исключение и его ничто не ловит, весь веб-сайт может пойти вниз. Супервизор поймает это и автоматически перезапустит экземпляр Django. Ниже приведен пример конфигурации программы супервизора (одного процесса):

[program:foo]
command=/path/toviertualenv/bin/python deploy.py
directory=/path/where/deploy.py/is/located/
autostart=true
autorestart=true
redirect_stderr=True
user=www

для Nginx, я знаю, что это может быть подавляющим сначала. Я нашел Nginx книги очень полезно. Это объясняет все основные nginx директивы.

в моей установке nginx я обнаружил, что лучше всего настроить только основные конфигурации в nginx.conf файл, а затем у меня есть отдельная папка sites где я храню конфигурации nginx для каждого из сайтов, которые я размещаю. Затем я просто включаю все файлы из этой папки в основной конфигурационный файл. Я использую директиву include sites/+*.conf;. Таким образом, он включает только файлы, начинающиеся с + символ . Таким образом, только по имени файла я могу контролировать, какая конфигурация файлы загружаются. Поэтому, если я хочу отключить определенный сайт, мне просто нужно переименовать файл конфигурации и перезапустить nginx. Не совсем уверен, что вы имели в виду под" символической ссылкой между доступным сайтом и сайтами с поддержкой в /etc/nginx " в вашем вопросе, так как это именованные папки Apache, но они выполняют аналогичную задачу, как

11

Ну, что касается лучших практик, которые вы задали в своем вопросе, я не могу не поделиться инструментом, который сотворил для меня чудеса, буквально! Я сам запутался в нескольких конфигурационных файлах gunicorn, nginx, supervisorD для нескольких сайтов! Но я жаждал как-то автоматизировать весь процесс, чтобы внести изменения в приложение/сайт и мгновенно развернуть его. Его зовут Джанго-фагунгис. Вы можете найти подробную информацию о моем опыте с Развертывание Django автоматизация здесь. Я только что настроил fabfile.py однажды (django-fagungis использует fabric для автоматизации всего процесса и делает virtualenv на вашем удаленном сервере, который очень удобно для управления зависимостями нескольких сайтов, размещенных на одном сервере. Он использует nginx, gunicorn и supervisorD для обработки развертывания проекта/сайта Django), а django-fagungis клонирует мой последний проект из bitbucket (который я использую для подрывной деятельности) и развертывает его на моем удаленном сервере, и у меня просто есть ввести три команды на оболочку моей локальной машины и что это!! Для меня это оказалось лучшей и беспроблемной практикой для развертывания Django.

2

проверьте это для минимальной конфигурации gunicorn и nginx, необходимой для проекта Django. http://agiliq.com/blog/2013/08/minimal-nginx-and-gunicorn-configuration-for-djang/

2