Як веб-рамки Python, WSGI та CGI вписуються разом

У мене є обліковий запис Bluehost, де я можу запускати сценарії Python як CGI. Я думаю, що це найпростіший CGI, тому що для запуску я повинен визначити наступне в .htaccess:

Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py

Тепер, коли я переглядаю веб-програмування з Python, я чую багато про WSGI та те, як більшість фреймворків використовують його. Але я просто не розумію, як це все підходить разом, особливо коли мій веб-сервер дається (Apache працює на машині хоста), і не те, з чим я справді можу грати (крім визначення .htaccessкоманд).

Як пов’язані WSGI , CGI та рамки? Що мені потрібно знати, встановити та зробити, якщо я хочу запустити веб-фреймворк (скажімо, web.py чи CherryPy ) на своїй базовій конфігурації CGI? Як встановити підтримку WSGI?

Як WSGI, CGI та рамки пов'язані між собою?

Apache прослуховує порт 80. Він отримує HTTP-запит. Він аналізує запит, щоб знайти спосіб відповісти. Apache має багато варіантів для відповіді. Один із способів відповісти - використовувати CGI для запуску сценарію. Ще один спосіб відповісти - просто подати файл.

У випадку CGI Apache готує середовище та викликає сценарій через протокол CGI. Це стандартна ситуація Unix Fork / Exec - підпроцес CGI успадковує середовище ОС, включаючи сокет і stdout. Підпроцес CGI пише відповідь, яка повертається до Apache; Apache надсилає цю відповідь браузеру.

CGI примітивний і дратівливий. Переважно тому, що він розщеплює підпроцес для кожного запиту, а підпроцес повинен вийти або закрити stdout та stderr, щоб означати кінець відповіді.

WSGI - це інтерфейс, який базується на шаблоні дизайну CGI. Це не обов'язково CGI - він не повинен розщедрити підпроцес для кожного запиту. Це може бути CGI, але цього не повинно бути.

WSGI додає до дизайну CGI декілька важливих способів. Він аналізує заголовки запитів HTTP для вас і додає їх у середовище. Він постачає будь-який POST-орієнтований вхід як файлоподібний об'єкт у середовищі. Він також пропонує вам функцію, яка буде формулювати відповідь, рятуючи вас від безлічі деталей форматування.

Що мені потрібно знати / встановити / зробити, якщо я хочу запустити веб-фреймворк (скажімо, web.py чи вишневий) у своїй базовій конфігурації CGI?

Нагадаємо, що розгортання підпроцесу коштує дорого. Є два шляхи вирішити це.

1. Вбудований mod_wsgi або mod_pythonвбудований Python всередині Apache; жоден процес не розщеплений. Apache запускає програму Django безпосередньо.

2. Демон mod_wsgi або mod_fastcgiдозволяє Apache взаємодіяти з окремим демоном (або "тривалим процесом"), використовуючи протокол WSGI. Ви запускаєте свій тривалий процес Django, потім налаштовуєте Apache mod_fastcgi для спілкування з цим процесом.

Зверніть увагу, що mod_wsgiможе працювати в будь-якому режимі: вбудований або демон.

Коли ви читаєте на mod_fastcgi, ви побачите, що Django використовує флюп для створення WSGI-сумісного інтерфейсу з інформації, наданої mod_fastcgi. Трубопровід працює так.

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

Django має кілька "django.core.handlers" для різних інтерфейсів.

Для mod_fastcgi, Django забезпечує manage.py runfcgiте, що інтегрує FLUP та обробник.

Для mod_wsgi для цього є основний обробник.

Як встановити підтримку WSGI?

Дотримуйтесь цих інструкцій.

https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki

Для фону дивіться це

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index

Я думаю , що відповідь Флоріана відповідає частині вашого запитання про "що таке WSGI", особливо якщо ви читаєте PEP .

Щодо питань, які ви ставите до кінця:

