Аналог gunicorn для windows

Обновлено: 04.07.2024

Flask или Django?

В большинстве случаев — Django.

Нужно ли разбивать свой код на отдельные приложения?

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

Стоит использовать DTL (Django’s default template language) или что-нибудь другое?

Sportmaster Lab , Санкт-Петербург, Москва, Липецк , От 100 000 до 150 000 ₽

По умолчанию он уже есть в пакете Django, и в принципе может выполнять всё, что вам нужно.

DTL не делает то, что мне нужно, могу я использовать Jinja2?

Всё равно используйте DTL.

Что использовать для запуска Django — uWSGI или Gunicorn?

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

Где мне стоит разворачивать своё приложение?

Если вам нужно больше управляемости или вы привязаны к AWS, то используйте AWS Elastic Beanstalk.

Вы, конечно, можете взять простенькую VM, установить туда nginx и настроить всё сами. Но зачем, если для этого уже существуют готовые решения?

Создать свою собственную платформу то же самое, что написать новую ОС. Зачем возиться?

Что использовать для обслуживания статических файлов?

Amazon S3, Nginx, Apache — все они хороши, но Whitenoise относительно маленькая библиотека, которая помогает обслуживать статические файлы без использования сторонних сервисов.

Может быть, не надо? Панель администратора Django — хорошая штука, но ссылаясь на официальную документацию:

Возможности панели ограничены. Она не предназначена для того, чтобы в неё ещё что-нибудь добавляли.
У панели администратора есть много возможностей для кастомизации, но не переусердствуйте. Если вам нужен более процессо-ориентированный интерфейс, который абстрагирует базы данных, поля и таблицы, время задуматься о написании своей панели.

Если вы до сих пор ломаете голову, как подстроить администратора под себя, — перестаньте. Пойдите и попробуйте сделать что-нибудь с generic views.

Какую базу данных использовать?

Она просто работает.

Стоит ли разделять файл конфигурации между разработкой и продакшном?

Twelve-Factor App охватывает ряд причин, по которым файлы конфигурации в приложении для каждой среды могут быть проблематичными, и почему вместо этого стоит использовать переменные окружения. django12factor и другие приложения помогут вам получить конфигурацию из окружения.

Стоит ли использовать кастомную модель пользователя?

Из официальной документации:

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

Это изменение не может быть сделано автоматически и требует ручной работы, перемещения данных из старой таблицы пользователя и, возможно, ручного повторного применения некоторых миграций.

Краткая история серверов WSGI Python

WSGI-серверы появились потому, что веб-серверы в то время не умели взаимодействовать с приложениями, написанными на языке Python. WSGI (произносится как «whiz-gee» с твердым «g») был разработан Филиппом Дж. Эби (вместе с Ян Бикинг и др.) В начале 2000-х годов. Модуль Apache, известный как mod_python, разработанный Григорием Трубецким в конце 90-х годов, на тот момент обрабатывал большую часть Python-приложений. Однако mod_python не был официальной спецификацией. Он был просто создан, чтобы разработчики могли запускать код Python на сервере. К сожалению, такой подход был небезопасным и разработчики начали искать новое решение.

WSGI(Web-Server Gateway Interface) является потомком CGI(Common Gateway Interface). Когда веб начал развиваться, CGI разрастался из-за поддержки огромного количества языков и из-за отсутствия других решений. Однако, такое решение было медленным и ограниченным. WSGI был разработан как интерфейс для маршрутизации запросов от веб-серверов(Apache, Nginx и т.д.) на веб-приложения.

Сервер и веб-приложение

В простейшем случае WSGI состоит из двух основных сущностей:

Веб-сервер (Nginx, Apache и т. д.);
Веб-приложение, написанное на языке Python.

Принцип работы:

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

Вот примеры фреймворков, поддерживающих WSGI:

Почему именно WSGI?

Возможно Вы спросите «Хорошо, но почему именно WSGI?». На это есть несколько причин:

WSGI-сервера были разработаны чтобы обрабатывать множество запросов одновременно. А фреймворки не предназначены для обработки тысяч запросов и не дают решения того, как наилучшим образом маршрутизировать их(запросы) с веб-сервера.
WSGI ускоряет разработку веб-приложений написанных на языке Python. Если в разработке веб-приложения Вы используете фреймворк(Django или что-то ещё) Вам не нужно беспокоиться о том, как Ваша конкретная инфраструктура использует стандарт WSGI.
WSGI дает Вам гибкость в изменении компонентов веб-стека без изменения приложения, которое работает с WSGI.

Bjoern

uWSGI

uWSGI был разработан компанией Unbit(Италия) с целью стать fullstack-решением, способным создавать услуги хостинга. Он назван в честь стандарта WSGI и создавался как плагин для одного из проектов компании.

Широкий и постоянно развивающийся проект, uWSGI позволяет делать гораздо больше, чем веб-приложения для хостинга. Многие находят uWSGI мощным инструментом, в то время как другие считают его несколько раздутым. Начиная с версии 2.0 uWSGI поддерживает также запуск веб-приложений на языках Lua, Perl, Ruby и других.

mod_wsgi

• Вы не нуждаетесь в root-правах при полной установке.
• Создается локальная среда, что снижает риск негативного воздействия на существующие настройки.

Развитие mod_wsgi как проекта может показаться медленным из-за того, что модуль разрабатывается одним разработчиком. Другим недостатком является то, что документация в настоящее время плохо организована и может быть устаревшей.

В настоящее время основное внимание уделяется упрощению реализации Apache с использованием mod_wsgi в средах с использованием Docker.

Meinheld

Meinheld имеет зависимость от стороннего компонента, называемого greenlet.

Репозиторий с исходным кодом расположен на GitHub. Meinheld поддерживает веб-сокеты и включает в себя несколько monkeypatches над другими модулями для расширения функциональности.

CherryPy

• Быструю, простую настройку;
• Возможность масштабирования;
• Небольшое и простое в использовании решение для ваших приложений Python;
• Поддержка SSL.

CherryPy отличает себя от более известных WSGI-серверов из-за простоты использования и удобства для разработчиков. Вы можете написать небольшое веб-приложение в течении нескольких минут, запустив его в несколько процессов и создав только один файл с именем server.py. Объединив CherryPy с Nginx в качестве прокси-сервера, Вы получите надежный способ обслуживания своих веб-приложений. CherryPy был создан Реми Делоном. Он хотел создать структуру, которая была бы максимально близка к главным принципам разработки на языке Python.

Gunicorn

Gunicorn — это WSGI-сервер, созданный для использования в UNIX-системах. Название — сокращенная и комбинированная версия слов «Green Unicorn». На самом сайте проекта есть зеленый единорог. Gunicorn был перенесен из проекта «Unicorn» из языка Ruby. Он относительно быстрый, ресурсоёмкий, легко запускается и работает с широким спектром веб-фреймворков.

Команда разработчиков рекомендует использовать Gunicorn в связке с Nginx, где Nginx используется в качестве прокси-сервера.

Для Django разработано немало серверов, потому трудно понять, какая установка подходит именно вам. Каждый из серверов имеет свои преимущества и недостатки. В этой статье мы рассмотрим наиболее распространенные серверы Django.

1: Сервер разработки Django

Сервер разработки Django поставляется в комплекте с Django и запускается с помощью следующей команды:

Эта команда запускает легкий веб-сервер, работающий по умолчанию через localhost по порту 8000. Чтобы изменить IP и порт, передайте новые значения в качестве аргументов:

django-admin.py runserver 10.0.0.150:8001

После запуска этой команды веб-сервер будет обслуживать приложение Django по IP-адресу 10.0.0.150 и порту 8001.

Сервер разработки Django предназначен исключительно для среды разработки. Он не подходит для производственной среды, как сказано в официальной документации Django. Сервер разработки предлагает вам простой способ протестировать приложение в среде разработки, не тратя время и ресурсы на установку и настройку полноценного веб-сервера.

Сервер разработки Django выгодно отличается от остальных своей легкостью и простотой в использовании. Он обслуживает статические файлы приложения, не собирая их в каком-то конкретном месте. Сервер разработки перезапускается при каждом сохранении файлов. Это полезно, потому что большинство веб-серверов для Python кэшируют приложение, но требуют перезагрузки для кэширования новой версии кода.

Очевидным недостатком сервера разработки Django является его непригодность в среде производства. Он не предназначен для обработки большого количества запросов.

В целом же, сервер разработки – отличный вариант для тех, кто хочет быстро начать работу с Django.

2: mod_wsgi

mod_wsgi – самый популярный модуль адаптера WSGI Python для Apache. Его рекомендуется использовать, если приложение обслуживается веб-сервером Apache.

После установки mod_wsgi его довольно просто внедрить. Просто добавьте следующую строку в виртуальный хост Apache:

WSGIScriptAlias /yourapp /opt/yourenv/yourapp.wsgi

Если приложение Django находится вне каталогов, в которых Apache ищет файлы, вам также нужно добавить в виртуальный хост следующее:

<Directory /opt/yourenv>
Order allow,deny
Allow from all
</Directory>

Обратите внимание: если вы хотите установить приложение WSGI в корень домена, вы можете использовать «/», но тут есть нюанс. В таком случае все статические файлы, найденные в DocumentRoot, будут обслуживаться не Apache, а скорее приложением WSGI. Чтобы обойти это, просто укажите статические файлы с помощью директивы Alias:

Alias /static/ /opt/yourenv/static/

Как и в случае с директивой WSGIScriptAlias, первым аргументом является точка монтирования. Второй аргумент – путь к каталогу, в котором хранятся все статические файлы.

Преимуществом mod_wsgi является его простая интеграция с Apache. Это отлично подходит для всех, кто использует Apache в качестве основного веб-сервера.

3: uWSGI

uWSGI – это сервер, который реализует протокол WSGI для связи с другими веб-серверами (Nginx, Apache, Cherokee и т. д.). Его цель – интерпретация кода Python, пока веб-сервер обрабатывает статические файлы и другие запросы. uWSGI был написан специально для Python, поэтому установить его можно с помощью следующей команды:

sudo pip install uwsgi

Внедрить uWSGI в приложение Django довольно просто. На сайте проекта Django есть отличная документация по этой теме (вы можете найти ее здесь).

Как только вы установите и запустите uWSGI, как показано в документации Django, останется только проксировать на uWSGI запросы с основного веб-сервера. Метод будет зависеть от вашего веб-сервера, но, как правило, очень это просто.

Плюсом uWSGI является то, что он очень легкий, работает отдельно от веб-сервера (чтобы не перегружать его процессы) и его относительно легко настроить.

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

4: Gunicorn

sudo pip install gunicorn

Как и uWSGI, Gunicorn проксирует запросы основного веб-сервера. Настройка проксирования в Gunicorn не легче, чем в uWSGI.

Сервер Gunicorn также очень легкий. Быстрее ли он, чем uWSGI? Это спорный вопрос. Во многом результат зависит от настройки серверов. Оба они могут предоставить впечатляющую производительность, хотя некоторые пользователи отмечают, что Gunicorn лучше справляется с высокой нагрузкой.

Недостатки Gunicorn такие же, как и у uWSGI (хотя некоторые считают, что Gunicorn легче настраивается, чем uWSGI).

Заключение

Flup не очень широко используется, поэтому его устанавливать не рекомендуется. Модуль mod_python для Apache работает нормально, но в большинстве документаций рекомендуется использовать modwsgi.

Итак, какой же сервер лучше? Ответ на этот вопрос зависит исключительно от вашей среды и вашего приложения. Если вы любите работать с Apache и не хотите долго возиться с настройкой и интеграцией, используйте mod_wsgi. Если приложение обслуживается другим веб-сервером, выберите uWSGI или Gunicorn. Оба сервера отлично справятся с обслуживанием приложения Django. В среде разработки обязательно используйте встроенный сервер Django для тестирования работы приложения.

Рано или поздно вы приходите к тому, что надо запустить проект на сервере. Этот туториал покажет как превратить любой Python-скрипт в сайт. Также будут примеры запуска проектов, сделанных на Django и Flask.

Цель туториала — сделать сайт, который узнает ваш IP-адрес:

Что надо знать

Конечно же, без определённых знаний и навыков запустить сайт на сервере не получится. Вот небольшой список того, что вы должны знать и уметь:

Системные требования

1. Запустите веб-сервер

Без веб-сервера не работает ни один сайт в интернете. Каждый раз, когда вы открываете страницу сайта ваш браузер связывается с сервером и запрашивает необходимые для работы ресурсы: HTML, картинки, шрифты и прочее. Веб-сервер отвечает за то, чтобы найти эти файлы и переслать их браузеру.

Давайте начнём с самого простого сайта, который просто показывает текст Here be dragons . Сайт будет реализован в виде Python-скрипта. Чтобы превратить скрипт в сайт нужен веб-сервер. А чтобы веб-сервер понял, как правильно запустить скрипт, существует стандарт WSGI.

WSGI — это стандарт взаимодействия между Python-скриптом и веб-сервером

Стандарт WSGI поддерживает много разных веб-серверов. Один из них Gunicorn. Он относительно быстр, легко настраивается и работает со многими веб-фреймворками. Написан Gunicorn на Python и поставляется в виде обычной библиотеки.

Gunicorn — это веб-сервер с поддержкой стандарта WSGI

Что-ж, пора начинать. Сперва установите Gunicorn:

В скрипте сейчас есть всё необходимое, чтобы увидеть текст Here be dragons в браузере. Осталось запустить веб-сервер Gunicorn. Запустите его командой:

Ключ -b или --bind означает “привязка” к определённому IP-адресу и порту.

82.148.28.32 — это IP-адрес сервера на котором хотите запустить Gunicorn. Тем же способом можно запустить веб-сервер локально на адресе 127.0.0.1 , либо на всех сетевых интерфейсах сразу через 0.0.0.0 .

После запуска Gunicorn сообщит в консоль, что он готов и ждёт входящих запросов от браузера:

Скрипт отправляет не только текст, но ещё статус и заголовки. Их можно проверить через инструменты разработчика браузера:

В Status Code вы видите статус 200 OK и заголовок Content-type , в котором обычный текст text/plain .

Отлично, вы теперь умеете запускать веб-сервер Gunicorn!

2. Сделайте сайт

У вас есть заготовка сайта Here be dragons. Превратим её в сайт, что определяет IP-адрес пользователя.

Добавьте в скрипт server.py HTML разметку:

Так как вместо Here be dragons функция теперь возвращает HTML, то Content-type изменился на text/html — вы сообщаете браузеру, что это разметка HTML.

Протестируйте обновлённый скрипт. Остановите Gunicorn командой Ctrl-C в консоли и запустите снова. В браузере обновите страницу сайта:

Сайт работает, IP-адрес он показывает не настоящий: 0.0.0.0 . Это лишь временная заглушка.

Содержимое словаря environ можно вывести в консоль и посмотреть что там лежит. Для этого добавьте в вашу функцию одну отладочную строчку кода перед return :

Перезапустите Gunicorn и обновите страницу в браузере. В консоли вы увидите подобный вывод:

Остался последний рывок — отобразить IP-адрес на сайте. Допишите скрипт и перезапустите Gunicorn. Получится что-то подобное:

Ура! Теперь у вас работает полноценный сайт. Сайт по определению IP-адреса:

3. Демонизируйте Gunicorn

В норме программы, запущенные внутри сеанса ssh будут остановлены вместе с завершением этого сеанса. Стоит пользователю отключиться от сервера и сайт сразу упадёт из-за остановки Gunicorn.

Для решения таких проблем в Linux существуют демоны — это программы, которые работают в фоне. Их запускает не пользователь, а операционная система, благодаря чему демон продолжает работать даже когда пользователь уходит с сервера. Чтобы сайт не падал Gunicorn тоже надо сделать демоном.

Systemd — система, которая управляет демонами. С её помощью вы сделаете Gunicorn демоном, а также сможете отслеживать его работу. С Systemd ваш сайт всегда будет онлайн.

Перейдите в папку /etc/systemd/system и создайте файл getip.service с настройками для будущего демона Gunicorn:

Замените путь к каталогу WorkingDirectory=/root/wsgi на тот, где лежит ваш скрипт. Также поменяйте IP адрес в настройке ExecStart .

После добавления нового сервиса перенастройте Systemd и запустите сервис:

Если при запуске сервиса будет ошибка, то вы не заметите этого. Проверить работу сервиса можно командой:

Вот пример вывода статуса сервиса:

Если всё прошло успешно, вы увидите зелёный кружок перед именем сервиса getip.service и зелёный индикатор активности active (running) .

Осталось добавить сервис getip в автозапуск при старте сервера:

Вы увидите в консоли:

Теперь ваш сайт будет работать всегда! Даже если вы перезапустите сервер, то Gunicorn включится сам.

4. Добавьте воркеров к Gunicorn

Gunicorn — это серьёзный веб-сервер, рассчитанный на большую нагрузку. Он умеет обрабатывать несколько запросов одновременно благодаря своей архитектуре. У Gunicorn есть главный процесс, который управляет набором рабочих процессов — воркеров. Главный процесс только распределяет запросы от клиентов сайта, а обрабатывают их воркеры.

Проверьте, сколько воркеров сейчас использует Gunicorn. Вдруг он использует сервер не на полную? Количество воркеров можно проверить в статусе демона. Проверьте статус Gunicorn командой:

Вы увидите статус Gunicorn:

На скриншоте красным выделена группа процессов. Видно, что запущено 2 процесса: 1 главный и 1 рабочий — воркер.

Веб серверу нужен хотя бы один воркер. Но одного воркера мало, чтобы разогнать Gunicorn по максимуму. Это всё из-за того, что воркеру мешают операции ввода/вывода, из за которых Python засыпает и ждёт ответа. Если воркеров будет мало, сервер работает не в полную силу, а если слишком много — тормозит. Число воркеров зависит от ядер процессора. Документация Gunicorn советует придерживаться такой формулы:

N воркеров = Количество ядер x 2 + 1

Количество ядер процессора показывает штатная утилита nproc:

Вот пример вывода npoc:

Итак, если у процессора 1 ядро, то по формуле получается 3 воркера. Эта опция указывается в настройке демона Gunicorn. Вот новое содержимое файла getip.service :

Поменялись только настройки ExecStart . Gunicorn запускается с ещё одним ключом -w или --workers , что как раз и означает количество воркеров.

А теперь проверьте статус Gunicorn:

В консоли будет:

Снова обратите внимание на группу процессов. Сейчас запущено 4 процесса: 1 главный и 3 воркера. Теперь Gunicorn будет работать быстрее.

5. Как запустить Django через Gunicorn

В Django уже есть встроенный веб-сервер — runserver. Его используют для быстрой отладки во время разработки. Но сами же разработчики Django прямым текстом пишут о том, что использовать в продакшне его не стоит:

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests.

Gunicorn быстрее и заботится о безопасности. Его можно использовать в продакшне, и даже ребята из Django советуют это делать.

Django поддерживает работу с WSGI веб-серверами из коробки. Django оборачивает весь проект в одну простую функцию и кладёт её в файлы wsgi.py и asgi.py в папке проекта рядом с settings.py .

Ниже будет пример запуска пустого Django-проекта через Gunicorn. В результате вы увидите в браузере страницу Django “Congratulations!” . Это та самая страница с ракетой.

В репозитории Django уже создала файлы wsgi.py и asgi.py . Который их них запускать? Файл asgi.py создан для асинхронных веб-серверов, а Gunicorn так не умеет. Используйте файл wsgi.py .

Для Django проекта важно из какого каталога будет запущен Gunicorn. Скрипты Python вычисляют пути к другим файлам проекта принимая за точку отсчёта корень проекта. А корнем считается текущий путь – тот каталог, откуда запущены скрипты. Если запустить Gunicorn из другого каталога, то и путь к корню проекта получится неправильный.

Воспользуйтесь утилитой tree, чтобы понять, откуда запускать Gunicorn:

Как видно, wsgi.py лежит в папке blog . Gunicorn запускается уровнем выше — оттуда, где лежит manage.py :

Вот и всё, что требуется чтобы запустить Django-проект через Gunicorn!

6. Как запустить Flask через Gunicorn

Фреймворк Flask, как и Django, тоже поддерживает работу с Gunicorn из коробки.

Вот простейший сайт на Flask, который выводит в браузер текст Here be dragons . Содержимое скрипта server.py :

Сайт можно запустить в отладочном режиме:

Для этого в скрипте есть блок if __name__ == "__main__" со строкой запуска отладочного сервера Flask.

Как и runserver в Django, тот тоже работает в однопоточном режиме и не справится с нагрузкой на сайт. На помощь придёт Gunicorn. Нужна функция соответствующая WSGI-протоколу.

Объект app во Flask-скрипте ведёт себя подобно функции – его можно запустить, передав аргументы:

Чтобы запустить сайт Flask через Gunicorn достаточно выполнить команду:

server — название модуля без .py , app — функция в скрипте.

Как видите, запустить Flask-проект через Gunicorn очень легко.

Что почитать

Попробуйте бесплатные уроки по Python

Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.

Читайте также: