Развертывание приложения Web.py с WSGI, несколькими серверами
Я создал web.py приложение, и теперь, когда это готово быть развернутым, я хочу работать в не на встроенном веб-сервере web.py. Я хочу смочь выполнить его на различных веб-серверах, Apache или IIS, не имея необходимость изменять мой код приложения. Это - то, где WSGI, как предполагается, входит, если я понимаю это правильно.
Однако я не понимаю, какой exacly я должен сделать для подавания моей заявки, развертываемой на сервере WSGI? Большинство примеров предполагает использование Pylons/Django/other-framework на котором Вы просто выполняете некоторую волшебную команду, которая фиксирует все для Вас.
Из того, что я понимаю (довольно краткой) web.py документации вместо выполнения web.application(...).run(), Я должен использовать web.application(...).wsgifunc(). И затем что?
3 ответа
То, что вам нужно сделать, чтобы разместить его с помощью определенного механизма хостинга WSGI, зависит от сервера.
В случае Apache / mod_wsgi и Phusion Passenger вам просто нужно предоставить Файл сценария WSGI, который содержит объект под названием «приложение». Для web.py 0.2 это результат вызова web.wsgifunc () с соответствующими аргументами. Для web.py 0.3 вместо этого вы используете функцию-член wsgifunc () объекта, возвращаемого функцией web.application (). Подробнее см. Документацию по mod_wsgi:
http://code.google.com/p/modwsgi/wiki/IntegrationWithWebPy
Если вместо этого вам нужно использовать адаптеры FASTCGI, SCGI или AJP для такого сервера, как Lighttpd , nginx или Cherokee, то вам нужно использовать пакет flup, чтобы обеспечить мост между этими языково-независимыми интерфейсами и WSGI. Это включает в себя вызов функции flup с тем же объектом приложения WSGI выше, который что-то вроде mod_wsgi или Phusion Passenger может использовать напрямую без необходимости в мосте. Подробнее об этом см.
http://trac.saddi.com/flup/wiki/FlupServers
Важно структурировать ваше веб-приложение так, чтобы оно находилось в собственном автономном наборе модулей. Для работы с конкретным сервером создайте отдельный файл сценария, если это необходимо, чтобы связать то, что требуется этому серверу, и кодом вашего приложения. Код вашего приложения всегда должен находиться за пределами каталога документов веб-сервера, и только файл сценария, который действует как мост, при необходимости может находиться в каталоге документов сервера.
Подробнее об этом см.http://trac.saddi.com/flup/wiki/FlupServers
Важно структурировать ваше веб-приложение так, чтобы оно находилось в собственном автономном наборе модулей. Для работы с конкретным сервером создайте отдельный файл сценария, если это необходимо, чтобы связать то, что требуется этому серверу, и кодом вашего приложения. Код вашего приложения всегда должен находиться за пределами каталога документов веб-сервера, и только файл сценария, который действует как мост, при необходимости может находиться в каталоге документов сервера.
Подробнее об этом см.http://trac.saddi.com/flup/wiki/FlupServers
Важно структурировать ваше веб-приложение так, чтобы оно находилось в собственном автономном наборе модулей. Для работы с конкретным сервером создайте отдельный файл сценария, если это необходимо, чтобы связать то, что требуется этому серверу, и кодом вашего приложения. Код вашего приложения всегда должен находиться за пределами каталога документов веб-сервера, и только файл сценария, который действует как мост, при необходимости может находиться в каталоге документов сервера.
затем при необходимости создайте отдельный файл сценария, чтобы соединить то, что требуется этому серверу, и код вашего приложения. Код вашего приложения всегда должен находиться за пределами каталога документов веб-сервера, и только файл сценария, который действует как мост, при необходимости может находиться в каталоге документов сервера. затем при необходимости создайте отдельный файл сценария, чтобы соединить то, что требуется этому серверу, и код вашего приложения. Код вашего приложения всегда должен находиться за пределами каталога документов веб-сервера, и только файл сценария, который действует как мост, при необходимости может находиться в каталоге документов сервера.По состоянию на 21 июля 2009 г. на сайте установки webpy есть гораздо более полное руководство по установке, в котором обсуждаются flup , fastcgi , apache и другие. Я еще не пробовал , но похоже, что он намного более подробный.
Вот пример двух размещенных приложений, использующих сервер cherrypy wsgi:
#!/usr/bin/python
from web import wsgiserver
import web
# webpy wsgi app
urls = (
'/test.*', 'index'
)
class index:
def GET(self):
web.header("content-type", "text/html")
return "Hello, world1!"
application = web.application(urls, globals(), autoreload=False).wsgifunc()
# generic wsgi app
def my_blog_app(environ, start_response):
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world! - blog\n']
"""
# single hosted app
server = wsgiserver.CherryPyWSGIServer(
('0.0.0.0', 8070), application,
server_name='www.cherrypy.example')
"""
# multiple hosted apps with WSGIPathInfoDispatcher
d = wsgiserver.WSGIPathInfoDispatcher({'/test': application, '/blog': my_blog_app})
server = wsgiserver.CherryPyWSGIServer(('0.0.0.0', 8070), d)
server.start()