Wsgi python что это

Обслуживание приложений Flask с uWSGI и Nginx в Ubuntu 18.04

Published on January 7, 2020

Введение

В этом обучающем модуле вы создадите приложение Python с использованием микроструктуры Flask в Ubuntu 18.04. Основная часть этой статьи посвящена настройке сервера приложений uWSGI, запуску приложения и настройке Nginx для работы в режиме обратного прокси-сервера фронтенда.

Предварительные требования

Перед началом прохождения этого обучающего модуля вам потребуется следующее:

Доменное имя, настроенное так, чтобы указывать на ваш сервер. Вы можете приобрести его на Namecheap или получить бесплатно на Freenom. Вы можете узнать, как указывать домены на DigitalOcean, из соответствующей документации по доменам и DNS. Обязательно создайте следующие записи DNS:

Знакомство с нашим сервером приложений uWSGI и спецификацией WSGI. В этом обсуждении определений и концепций о них рассказывается более подробно.

Шаг 1 — Установка компонентов из хранилищ Ubuntu

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

Шаг 2 — Создание виртуальной среды Python

Теперь мы настроим виртуальную среду, чтобы изолировать наше приложение Flask от других файлов Python в системе.

Затем создадим родительский каталог для нашего проекта Flask. Перейдите в каталог после его создания:

Создайте виртуальную среду для хранения требований Python для вашего проекта Flask, введя следующую команду:

Локальные копии Python и pip будут установлены в каталог myprojectenv в каталоге вашего проекта.

Прежде чем устанавливать приложения в виртуальной среде, ее нужно активировать. Для этого нужно ввести следующую команду:

Командная строка изменится, показывая, что теперь вы работаете в виртуальной среде. Она будет выглядеть примерно так: ( myprojectenv ) user @ host :

Шаг 3 — Настройка приложения Flask

Находясь в виртуальной среде, вы можете установить Flask и uWSGI и начать работу над созданием вашего приложения.

Примечание. Если виртуальная среда активна, то вне зависимости от того, какую версию Python вы используете, вы должны использовать команду pip (а не pip3 ).

Затем установим Flask и uWSGI:

Создание образца приложения

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

Хотя ваше приложение может быть более сложным, мы создадим наше приложение Flask в одном файле с именем myproject.py :

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

Здесь определяется, какой контент должен выводиться при доступе к корневому домену. Сохраните файл и закройте его после завершения.

Если вы следовали указаниям модуля по начальной настройке сервера, у вас должен быть включен брандмауэр UFW. Чтобы протестировать приложение, вам нужно разрешить доступ к порту 5000 :

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

Вы увидите следующий результат, в том числе полезное предупреждение, напоминающее не использовать эти настройки сервера в реальной работе:

Откройте в браузере IP-адрес вашего сервера с суффиксом :5000 :

Вы увидите примерно следующее:

Wsgi python что это. Смотреть фото Wsgi python что это. Смотреть картинку Wsgi python что это. Картинка про Wsgi python что это. Фото Wsgi python что это

Когда вы закончите, нажмите CTRL+C в окне терминала, чтобы остановить сервер разработки Flask.

Создание точки входа WSGI

Теперь создадим файл, который будет служить точкой входа в наше приложение. Это покажет серверу uWSGI, как с ним взаимодействовать.

Мы назовем этот файл wsgi.py :

Сейчас мы импортируем экземпляр Flask из нашего приложения в этот файл и запустим его:

Сохраните файл и закройте его после завершения.

Шаг 4 — Настройка uWSGI

Ваше приложение написано, и для него создана точка входа. Теперь мы можем перейти к настройке uWSGI.

Тестирование обслуживания uWSGI

Проверим способность uWSGI обслуживать наше приложение.

Теперь вы снова увидите результат выполнения вашего приложения:

Wsgi python что это. Смотреть фото Wsgi python что это. Смотреть картинку Wsgi python что это. Картинка про Wsgi python что это. Фото Wsgi python что это

Убедившись в его нормальной работе, нажмите CTRL+C в окне терминала.

