Как развернуть приложение Django + Whitenoise с помощью gunicorn? - PullRequest
0 голосов
/ 01 мая 2019

Я использую Whitenoise для обслуживания статических файлов в моем приложении Django. Я НЕ использую Nginx. Я планирую использовать Whitenoise за CDN, таким как Cloudfront, в будущем. См. Часто задаваемые вопросы по Whitenoise .

Я искал инструкции по развертыванию, в которых рассматриваются следующие вопросы:

  1. Поскольку я не использую nginx, я планирую привязать gunicorn напрямую к порту 80. Это приводит к ошибке - Permission Denied. Я могу запустить gunicorn как root, но это кажется плохим подходом.

  2. Как работать с сертификатами SSL? Обычно это выполняется такими серверами, как Nginx.

РЕДАКТИРОВАТЬ: я развертываю свое приложение на Ubuntu 18.04 VM на Google Cloud Compute Engine.

P.S .: Мой сайт не будет очень посещаемым. Другие использовали эту конфигурацию для обслуживания сайтов с высоким трафиком. Посмотрите это Выжимая каждую каплю производительности из приложения Django на Heroku .

1 Ответ

0 голосов
/ 02 мая 2019

TL; DR

Я использовал nginx в качестве http-сервера.Я удалил конфигурацию, связанную со статическими файлами в nginx, поэтому запросы статических файлов передаются слою wsgi (gunicorn) и обрабатываются Whitenoise.Таким образом, вы можете следовать любым инструкциям / учебным пособиям по развертыванию 'nginx + gunicorn + django', которые легко доступны с помощью простого поиска в Google.

Этот пост прояснил это для меня: Развертывание ваших статических файлов Django вAWS (часть 2) .

Длинный ответ

Как уже упоминалось ранее, существует множество руководств по развертыванию приложений Django + Whitenoise на Heroku.Как указано в комментариях:

Heroku, который имеет собственный прокси-слой в передней части и поэтому вообще не имеет значения.

Без проверки этого утвержденияЯ думал, что это должно быть правдой.gunicorn не является полноценным веб-сервером.На самом деле создатели Gunicorn настоятельно рекомендуют использовать его за прокси-сервером (например, Nginx). См. Документы .

Я был сбит с толку, потому что я всегда думал о Nginx как об обратном прокси.Функционирование обратного прокси для статических ресурсов - это только одна из функций в nginx.Он предоставляет гораздо больше функций, таких как буферизация медленных клиентов, чего нет у Gunicorn, что помогает предотвратить атаки типа «отказ в обслуживании».

Я уже знал это.Было бы глупо не использовать nginx или любой другой веб-сервер.

Whitenoise просто устанавливает правильные заголовки кэширования для статических файлов и включает сжатие с помощью gzip / brotli.При использовании с whitenoise.storage.CompressedManifestStaticFilesStorage он автоматически генерирует версионные статические файлы.Например./static/js/app.49ec9402.js, если вы поместили свой файл в шаблон как {%statis%} 'js/app.js'.Максимальный возраст версии файла для версии - 10 лет, то есть он кешируется навсегда.

Если вы не развертываете на Heroku, вам все равно понадобится веб-сервер, такой как Nginx .Таким образом, вы можете следовать любым инструкциям / руководствам по развертыванию 'nginx + gunicorn + django', которые легко доступны с помощью простого поиска Google.Одним из них является Развертывание ваших статических файлов Django в AWS (часть 2) , что помогло мне решить эту проблему.

...