Category: технологии

Category was added automatically. Read all entries about "технологии".

jewishi

Яндекс.Почта меняет формат

Приходит мне тут письмо от Яндекс.Почты. Говорят, переходят на SSL строгий и просят... почменять порты подключений...
http://help.yandex.ru/mail/mail-clients/ssl.xml

XXI век? Нет, не слышал.
http://www.imc.org/ietf-apps-tls/mail-archive/msg00204.html
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=9

Беспокоюсь и переживаю за коллег. Может зря я не согласился в своё время работать там?
jewishi

Фэн шуй



Вот так выглядят место, где лежат ваши сайты, с филейной части. Мастер по фэн-шую ad_null.

Отдельный привет хочется передать корпорации Intel с их болтами M5 к рельсам.
Caribi

Небольшая разминка с WSGI/Python

 Пока чинят ковшик, Василий Иванович разминается красненьким (c) анекдот

Все в курсе что мы с ad_null последние полтора года внедряем всякие решения на Python в http://efind.ru . Мы ещё со времён петерхоста посматриваем на фреймворки Django или там Pylons. При всех прелестях языка, развитых библиотеках, очень хорошей реализации в общем и по мелочам - захостить как-то это негде. Надо ли говорить, что меня, как хостера, это чуток напрягало. Да, в прошедшем времени.

Мы перепробовали различные подходы к запуску python-приложений на практике. И разные варианты с mod_python, и CGI, и FastCGI.. Я даже там всякие извращения пробовал. Что же выбрать, думали мы. Массовая услуга должна подразумевать, по нашему мнению, и удобство развёртывания кода (ну там не 100 настроек - а две три специфичные для развёртывания), и некоторую универсальность (поскольку уникальность технологий скорее вредит бизнесу из-за страха клиента остаться наедине с этой уникальностью), и эффективность использования (нагрузка и всё такое), и расширяемость (в том смысле, что мы должны всегда учитывать рост проекта клиента). Также, нам хотелось не ограничиваться хостингом только узкого набора фреймворков, а организовать именно полноценный хостинг для приложений на языке Python.

Я знаю - сейчас тут приведут в пример хостеров нескольких с mod_python - но там есть проблемы. Опишу как-нибудь потом подробнее. С FastCGI меня всегда напрягала проблема "поднятия" скрипта и менеджмента FastCGI-процессов. Да и тогда надо приучать клиента к соответствующему "паблишеру", который может и не пригодиться потом.

Какого-же было наше удивление, когда мы обнаружили что разработки на python давно используют унифицированнй стандарт... "точки входа в приложение" что ли... для веб-приложений. Идея примерно такая - все сервера для питона (это может быть модуль апача, FastCGI или чёрт в ступе) принимают некое соглашение о вызове приложения через "точку входа", все приложения принимают соглашение о такой точке входа. Есть спецификация описывающая эту точку входа и что она должна возвращать.
WSGI является стандартом Python и описан в PEP 333.
Ваше приложение, написанное на WSGI, не знает кто его вызвал, для него абсолютно всё равно, запущен ли он на mod_python под Apache или как FastCGI, или как CGI. Приложение и сервер выделяются в разные абстракции.

Наличие этого стандарта позволило нам отделить техническую реализацию хостинга от кода приложений. Это расширяет наши возможности в перспективе по специализации предоставления услуг хостинга python-приложений в зависимости от разных условий, например, от нагрузки создаваемой приложением, с минимальными затратами со стороны клиента. Например, клиент может переходить с тестового тарифа, на нормальный, а потом на VIP, а потом и вообще уйти от нас на свой сервер не парясь переделкой своих программ. WSGI поддерживают все популярные веб-приложения на Python. Многие из них считают WSGI основным способом публикации и поставляемые "коннекторы" к другим технологиям публикации являются всего-лишь прослойкой для WSGI (например, Django). Запуск многих из этих приложений на хостинге занимает несколько минут.

В качестве разминки перед великими свершениями, мы тут немного поднапряглись (в основном благодаря цепкости ad_null) и у нас кое-что получилось...

ВСТРЕЧАЙТЕ WSGI на DiPHOST

Технология, которую мы внедрили, создаёт для каждого приложения несколько процессов с интерпретатором python в контексте пользователя, которые во время первого обращения к приложению, подхватывают операционый код приложения, и после выполнения оставляет у себя в памяти до следующего обращения. Запросы диспетчеризуются и в резидентную программу с подгруженным приложением приходят только "родные" запросы. Перед приложением запрос обрабатывает - поэтому .htaccess и прочие прелести всегда с нами. Система в целом очень похожа на принцип работы FastCGI за тем только различием, что ни внутри, ни внешне - нигде нет никакого намёка на FastCGI. Система реализована просто и академически правильно - никаких костылей и подпорок.

Я ещё не до конца понимаю какие ограничения куда применять, во что это выльется и как с чем бороться. Непонятны основные целевые аудитории. Будем наблюдать и выделять. Не надо меня "тестировать" - всё сломается и многие будут плакать. А я хочу быть рад за вас, хочу чтобы вы были рады за меня.
http://rack.rubyforge.org/
Ещё бы с Ruy-On-Rails как-то так же поступить. Кстати, у ruby тоже есть подобный стандарт - Rack: a Ruby Webserver Interface. Но с рубийным подходом "напишем всё на ruby" придётся самому видимо писать платформу.

Мы и дальше будем вести наш народ к звёздам!...