Мы закончили работу с виртуальной средой, и теперь можем отключить ее:

Теперь любые команды Python снова будут использовать системную среду Python.

Создание файла конфигурации uWSGI

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

Поместим этот файл в каталоге нашего проекта и назовем его myproject.ini :

Затем мы укажем uWSGI начать работу в режиме мастера и создать пять рабочих процессов для обслуживания фактических запросов:

Также изменим разрешения сокета. Позднее мы сделаем группу Nginx владельцем процесса uWSGI, и поэтому нужно сделать так, чтобы владелец группы сокета мог считывать из нее информацию и записывать в нее информацию. Также мы выполним очистку сокета после остановки процесса, для чего используем опцию vacuum :

После завершения редактирования сохраните и закройте файл.

Шаг 5 — Создание файла элементов systemd

Далее мы созадим файл служебных элементов systemd. Создание файла элементов systemd позволит системе инициализации Ubuntu автоматически запускать uWSGI и обслуживать приложение Flask при загрузке сервера.

Мы начнем с раздела [Unit] этого файла, где указываются метаданные и зависимости. Здесь мы разместим описание службы и предпишем системе инициализации запускать ее только после достижения сетевой цели:

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

Теперь служебный файл systemd готов. Сохраните и закройте его.

Теперь мы запустим созданную службу uWSGI и активируем ее запуск при загрузке системы:

Теперь проверим состояние:

Результат должен выглядеть следующим образом:

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

Шаг 6 — Настройка Nginx для работы с запросами прокси-сервера

Сохраните файл и закройте его после завершения.

Чтобы активировать созданную конфигурацию серверных блоков Nginx, необходимо привязать файл к каталогу sites-enabled :

Когда этот файл будет в данном каталоге, мы сможем провести проверку на ошибки синтаксиса с помощью следующей команды:

Если ошибок обнаружено не будет, перезапустите процесс Nginx для чтения новой конфигурации:

Теперь у вас должна быть возможность открыть доменное имя вашего сервера в браузере:

Вы должны увидеть результат выполнения вашего приложения:

Wsgi python что это. Смотреть фото Wsgi python что это. Смотреть картинку Wsgi python что это. Картинка про Wsgi python что это. Фото Wsgi python что это

Если будут обнаружены любые ошибки, проверьте следующее:

Шаг 7 — Защита приложения

Чтобы обеспечить защиту трафика вашего сервера, необходимо получить сертификат SSL для вашего домена. Этого можно добиться несколькими способами, в том числе получить бесплатный сертификат от Let’s Encrypt, сгенерировать сертификат с собственной подпись ю или приобрести сертификат у другого поставщика и настроить Nginx для его использования, для чего потребуется выполнить шаги с 2 по 6 обучающего модуля Создание сертификата SSL с собственной подписью для Nginx в Ubuntu 18.04. Для удобства мы выберем первый вариант.

Вначале добавьте хранилище Certbot Ubuntu:

Вам нужно будет нажать ENTER для подтверждения.

Затем установите пакет Certbot Nginx с apt :

Certbot предоставляет широкий выбор способов получения сертификатов SSL с помощью плагинов: Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется. Для использования этого плагина введите следующую команду:

Если это будет подтверждено, certbot запросит у вас предпочитаемый вариант настройки HTTPS:

Если вы следовали инструкциям по установке Nginx из предварительных требований, вам больше не потребуется разрешать профиль HTTP лишний раз:

Чтобы подтвердить конфигурацию, снова перейдите в свой домен, используя префикс адреса https:// :

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

Заключение

В этом обучающем модуле вы научились создавать и защищать простое приложение Flask в виртуальной среде Python. Вы создали точку входа WSGI, с которой может взаимодействовать любой сервер приложений с поддержкой WSGI, а затем настроили сервер приложения uWSGI для обеспечения этой функции. После этого вы создали служебный файл systemd, который автоматически запускает сервер приложений при загрузке. Также вы создали серверный блок Nginx, который передает трафик веб-клиента на сервер приложений, перенаправляет внешние запросы и защищает трафик вашего сервера с помощью сертификата Let’s Encrypt.

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

Источник

Развертывание приложений Python WSGI с помощью Gunicorn на основе Nginx

Вступление

Цель данной статьи – помочь установить и настроить все необходимые для развертывания приложения компоненты. Для начала нужно ознакомиться с особенностями HTTP-сервера Gunicorn WSGI, а затем научиться разворачивать веб-приложение Python WSGI, разработанное на основе различных фреймворков.

Примечание: чтобы получить информацию о других веб-серверах Python WSGI, читайте статью «Сравнение веб-серверов приложений на основе Python»

Что такое Gunicorn и Nginx?

Gunicorn

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

Технически Gunicorn работает подобно Unicorn, популярному веб-серверу приложений Ruby. Они оба используют так называемую pre-fork модель (это значит, что главный процесс управляет инициированными рабочими процессами различного типа, создает сокеты и соединения, и т.п.).

Особенности сервера Gunicorn

Развертывание веб-приложения с помощью Nginx

Nginx – это веб-сервер/инвертированный прокси очень высокой производительности.

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

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

Nginx как инвертированный прокси

Почему именно Nginx? Многие фреймворки и серверы приложений (в том числе и Gunicorn) могут обслуживать статические файлы (например, JavaScript, CSS, изображения и т.д.) вместе с ответами. Тем не менее, лучше установить инвертированный прокси-сервер (как Nginx), который будет обслуживать эти файлы и управлять соединениями (запросами). Это существенно снизит нагрузку на сервер приложений, тем самым улучшая общую производительность.

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

Расширяемость Nginx (то есть, кэширование наряду с отказоустойчивостью и другими механизмами) – еще одно огромное преимущество этого сервера перед более простыми серверами приложений.

Пример базовой архитектуры сервера:

Примечание: чтобы узнать необходимое количество серверов/процессов, читайте раздел «Настройка и оптимизация Gunicorn».

Подготовка сервера к производству

Данный раздел посвящен подготовке виртуального сервера к производству (то есть, к развертыванию приложения).

Примечание: здесь приведены краткие инструкции. Более подробную информацию можно получить, прочитав статью «Общие инструменты Python: использование virtualenv, установка пакетов с помощью pip и управление пакетами».

Обновление операционной системы

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

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

Для обновления систем на основе Debian (Ubuntu, Debian):

Для обновления систем на основе RHEL (CentOS):

Установка Python, pip и virtualenv

Примечание для пользователей CentOS / RHEL

По умолчанию CentOS / RHEL поставляются почти чистыми. Инструментарий на данном сервере предоставляется не для запуска приложений пользователя, а для питания инструментов системы (например, yum).

Чтобы подготовить систему CentOS, нужно установить (то есть, скомпилировать из исходного кода) Python, а затем установить pip и virtualenv при помощи специального интерпретатора.

Чтобы получить подробную информацию по установке Python 2.7.6 и 3.3.3 на CentOS 6.4 и 5.8, прочтите данную статью.

На Ubuntu и Debian последняя версия интерпретатора Python (который можно использовать) поставляется по умолчанию. Потому все, что осталось установить:

python-dev: общесистемный пакет, который содержит расширенные средства разработки для построения модулей Python

Для установки python-dev запустите:

aptitude install python-dev

pip: менеджер пакетов, который помогает устанавливать необходимые пакеты приложений.

Выполните следующие команды для установки pip:

На данном этапе могут понадобиться привилегии sudo

Virtualenv:

Приложение Python вместе со всеми его зависимостями рекомендуется хранить в отдельной среде. Проще говоря, среда – это изолированное место (каталог) для размещения пакетов веб-приложения. Для этого используется инструмент под названием virtualenv.

Чтобы установить virtualenv с помощью pip, используйте:

sudo pip install virtualenv

Создание автономный виртуальной среды Python

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

Запомните: если на (локальной) машине разработки нет virtualenv (или виртуальной среды), необходимо создать ее и переместить туда приложение и его зависимости.

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

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

Затем нужно войти в эту папку и создать в ней новую виртуальную среду:

cd my_app
virtualenv my_app_venv

Виртуальную среду также можно назвать как угодно.

Теперь создайте новую папку для модуля приложения Python:

Активируйте интерпретатор внутри виртуальной среды:

source my_app_venv /bin/activate

Пожалуйста, убедитесь в том, что заменили имя виртуальной среды «my_app_venv» именем своей venv (в случае, если она имеет другое имя).

Теперь главный каталог развертывания приложений должен выглядеть так:

my_app # Main Folder to Contain Everything Together
|
|=== my_app_venv # V. Env. folder with the Python Int.
|=== app # Your application module
|..
|.

Загрузка и установка Gunicorn

Все связанные с приложением компоненты настоятельно рекомендуется хранить внутри виртуальной среды. Потому Gunicorn также будет установлен здесь.

В случае если виртуальная среда дезактивирована, Gunicorn будет установлен общесистемно (глобально), чего делать не рекомендуется.

Чтобы установить Gunicorn с помощью pip, запустите:

pip install gunicorn

Загрузка и установка Nginx

Запустите следующую команду, чтобы установить Nginx с помощью aptitude, менеджера пакетов по умолчанию:

sudo aptitude install nginx

Для запуска Nginx используйте:

sudo service nginx start

Чтобы выключить Nginx, используйте:

sudo service nginx stop

Чтобы перезапустить Nginx:

sudo service nginx restart

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

Чтобы получить дополнительные инструкции по установке Nginx на Ubuntu, читайте статью «Установка Nginx на Ubuntu 12.04 LTS (Precise Pangolin)».

Обслуживание веб-приложений Python с помощью Gunicorn

Данный раздел демонстрирует работу WSGI-приложений с Gunicorn. Этот процесс состоит из предоставления серверу callable объекта WSGI-приложения (например, application = (..)) как точки входа.

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

Примечание: для получения дополнительной информации о WSGI и веб-серверах Python читайте статью “Сравнение веб-серверов для приложений на основе Python“.

Callable объект приложения WSGI: wsgi.py

Как уже было сказано, веб-серверам, запущенным на WSGI, необходим объект приложения.

Для большинства фреймворков и приложений он выглядит так: wsgi.py содержит и предоставляет объект приложения (или callable), который будет использоваться сервером.

Для начала создайте образец wsgi.py для использования его с Gunicorn.

Конечно, вместо имени «wsgi.py» можно выбрать любое другое имя. Но имя wsgi.py считается стандартным и используется чаще всего (например, в Django).

Итак, можно приступить к созданию файла wsgi.py, который будет содержать базовое приложение WSGI.

Чтобы создать данный файл с помощью текстового редактора nano, запустите команду:

Теперь нужно переместить (скопировать и вставить) в него базовый код приложения WSGI (замените его собственным callable приложения):

def application(env, start_response):
start_response(‘200 OK’, [(‘Content-Type’, ‘text/html’)])
return [«Hello!»]

Каждый раз, когда поступает запрос, сервер использует этот callable приложения, чтобы запустить его обработчики запросов (например, контроллеры), анализируя URL (например, mysite.tld/controller/method/variable).

Разместив код приложения в файле, нажмите CTRL+X, чтобы сохранить файл в папке my_app наряду с виртуальной средой и модулем приложения (нажмите Y для подтверждения).

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

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

my_app # Main Folder to Contain Everything Together
|
|=== my_app_venv # V. Env. folder with the Python Int.
|=== app # Your application module
|
|— wsgi.py # File containing application callable
|..
|.

Запуск сервера

Чтобы приложение обслуживалось, выполните:

Чтобы запустить сервер, используйте следующее:

Это запустит сервер в приоритетном режиме. Чтобы отключить его, нажмите клавиши CTRL + C.

Чтобы запустить сервер в фоновом режиме, выполните следующую команду:

Запуская приложение в фоновом режиме, используйте менеджер процессов (например, htop), чтобы прервать его.

Настройка и оптимизация Gunicorn

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

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

[!] Важно: Все перечисленные ниже настройки и параметры конфигураций необходимо «сцепить» (внести один за другим), чтобы запустить gunicorn и обслуживать приложение. После запуска сервера изменять настройки нельзя. Любая использованная опция должна сопровождаться файлом WSGI, содержащим точку входа в приложение.

Подсчет процессов

В целом, считается, что приложения зависят скорее от I/O, чем от CPU. Это значит, что узкое место вызвано не вычислительной мощностью виртуального сервера, а диском. Идея такова: пока один процесс занят дисковыми операциями, другой все еще использует CPU для обработки запросов.

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

Указать количество процессов можно с помощью аргумента –workers=[n].

Примечание: такой сценарий не сработает с неблокируемыми процессами.

Настройки сокетов

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

Примечание: когда приложение прослушивает входящие соединения на 127.0.0.1, доступ к нему можно получить только локально. При использовании 0.0.0.0, оно также будет принимать соединения извне.

Выбор типа процесса

Как уже было сказано, Gunicorn предоставляет возможность использовать разные типы процессов.

В большинстве случаев используется sync – стандартный процесс, установленный по умолчанию и, следовательно, не требующий подробной настройки.

Что касается других процессов – имейте в виду, их необходимо установить как зависимости.

Доступные типы процессов:

Количество одновременных подключений для процессов Eventlet / Gevent

Чтобы изменить количество одновременных подключений для процессов Eventlet и Gevent:

Журналы доступа

Чтобы явно определить файл для ведения журнала доступа:

По умолчанию данная опция имеет значение None.

Журналы ошибок

Чтобы указать файл для ведения журнала ошибок, используйте:

Уровни журналов

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

Наименование процессов

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

Настройка Nginx

Настроив и запустив Gunicorn, нужно настроить Nginx, чтобы он мог взаимодействовать с сервером Gunicorn при запуске приложения. Для этого нужно отредактировать nginx.conf, конфигурационный файл Nginx.

Чтобы открыть данный файл в редакторе nano, запустите:

sudo nano /etc/nginx/nginx.conf

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

Примечание: чтобы активировать поддрежку SSL, пожалуйста, прочтите статью «Создание SSL-сертификата на Nginx».

Пример конфигураций для веб-приложения:

Завершив редактирование конфигураций, нажмите CTRL+X, чтобы сохранить изменения и выйти, а затем Y для подтверждения.

Чтобы перезапустить Nginx:

sudo service nginx stop
sudo service nginx start

Источник

Настройка uWSGI и Nginx для обслуживания приложений Python в Ubuntu 14.04

Данное руководство поможет настроить простое приложение WSGI, обслуживаемое uWSGI. Веб-сервер Nginx используется в качестве обратного прокси-сервера для более надёжного соединения.

Примечание: Все компоненты установлены на сервер Ubuntu 14.04.

Основные понятия и подходы

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

Требования к приложениям WSGI

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

Веб-сервер (uWSGI) должен иметь возможность отправлять запросы приложению. Callable (или точка входа)– псевдотип данных, «нечто, что можно вызвать как функцию». Ожидаемым параметром является словарь с переменными окружения и точка входа веб-сервера.

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

Установка компонентов

Для начала нужно установить все необходимые программы на сервер Ubuntu 14.04. Для этого можно использовать apt и pip.

Обновите индекс пакетов и установите библиотеку разработки Python, pip (пакетный менеджер Python) и веб-сервер Nginx.

sudo apt-get update
sudo apt-get install python-dev python-pip nginx

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

sudo pip install virtualenv

После этого можно создать общую структуру приложения. Создайте виртуальное окружение и установите в него сервер приложений uWSGI.

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

Теперь создайте папку для приложения. В ней вы сможете развернуть виртуальную среду и хранить точку входа WSGI.

Откройте этот каталог:

Создайте виртуальную среду с помощью команды virtualenv (для простоты в руководстве она называется myappenv)

Теперь в каталоге myappenv развёрнуто новое окружение Python. Включите его:

После этого командная строка изменится. Это значит, что виртуальная среда активна:

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

Примечание: Если вы вышли из виртуальной среды только что, вернитесь в неё.

Когда виртуальная среда включена, все устанавливаемые приложения Python будут помещены в иерархию этого каталога. Они не смогут повлиять на общесистемные приложения Python. Теперь можно установить сервер uWSGI с помощью pip. Его пакет называется uwsgi (однако не следует путать пакет сервера uWSGI с протоколом uwsgi).

Чтобы убедиться, что установка прошла успешно, запросите версию:

Команда должна вернуть версию сервера uWSGI.

Создание приложения WSGI

Теперь нужно создать простое приложение WSGI согласно спецификации WSGI. Это приложение должно состоять из таких компонентов:

Запишите приложение в файл wsgi.py:

В этом файле будет находиться простое приложение, созданное согласно WSGI.

Важно! Вносите код, учитывая отступы.

def application(environ, start_response):

start_response(‘200 OK’, [(‘Content-Type’, ‘text/html’)])
return [«

Hello There!

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

Первый параметр называется environ и задаёт словарь переменных. Второй параметр называется start_response и сообщает точке входа веб-сервера uWSGI имя приложения.

Приложение будет выполнять два действия. Во-первых, оно вызовет точку входа, полученную с кодом состояния HTTP и заголовками. В таком случае отправляется ответ 200 ОК, а text/html получает заголовок Content-Type.

Во-вторых, приложение будет возвращать итератор в качестве тела запроса. В данном приложении используется одна строка HTML. Строки тоже относятся к итератору, но в списке uWSGI может обрабатывать целую строку при помощи одного итератора.

Такой файл, скорее всего, будет использоваться как ссылка на остальной код приложения. к примеру, Django-проекты включают файл wsgi.py по умолчанию. Он переводит запросы веб-сервера uWSGI в понятный приложению формат. Упрощенный интерфейс WSGI остаётся таким независимо от сложности самого кода приложения.

Сохраните и закройте файл.

Чтобы протестировать код, запустите uWSGI. Сервер будет использовать HTTP и прослушивать порт 8080. Передайте серверу название сценария:

Теперь посетите в браузере IP-адрес или доменное имя, задав порт 8080. На экране появится фраза:

Hello There!

Остановите сервер, нажав CTRL-C.

Теперь приложение готово. Отключите виртуальную среду:

Конфигурационный файл uWSGI

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

В этом файле нужно создать раздел кода [uwsgi]. В нём будут храниться все конфигурации. Задайте настройки самого приложения. Сервер uWSGI должен знать о местонахождении точки входа приложения.

[uwsgi] module = wsgi:application

Начальный процесс uwsgi должен быть ведущим (master) и порождать множество рабочих процессов (в данном примере 5).

[uwsgi] module = wsgi:application
master = true
processes = 5

Теперь нужно изменить протокол, с помощью которого uWSGI взаимодействует с другими компонентами. Во время тестирования был установлен протокол –protocol=http, чтобы приложение можно было просмотреть в браузере. Однако в в дальнейшем будет настроен обратный прокси-сервер Nginx, который реализует механизм проксирования uwsgi (быстрый бинарный протокол, с помощью которого uWSGI взаимодействует с другими серверами). Протокол uwsgi является протоколом uWSGI по умолчанию, потому достаточно просто не задавать протокол, чтобы сервер использовал uwsgi.

Поскольку этот конфигурационный файл должен поддерживать взаимодействие с Nginx, замените стандартный порт сокетом Unix. Это более быстрый и безопасный вариант. Сокет будет создан в текущем каталоге (в руководстве он будет называться myapp.sock). Измените права доступа к нему, указав 664, чтобы веб-сервер Nginx имел право на редактирование. Добавьте опцию vacuum, которая удалит сокет сразу после остановки процесса:

[uwsgi] module = wsgi:application
master = true
processes = 5
socket = myapp.sock
chmod-socket = 664
vacuum = true

Осталось добавить последнюю опцию, которая нужна для поддержки файла Upstart. Upstart и uWSGI по-разному воспринимают сигнал SIGTERM. Чтобы устранить эту проблему, просто добавьте опцию die-on-term.

[uwsgi] module = wsgi:application
master = true
processes = 5
socket = myapp.sock
chmod-socket = 664
vacuum = true
die-on-term = true

Сохраните и закройте файл.

Создание файла Upstart

Теперь можно настроить автозапуск uWSGI во время загрузки сервера. Поместите его в каталог /etc/init, который проверяет система Upstart (в руководстве файл называется myapp.conf).

sudo nano /etc/init/myapp.conf

Добавьте описание сервиса и установите уровни выполнения. Уровни выполнения стандартного пользователя – 2-5.

Если приложение перейдет на уровень, который не входит в этот диапазон, Upstart остановит его.

description «uWSGI instance to serve myapp»
start on runlevel [2345] stop on runlevel [!2345]

Теперь установите пользователя и группу, с помощью которых будет запущен процесс. В качестве группы можно указать www-data, чтобы сервер Nginx имел доступ к приложению.

description «uWSGI instance to serve myapp»
start on runlevel [2345] stop on runlevel [!2345] setuid demo
setgid www-data

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

Сценарий готов. Сохраните и закройте его.

Чтобы убедиться, что сервер запущен, введите:

Теперь сервис будет автоматически загружаться вместе с системой. Чтобы остановить сервис, введите:

Nginx как обратный прокси-сервер для uWSGI

Итак, теперь приложение WSGI работает и поддерживается сервером uWSGI. Также сервис запускается автоматически при помощи Upstart. Процесс uWSGI прослушивает сокет и взаимодействует с протоколом uwsgi.

Теперь нужно настроить Nginx как обратный прокси-сервер. Nginx может проксировать запросы при помощи протокола uwsgi для взаимодействия с uWSGI. Этот протокол быстрее, чем HTTP.

Настройка Nginx очень проста. Нужно только создать новый файл в каталоге sites-available в иерархии Nginx (имя файла должно совпадать с именем приложения, потому в руководстве файл называется myapp).

sudo nano /etc/nginx/sites-available/myapp

В этом файле нужно задать номер порта и доменное имя, к которому относится данный блок server. В данном случае используется стандартный порт 80.

server <
listen 80;
server_name server_domain_or_IP;
>

Чтобы приложение WSGI могло отправлять все запросы на этот домен или IP, нужно создать блок location для запросов, которые начинаются с / (это соответствует всем запросам). Добавьте в него директиву include, чтобы внести ряд параметров по умолчанию из конфигурационного каталога Nginx. Этот файл называется uwsgi_params. После этого нужно передать трафик приложению uWSGI через протокол uwsgi. Для этого используется сокет unix.

server <
listen 80;
server_name server_domain_or_IP;
location / <
include uwsgi_params;
uwsgi_pass unix:/home/demo/myapp/myapp.sock;
>
>

Этих настроек достаточно для поддержки простого приложения. Сложным приложениям нужна более тонкая настройка (например, можно определить количество upstream-серверов uWSGI вне этого блока, добавить больше параметров uWSGI, настроить обработку статических файлов Nginx и передавать uWSGI только динамические запросы). В данном случае такие сложные функции не нужны. Просто сохраните и закройте файл.

Чтобы привести новые параметры в исполнение, создайте символьную ссылку на каталог sites-enabled.

Проверьте конфигурационный файл на наличие ошибок:

sudo service nginx configtest

Если в файле нет ошибок, перезапустите веб-сервер:

sudo service nginx restart

После этого откройте в браузере доменное имя или IP (без номера порта). На экране появится:

Hello There!

Заключение

Теперь у вас есть полностью рабочее простое приложение WSGI. Его можно использовать как шаблон для создания более сложного приложения.

uWSGI может управлять несколькими приложениями, для этого используется так называемый «emperor mode». Вы можете расширить настройки Nginx, добавив балансировку нагрузки. Все компоненты достаточно гибкие, их можно настроить согласно требованиям вашего приложения.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *