Публикации с меткой «hosting»

1. Поддержка питона 3.1 и выше.
2. Опции «process-group», «application-group», «callable-object» и «pass-authorization» могут быть размещены в директивах WSGIscriptAlias и WSGIscriptAliasMatch
3. Если клиент обрывает соединение в процессе обработки итератора вместо «бросания исключения» теперь записывается отладочное сообщение в лог
4. В директиву WSGIDaemonProcess добавлена опция «chroot», позволяющая запускать приложения более изолированно
5. Добавлена глобальная директива WSGIPy3kWarningFlag, при использовании python2.6 будут выдаваться предупреждения
6. Исправлена «assertion error» если питон был скомпилирован с директивой Py_DEBUG
7. Добавлена поддержка «Content-Type: chunked» в запросе (директива «WSGIChunkedRequest»). Данные склеиваются и передаются приложению на обработку.
8. Значения HTTP заголовков теперь передаются в справочнике окружения, для хуков доступа, авторизации и аутентификации
9. Флаг «flag wsgi.run_once» не выставляется в True, при работе в режиме демона, когда «maximum-requests» установлен в 1. В случае использования множества потоков, параметр «maximum-requests» проверяется только после завершения обработки запроса, поэтому нет гарантии, был ли выполнен только один запрос
10. Теперь интерпретаор инициализируется не в родительском процессе, а только после того, как будет создан дочерний
11. Сообщения из модулей-расширений на C попадают в логи виртуальных хостов, как и положено, а не в общий лог, как было ранее
12. Теперь невозможно писать сообщения в логи «чужих» виртуальных хостов
13. В режиме демона может производиться внутренняя переадресация с использоваением заголовка «Location» в ответе
14. В режиме демона может использоваться директива «WSGIErrorOverride», для того, чтобы возвращать стандартные страница ошибок Apache
15. Добавлена директива «WSGIPythonWarnings» работающая по аналогии с директивой «-W» интерпретатора
16. В директиву «WSGIDaemonProcess» добавлена опция «cpu-time-limit» определяющая количество процессорного времени, после которого процесс будет перезапущен
17. В директиву «WSGIDaemonProcess» добавлена опция «cpu-priority» говорящая за себя
18. Добавлена директива «WSGIHandlerscript» позволяющая определить скрипт, обрабатывающий определённый тип файлов

Меня тут попросили описать то, как я запускаю джанговские приложения в апаче. Я решил не растягивать резину в долгий ящик и просто привести свой конфиг с комментариями. :)

<VirtualHost *>
    ServerAdmin piranha@piranha.org.ua
    ServerName piranha.org.ua
    ServerAlias www.piranha.org.ua

    # директива говорит о том, что это конкретное приложение будет исполняться
    # в процессе-демоне с названием piranha
    WSGIProcessGroup piranha
    # Собственно описание этого демона. 2 процесса, максимум 1000 запросов.
    # Сайт не нагруженный, больше и не надо. :)
    WSGIDaemonProcess piranha user=piranha group=www-data threads=2 maximum-requests=1000
    # Главная, практически, директива. Файлик с описанием приложения. См. ниже.
    WSGIScriptAlias / /home/piranha/web/byteflow/byteflow/django.wsgi

    # Решил оставить, чтоб не забывали про него. :)
    # Кеширование картинок и прочих статических файлов.
    <IfModule mod_expires.c>
        <FilesMatch "\.(jpg|gif|png|css|js)$">
            ExpiresActive on
            ExpiresDefault "access plus 3 days"
        </FilesMatch>
    </IfModule>

    # Описание расположения статических файлов.
    Alias "/admin-media/" "/usr/local/lib/python2.4/site-packages/django/contrib/admin/media/"
    <Location "/admin-media/">
        SetHandler None
    </Location>

    Alias "/media/" "/home/piranha/web/byteflow/media/"
    <Location "/media/">
        SetHandler None
    </Location>

    # Логи. ;)
    LogLevel warn
    CustomLog /home/piranha/web/logs/piranha.access.log combined
    ErrorLog /home/piranha/web/logs/piranha.error.log
</VirtualHost>

А вот тот самый файлик, в котором описывается, как запускать приложение:

import sys
import os
import os.path

sys.path.insert(0, os.path.dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandler()

Кратко и незамысловато. Годится для любого проекта в силу независимости от места расположения. :)

Вот и всё. Файлик django.wsgi лежит в директории проекта, джанга лежит в пути Python'а (у меня вот в /usr/local/, потому как последний trunk и пакета для него, естественно, нету), всё работает прекрасно.

P.S. И, естественно, апач надо релоадить (apache2ctl graceful) после изменений в конфиге или в питон-коде приложения.

Меня тут попросили описать то, как я запускаю джанговские приложения в апаче. Я решил не растягивать резину в долгий ящик и просто привести свой конфиг с комментариями. :)

<VirtualHost *>
    ServerAdmin piranha@piranha.org.ua
    ServerName piranha.org.ua
    ServerAlias www.piranha.org.ua

    # директива говорит о том, что это конкретное приложение будет исполняться
    # в процессе-демоне с названием piranha
    WSGIProcessGroup piranha
    # Собственно описание этого демона. 2 процесса, максимум 1000 запросов.
    # Сайт не нагруженный, больше и не надо. :)
    WSGIDaemonProcess piranha user=piranha group=www-data threads=2 maximum-requests=1000
    # Главная, практически, директива. Файлик с описанием приложения. См. ниже.
    WSGIScriptAlias / /home/piranha/web/byteflow/byteflow/django.wsgi

    # Решил оставить, чтоб не забывали про него. :)
    # Кеширование картинок и прочих статических файлов.
    <IfModule mod_expires.c>
        <FilesMatch "\.(jpg|gif|png|css|js)$">
            ExpiresActive on
            ExpiresDefault "access plus 3 days"
        </FilesMatch>
    </IfModule>

    # Описание расположения статических файлов.
    Alias "/admin-media/" "/usr/local/lib/python2.4/site-packages/django/contrib/admin/media/"
    <Location "/admin-media/">
        SetHandler None
    </Location>

    Alias "/media/" "/home/piranha/web/byteflow/media/"
    <Location "/media/">
        SetHandler None
    </Location>

    # Логи. ;)
    LogLevel warn
    CustomLog /home/piranha/web/logs/piranha.access.log combined
    ErrorLog /home/piranha/web/logs/piranha.error.log
</VirtualHost>

А вот тот самый файлик, в котором описывается, как запускать приложение:

import sys
import os
import os.path

sys.path.insert(0, os.path.dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandler()

Кратко и незамысловато. Годится для любого проекта в силу независимости от места расположения. :)

Вот и всё. Файлик django.wsgi лежит в директории проекта, джанга лежит в пути Python'а (у меня вот в /usr/local/, потому как последний trunk и пакета для него, естественно, нету), всё работает прекрасно.

P.S. И, естественно, апач надо релоадить (apache2ctl graceful) после изменений в конфиге или в питон-коде приложения.

Сегодня наткнулся на просто невероятную вещь - mod_wsgi для nginx'а. На английском упоминаний нету вообще нигде, но не сомневаюсь, что они скоро появятся. :)

UPD. Он, конечно, совсем новый и ещё не юзабельный для продакшена, но, судя по всему, пока разработчик порядочно активен - только что добавился TODO

Сегодня наткнулся на просто невероятную вещь - mod_wsgi для nginx'а. На английском упоминаний нету вообще нигде, но не сомневаюсь, что они скоро появятся. :)

UPD. Он, конечно, совсем новый и ещё не юзабельный для продакшена, но, судя по всему, пока разработчик порядочно активен - только что добавился TODO

Всё, перевёл все свои виртуалхосты, использующие питон, на mod_wsgi, который куда лучше и проще настраивается, чем mod_python.

Кроме того, он позволяет запускать процессы в таком себе daemon-режиме, благодаря чему теперь мой меркуриал запущен из-под моего юзера - а это значит, что репозитории, которые в нём лежат, одновременно и доступны для записи, и принадлежат мне (и без всяких предоставлений юзеру www-data прав на запись). Очень удобно.

Меркуриал, кстати, невероятно рулит. Позволяет через браузер ходить по репозиторию (и смотреть не только последние версии, как svn), clone/pull проходит на порядок быстрее, чем в svn'е, а скорость annotate сравнить вообще нельзя - оно же всё локально происходит. :)

Всё, перевёл все свои виртуалхосты, использующие питон, на mod_wsgi, который куда лучше и проще настраивается, чем mod_python.

Кроме того, он позволяет запускать процессы в таком себе daemon-режиме, благодаря чему теперь мой меркуриал запущен из-под моего юзера - а это значит, что репозитории, которые в нём лежат, одновременно и доступны для записи, и принадлежат мне (и без всяких предоставлений юзеру www-data прав на запись). Очень удобно.

Меркуриал, кстати, невероятно рулит. Позволяет через браузер ходить по репозиторию (и смотреть не только последние версии, как svn), clone/pull проходит на порядок быстрее, чем в svn'е, а скорость annotate сравнить вообще нельзя - оно же всё локально происходит. :)