WSGI, CGI, FastCGI і т. Д. - всі протоколи веб-сервера для запуску коду та доставки динамічного контенту, який створюється. Порівняйте це зі статичним веб-сервісом, де звичайний HTML-файл в основному доставляється як клієнту.

CGI, FastCGI та SCGI - це мовний агностик. Ви можете писати CGI-скрипти в Perl, Python, C, bash, що завгодно. CGI визначає, який виконуваний файл буде викликатися на основі URL-адреси, і як він буде називатися: аргументи та середовище. Він також визначає, як повернене значення має бути передано назад на веб-сервер, коли ваш виконаний файл буде закінчений. Варіанти - це в основному оптимізація, щоб можна було обробляти більше запитів, зменшувати затримку тощо; основне поняття те саме.

WSGI - це лише Python. Замість мовного агностичного протоколу визначається стандартний підпис функції:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

Це повний (якщо обмежений) додаток WSGI. Веб-сервер з підтримкою WSGI (наприклад, Apache з mod_wsgi) може викликати цю функцію кожного разу, коли надійде запит.

Причина цього настільки велика, що ми можемо уникнути безладного кроку перетворення з HTTP GET / POST в CGI до Python і знову повернутися на вихід. Це набагато більш прямий, чистий та ефективний зв'язок.

Це також значно спрощує наявність тривалих фреймворків, що працюють за веб-серверами, якщо все, що потрібно зробити для запиту, - це виклик функції. За допомогою звичайного CGI вам доведеться запускати весь каркас для кожного окремого запиту.

Щоб мати підтримку WSGI, вам потрібно буде встановити модуль WSGI (наприклад, mod_wsgi ) або використовувати веб-сервер із запеченим WSGI (наприклад, CherryPy ). Якщо жодне з цих варіантів неможливо, ви можете використовувати міст CGI-WSGI, вказаний у PEP.

Ви можете запустити WSGI через CGI, як Pep333 демонструє як приклад. Однак кожен раз, коли виникає запит, запускається новий інтерпретатор Python, і потрібно будувати весь контекст (підключення до бази даних тощо), який вимагає часу.

Найкраще, якщо ви хочете запустити WSGI, було б, якщо ваш хост встановив mod_wsgi і зробив відповідну конфігурацію, щоб відкласти контроль для вашої програми.

Flup - це ще один спосіб роботи з WSGI для будь-якого веб-сервера, який може говорити FCGI , SCGI або AJP. З мого досвіду справді працює лише FCGI, і його можна використовувати в Apache або через mod_fastcgi, або якщо ви можете запустити окремий демон Python з mod_proxy_fcgi .

WSGI - це протокол, подібний до CGI, який визначає набір правил взаємодії веб-сервера та коду Python, визначається як Pep333 . Це робить можливим, що багато різних веб-серверів можуть використовувати безліч різних фреймворків та програм, використовуючи один і той же протокол програми. Це дуже корисно і робить його таким корисним.

Якщо вам не зрозуміло всі терміни в цьому просторі, і ви можете зіткнутися з цим, його заплутаною абревіатурою, є також хороший фоновий читач у формі офіційного пітона HOWTO, який обговорює CGI проти FastCGI проти WSGI і так далі on: http://docs.python.org/howto/webservers.html

Це простий шар абстракції для Python, схожий на те, що специфікація сервлетів для Java. У той час як CGI дійсно низький рівень і просто скидає речі в процесне середовище і стандартний вхід / вихід, вищевказані дві характеристики моделюють запит і відповідь http як конструкції на мові. Однак моє враження полягає в тому, що в Python люди не дуже розібралися з де-факто реалізаціями, тому у вас є суміш реалізованих посилань та інших бібліотек типу утиліти, які надають інші речі поряд із підтримкою WSGI (наприклад, Paste). Звичайно, я можу помилитися, я новачок в Python. Спільнота "веб-сценаріїв" вирішує проблему з іншого напрямку (спільний хостинг, спадщина CGI,