Как перезапустить django на сервере ubuntu

Обновлено: 06.07.2024

Наше развертывание мы разделим на два этапа:

Установка и настройка среды Python и UWSGI.
Настройка веб-сервера NGINX.

Рассмотрим эти процессы по шагам.

Python, Django и UWSGI

Устанавливаем необходимые пакеты:

apt-get install nginx uwsgi python3 uwsgi-plugin-python3 python3-pip python3-dev build-essential libssl-dev libffi-dev python3-setuptools

Устанавливаем пакеты для Python:

pip3 install virtualenv uwsgi django

Создаем директорию для хранения стачичных файлов (css, js, img):

mkdir -p /var/www/my_app/static /var/www/my_app/media

chown www-data.www-data /var/www/my_app/media

chown www-data.www-data /var/www/my_app/static

Копируем наше приложение в папку /var/www/my_app, структура должна получиться примерно такой:

Вносим изменения в конфигурационный файл нашего проекта:

ALLOWED_HOSTS — разрешенные доменные имена, на которых должен открываться наш сайт.
DATABASES — данные для подключения к базе данных. Подробнее, данная настройка описана ниже.

Запускаем команду для сбора всех статических файлов в нашем проекте (из корня проекта):

[uwsgi]
chdir = var/www/my_app
env = DJANGO_SETTINGS_MODULE=project.settings.production
wsgi-file = my_app/wsgi.py
workers = 1max-requests=5000
plugins=python3
processes = 5
threads = 2
master = true
die-on-term = true
socket = sedova.sock
chmod-socket = 660
vacuum = true
uid = www-data
gui = www-data

chdir — указываем директорию нашего проекта.
env — конфигурационный файл нашего приложения.
wsgi-file — относительный путь до файла wsgi.py нашего приложения.

Перезапускаем сервис uwsgi:

service uwsgi restart

Настройка Nginx

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

Содержимое файла должно быть примерно следующим:

server listen 80;
server_tokens off;
server_name my_app my_app.domain.local;

location / include uwsgi_params;
uwsgi_pass unix:///run/uwsgi/app/sedova/socket;
>

location /static/ alias /var/www/my_app/static/;
>

location /media/ alias /var/www/my_app/media/;
>
>

systemctl restart nginx

Подключение к базе данных

Рассмотрим пример настройки подключения к СУБД MariaDB/MySQL. Нам необходимо будет настроить как сам сервер баз данных, так и фреймворк. В инструкции опишем полный процесс, начиная от установки СУБД.

MariaDB

Выполним установку и настройку сервера баз данных. Начнем с установки:

apt-get install mariadb-server

Разрешаем автозапуск СУБД:

systemctl enable mariadb

Зададим пароль для учетной записи mysql-root:

mysqladmin -u root password

Установка и запуск завершены. Перейдем к настройке.

Для Django важно, чтобы кодировка была UTF-8. Откроем конфигурационный файл клиента:

[mysql]
.
default-character-set = utf8

Аналогичную настройку выполняем в следующем файле:

[mysql]
.
default-character-set = utf8

Редактируем файл для настройки сервера:

Задаем значения для опций:

character-set-server = utf8
collation_server = utf8_unicode_ci

Для применения настроек перезапускаем сервис:

systemctl restart mariadb

Подготовка базы данных

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

Не забываем также настроить права доступа на базу.

Установка модуля для Python

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

apt-get install libmysqlclient-dev

pip3 install mysqlclient

Первая команда установит библиотеки, необходимые для установки mysqlclient через менеджер пакетов Python. Вторая, собственно, и установит клиента.

Настройка подключения

Откроем конфигурационный файл нашего приложения:

Данная настройка прописывается, как правило, по умолчанию и позволяет использовать базу sqlite3. Поменяем ее:

* в данном примере:

NAME — имя базы данных, к которой мы подключимся.
HOST — сервер баз данных.
USER — пользователь с привилегиями работы с базой данных.
PASSWORD — пароль для пользователя.

Делаем выборку

Для проверки настройки создадим select-запрос с нашей базе. Предположим, к таблице users. Пример кода будет таким:

from django.db import connection
cursor = connection.cursor()
cursor.execute("SELECT * FROM users")
print(cursor.fetchall())

В данном примере мы извлечем все содержимое таблицы users и выведем это на экран.

когда я делаю модификацию в исходном файле python в своем проекте, Django обнаруживает это и перезапускает сам runserver. Но когда я изменяю шаблон django, я должен убить runserver и перезапустить его снова : как я могу сделать, чтобы runserver перезапустился автоматически при изменении шаблона ?

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

есть загрузчик шаблонов кэширования, но по умолчанию он отключен. См.документация для получения дополнительной информации.

чтобы добавить к ответу кнутина, проблема, с которой вы столкнулись, точно вызвана FetchFromCacheMiddleware, поэтому все, что вам нужно сделать, это отключить его в settings.py файл выглядит следующим образом:

выполнить touch против одного из исходных файлов Python.

, потому что runserver мониторы .py-файлы для изменений, он не перезапускается для изменения шаблонов (.формат HTML.) Вы можете запустить этот перезапуск, практически отредактировав любой из них .py файлы с помощью touch команда, которая обновляет свою измененную дату и оставляет все остальное содержимое одинаковым.

У меня была аналогичная проблема, однако мои шаблоны требовали запуска скрипта django manager для их обновления. Нет простого способа заставить django смотреть другие типы файлов, но вот работа, которую я использую.

это автономный скрипт, который я теперь использую для запуска dev-сервера:

этот скрипт работает при следующих предположениях:

используя питон3
этот сценарий помещается вдоль стороны manager.py
manager.py является runnable
веб-приложение называется веб-сайт
на веб-сайте есть файл под названием website/urls.py
вы используете GNU / Linux, который поддерживает inotify

вам не нужно перезапускать сервер, чтобы перезагрузить изменения шаблона.

в производстве вы можете сделать это:
В settings.py, для шаблонов config
- Удалите параметр APP_DIRS
- Вместо этого добавьте этот параметр в OPTIONS:

почему это работает:
По умолчанию параметр DEBUG имеет значение True (в режиме разработки). В этом режиме Django не кэширует шаблоны. Но в производственном режиме (т. е. DEBUG = False) Django включает шаблон кэширование. Следовательно, перезапуск сервера необходим для перезагрузки отредактированного / затронутого шаблона.

Примечание:
Помните о том, что-отключив кэширование шаблонов на вашей производственной машине, вы добавите накладные расходы для каждого запроса, который проходит.

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

отключить кэшированный загрузчик шаблонов

загрузчик кэшированных шаблонов по умолчанию не включен, но вы могли бы включить это в настройках производства. Убедитесь, что загрузчик кэшированных шаблонов не включен в настройках разработки. документы Django на загрузчике кэшированных шаблонов

использовать манекен кэширование базы

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

другое решение - убедиться, что у вас есть debug значение true внутри вас TEMPLATES config в settings.py

, когда debug is False вы должны вручную перезапустить сервер, чтобы увидеть любые изменения, внесенные в шаблоны (так как они не запускают автоматический перезапуск)

В этом туториале вы сами развернёте небольшой сайт в production-режиме с помощью Nginx + Gunicorn, совсем как крутые бородатые дядьки-программисты. Сайт тоже будет непростой: он будет состоять сразу из двух фреймворков, Django и Flask. То есть развернуть нужно будет как бы сразу два сайта

В итоге вы получите сайт, который показывает юзерам их IP-адрес:

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

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

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

Сервер с ОС Ubuntu 20.04 LTS
Python3

1. Запустите проект на сервере

Перед тем как работать с Nginx/Gunicorn, стоит хоть раз запустить сайт на сервере. А то вдруг вам подсунули нерабочие исходники?

Подключитесь к своему серверу и подготовьте его к установке пакетов Python:

Скачайте на сервер код проекта и установите его зависимости:

2. Запустите сайт на Flask

В репозитории с кодом есть насколько папок. В одной из них лежит проект на Flask. Раз уж вы собрались запускать всё по-взрослому, то давайте использовать не отладочный сервер, а Gunicorn:

Вместо ip 206.189.61.169 подставьте ip вашего сервера.

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

Есть ещё один нюанс: стоит вам только закрыть терминал, и сайт сразу упадёт. Неужели теперь нельзя выключать компьютер? И что толку от сервера? Нужно ваш Flask демонизировать с помощью systemd .

Для этого создайте новый юнит-файл: /etc/systemd/system/flask.service . Вот готовый конфиг для этого юнита. Осталось только его скопировать.

Зайдите на сайт, и проверьте, что он продолжает работу:

4. Запустите Django

Сайт не ограничивается Flask’ом, нужно запустить ещё и Django. Причём, параллельно, одновременно с Flask.

Откройте новый терминал и снова подключитесь к серверу:

Так как порт 8080 уже занят частью сайта на Flask, Django будет жить на 8081 :

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

В README проекта указана дополнительная настройка DJ_ALLOWED_HOSTS . Нужно её заполнить, чтобы Django не переживала:

Django отвечает за API сайта, оно находится по ссылке 206.189.61.169:8081/api/ip/. Проверьте, что оно работает:

5. Демонизируйте Django

Так же как и с Flask, стоит запустить Django из systemd , чтобы она не выключилась, когда вы выйдите с сервера. Создайте файл с конфигом для /etc/systemd/system/django.service и добавьте в него второй кофиг, уже для Django.

После этого остаётся только включить django.service :

Зайдите на сайт и проверьте, что он работает: 206.189.61.169:8081/api/ip/.

6. Добавьте Nginx

Установите на сервер Nginx

206.189.61.169:80 – Nginx
206.189.61.169:8080 – Flask
206.189.61.169:8081 – Django

Получился странный сайт: пользователям надо вбивать какие-то порты, чтобы попасть на нужный веб-сервер. Очевидно, в жизни так никто делать не будет. Нужно как-то их “объединить”, чтобы пользователь просто заходил на сайт, а всю возню с портами за него делал кто-то другой.

Для начала “объединим” два первых сервера, Nginx и Flask, в один. Сделаем так, чтобы все пользователи общались только с Nginx, а о существовании Flask даже не догадывались. Такая схема работы называется reverse proxy:

Ждём запроса от клиента
“Пересылаем” запрос клиента в Gunicorn
Ждём ответа от Gunicorn
“Пересылаем” ответ Gunicorn клиенту

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

Реализуем схему, как на иллюстрации выше. Для этого создадим новый файл конфигурации Nginx /etc/nginx/sites-enabled/myip-multi-framework .

Конфиг состоит буквально из нескольких строк кода. Давайте разберём их по частям.

Первая строка сообщает Nginx о том, чтобы он применил все эти настройки к запросам, прилетающим на порт 80 по адресу 206.189.61.169 :

Последняя строка заставляет Nginx “пересылать” все запросы на порт 8080 к Gunicorn и Flask:

Настройки для Nginx готовы. Применим их:

Теперь на стандартном 80 порту отображается не приветствие Nginx, а сервис MyIP:

7. Почините reverse proxy

Обратите внимание на то, какой IP адрес отображает страница сайта. Это же не ваш IP, это адрес сервера! Давайте разберёмся с этим.

В стандартной поставке у Nginx уже есть такие настройки, достаточно их подключить:

Проверяем работу сайта. Теперь IP клиента будет отличаться от адреса сервера:

8. Подключите Django

Теперь тот же трюк проворачиваем с Django. Из всех запросов к Nginx выделим не запросы, чьи адреса начинаются с префикса /api/ , и “перешлём” их к Django.

Добавляем в конфиг Nginx новый раздел для Django:

Обратите внимание, что для входящего запроса Nginx выбирает подходящий location , ориентируясь не на порядок следования настроек, а на их специфичность. Чем точнее в location описана схема адресов, тем выше у неё приоритет. Блок настроек внутри location / будет срабатывать только если не найдётся ничего другого, более подходящего. Подробнее про специфичность читайте в документации Nginx.

В настройках есть ещё одна особенность. В proxy_pass для Gunicorn указан не только хост и порт 206.189.61.169:8081 , но и префикс адреса /api/ :

Вот что здесь происходит. Положим, клиент прислал в Nginx запрос на адрес /api/docs/ . Подходящие настройки для запроса нашлись внутри location /api/ , и поэтому Nginx сразу отсёк от исходного адреса указанный префикс /api/ : /api/docs/ —> /docs/ . Если ничего не предпринять, то Gunicorn получит запрос на новый адрес /docs/ вместо исходного /api/docs/ .

На сайте должно было заработать API. Перейдите по ссылке в верхнем меню, чтобы проверить работу Django:

Заходим на страницу с IP и проверяем, что адрес отображается наш, а не сервера:

9. Спрячьте Gunicorn

На сервере крутятся сразу три веб-сервера – один Nginx и два Gunicorn. И все они доступны из внешнего мира. Пользователь сайта может сам выбрать к кому из них обратиться: к Nginx на порту 80, или к Gunicorn на портах 8080 и 8081. Пользы от такой свободы нет, а вот риски возрастают:

Gunicorn куда более уязвим к DoS атакам, чем Nginx
Путаница в адресах приведёт к путанице в ссылках
Механизмы защиты, встроенные в Nginx можно легко обойти, обратившись напрямую к Gunicorn

Gunicorn можно полностью спрятать от пользователя, перевесив его с публичного адреса 206.189.61.169 на внутренний 127.0.0.1 .

127.0.0.1 - это IP-адрес, также называемый «локальный хост». Этот адрес используется для установления IP-соединения с той же машиной или компьютером, на которой запущена программа. Если у компьютера отключить интернет, то адрес 127.0.0.1 всё равно будет доступен.

Порты оставим те же, заменим только адреса 206.189.61.169 —> 127.0.0.1 . Изменения коснутся трёх файлов c настройками:

/etc/systemd/system/flask.service
/etc/systemd/system/django.service
/etc/nginx/sites-enabled/myip-multi-framework

Поменяйте эти настройки и перезапустите веб-серверы:

Теперь проверьте работу сайта. На порту 80 должны работать и главная страница сайта, и API, а на портах 8080 и 8081 браузеру никто не ответит:

10. Подключите статику

На сайте MyIP есть несколько картинок, но загрузить их с сервера браузер не может. Проблема хорошо заметна в консоли браузера:

Проблемы возникают при загрузке двух файлов:

Эти файлы logo.jpg и background.svg есть в репозитории проекта. Лежат они в каталоге static .

С раздачей файлов статики лучше прочих справляется Nginx. Он был создан для этого, поэтому логично поручить раздачу статики ему, а не Gunicorn.

Добавьте в настройки Nginx ещё один location для обработки файлов статики:

В шапке сайта появится иконка и изменится фон:

Другие статьи на эту тему

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

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

Рано или поздно вы приходите к тому, что надо запустить проект на сервере. Этот туториал покажет как превратить любой 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

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