+38 (044) 361-23-09
Web фрэймворки, php, python CGI, ruby on rails и хостинг сайтов
Web фрэймворки, php, python CGI, ruby on rails и хостинг сайтов
Джон Грабер зашел на пост официального блога Dreamhost, сетующий на состояние применения веб структуры на виртуальном хостинге потребительского уровня. Пока пост в значительной степени интересуется Ruby on Rails, текущее состояние применения популярных (не основанных на PHP) веб структур, на таких хостах как Dreamhost, довольно отвратительно. Поиск «идеального хоста» в архивах рассылок пользователей django выдает приблизительно пятьсот результатов, большинство из которых прилагают все усилия для его работы. Я предполагаю, что подобные поиски списка архивов других структур вызовут похожее количество проблем.
Ну, так в чем же трудности и что можно сделать, чтобы исправить ситуацию?
Проблема
Вообще-то «проблемы». Я предполагаю, что есть три главных вопроса, с которыми сталкиваются структуры на виртуальном хостинге.
Прежде всего, новая волна популярных структур полностью отстранилась от традиционной модели интерфейса CGI, в котором приложение легко загружается и выполняется при каждом запросе. Это необходимое изменение (перезагрузка такой структуры, как Rails или Django, при каждом запросе приводила бы к трудоемкой работе), но единственное, которое вызывает головную боль у веб хостов.
Второе, параметры внедрения настолько различны, что сбивают с толку. Даже при наличии некоего стандартного протокола шлюза — как WSGI в Python — все еще существует большое количество для разногласий о том, как фактически внедрять приложение. Чтобы поработать, например, с WSGI (и немного придраться к Python, чтобы показать, что я не занимаюсь фаворитизмом), я могу написать приложение, которое легко говорит на WSGI, а приложения WSGI в основном взаимозаменяемы. Но с точки зрения сервера, это не очень понятно: должен ли сервер научиться непосредственно говорить на WSGI (à la mod_wsgi)? Должен ли присутствовать посредник, чтобы устранить недоразумения, как, например, flup? Если так, каким протоколом должен пользоваться сервер и посредник (flup, например, может говорить на FastCGI, SCGI и AJP)?
Третье, впервые новая волна структур вносит языки, такие как Ruby и Python, в виртуальный хостинг, и вместе с этим возникает проблема поддержки библиотеки. Новые хосты стандартных модулей должны быть готовы к поддержке, если они хотят серьезно относиться к этим структурам, потому что просить типичного пользователя виртуального хостинга скомпилировать адаптеры базы данных или библиотеку преобразования изображений (если ваш AUP разрешает это) просто не выход.
Купить
Модель внедрения для новых структур сосредоточена вокруг процессов долгого выполнения, - а не вокруг запуска оригинала приложения при каждом запросе, - и она довольно строга к провайдерам хостинга. В отличие от традиционных установок CGI и PHP, структура, подобно Rails, Django или TurboGears, просто не может работать на основе «запускать оригинал каждый раз». Структуры просто неприменимыми в данной ситуации из-за издержек на установку и запуск. Единственный путь работы это постоянный процесс, который загружает код один раз и сохраняет его в памяти.
Но, как правило, хосты неохотно позволяли пользователям запускать процессы долгого выполнения того типа, который необходим для эффективного обслуживания приложения, основанного на структуре. Когда я работал фрилансером, то довольно часто сталкивался с хостами с автоматизированным мониторингом процесса, который просто убивал любой личный процесс пользователя, который хранился в памяти более тридцати секунд. Другие же убивают что-либо вне одобренного белого списка (прочитайте: Rails), что приводит к такому забавному явлению, при котором в качестве обходного пути переименовывают не-Rails программы обработки FastCGI в dispatch.rb.
Эта ситуация понемногу налаживается, но необходимо дальнейшее развитие. Да, процесс долгого выполнения будет жевать ценную память даже, когда она не обслуживает запрос, но это придется принять. Хосты, которые это не поддерживают, превращаются в хосты устных рекомендаций пользователей структуры.
Единственный очевидный путь этого
Одним из аргументов вездесущности PHP является то, что за длительное время, модель внедрения была простой и стандартной: установите PHP и mod_php, укажите Apache использовать это для всего заканчивающегося на .php и большая чатсь работы сделана. В наши дни в параметрах присутствует некая фрагментация - mod_php против FastCGI против прямого CGI - но они все документально подтверждены, просты в понимании и установке (и, с точки зрения, автора приложения, они все одинаково работают: просто загрузите файл .php). Более того, большинство дистрибутивов Linux могут установить все, если один раз заглянуть в диспетчер пакетов.
На данный момент, у Ruby и Python нет ничего похожего. Да, у Python есть WSGI, но посмотрите выше, почему это не решает проблему. По большей мере, там должен быть один стандартный стек для одного языка и предпочтительнее форма «установить этот модуль Apache». Я предполагаю, что самая перспективная опция для Python это mod_wsgi, который, хотя не все разрешает в .htaccess, с легкостью подключается к популярным панелям управления хостинга. Относительно Ruby, я не знаю. Я не достаточно знаком с различными опциями, чтобы составить свою точку зрения.
Впрочем, это не означает, что структуры не должны поддерживать многочисленные опции внедрения, но это также означает что, с каким бы языком вы не работали, должна существовать стандартная опция, а структура должна ее поддерживать.
Импортируйте это
Другой аргумент успеха PHP заключается в том, что его особой целью является развитие веб, а также полного комплекта всего необходимого. Отрицательной чертой является то, что стандартная функция пространства имен в PHP ужасно переполнена, но, по крайней мере, есть всего несколько случаев, когда необходимо выйти и установить новую библиотеку только, чтобы получить, например, поддержку базы данных.
С другой стороны, Ruby и Python это универсальные модульные языки. Это значит, что существует ряд модулей, которые, хотя и необходимы для разработки веб приложения, не включены в стандартную библиотеку любого языка. Взаимодействие с базой данных, например, в значительной степени зависит от сторонних модулей. Python поддерживает только SQLite вне блока (и только в Питоне 2.5 и в следующих версиях), и насколько мне известно, Ruby не отправляет модули для любой из открытых баз данных «большой тройки»(SQLite, MySQL и PostgreSQL) в его стандартную библиотеку.
Кое-чему из этого можно посодействовать и внести изменения в стандартные библиотеки или с помощью более удобной упаковки некоторых важных сторонних элементов, но если хосты хотят серьезно относиться к структурам, им нужно гарантировать доступность любых ключевых модулей, которые не являются частью языка. Сказать кому-либо скомпоновать собственную копию, скажем, MySQLdb для Python – занятие, обреченное на неудачу.
Работай со мной здесь
Вы заметите, что из трех вопросов, изложенных выше, два возлагают много ответственности на провайдеров хостинга (хотя, если вы считаете, что решение вопроса «стандартного внедрения» будет простым с точки рения структуры, у меня есть слон, которого хочу вам продать). Это довольно таки неизбежно: когда новый метод построения веб приложений становится популярным, веб хостинг необходимо изменить, чтобы он не отставал.
Но в целом, должен быть диалог между хостами, которые желают предложить твердую поддержку структуры, и разработчиками и пользователями структур, которые хотят, чтобы опыт использования хостинга был как можно безболезненнее. Ни одна из сторон не может позволить себе сидеть сложа руки и надеяться, что кто-нибудь другой решит проблему, и у ни одной из сторон нет достаточной компетентности или ресурсов, чтобы решить все вопросы.
И, конечно же есть хосты, которые делают свою часть работы. Например, Joyent, на котором благополучно размещен этот сайт, гордится поддержкой Rails и он также сделал кучу невоспетой работы для гарантии того, что структуры Python будут простыми в использования на их виртуальных предложениях (до такой степени, что способствует соединению с ключевыми сторонними модулями, так что они будут работать на Solaris среде Joyent). WebFaction буквально из кожи вон лез, чтобы интегрировать поддержку для популярных структур прямо в их панели управления (например, внедрение демо-роликов на Django).
Продвигаясь вперед, я думаю, что это единственный путь решения вопросов, указанных выше: хосты, которые желают обеспечить большой опыт работы со структурами, должны объединится со структурами, которые желают обеспечить большой опыт работы с хостингом, и решить эти вопросы. И если они ищут решения проблем, с которыми они сталкиваются в структурах, я бы очень хотел посмотреть, как Dreamhost принимает в этом участие.
Комменты
Sheesh
Также как музыкальная индустрии свыклась с понятием CD и находит новые пути продаж, также как кинокорпорации свыклись с понятием распространения фильмов на дисках (полная глупость!) и находят новые пути продаж (читай: интернет), так и хостинговым компаниям нужно найти новые пути продаж. Виртуальный хостинг свое отжил, им всем нужно полностью перейти на VPS хостинг.
she
Sheesh, это не только вина хостинговых компаний.
PHP довольно таки противный язык, но тем не менее он используется в большинстве www.
В этом смысле, Ruby и Python, как языкам, нужно поспевать. Если же нет, php будет благополучно существовать со всеми его недостатками (и нужно принять это во внимание при процессе разработки следующих версий php 6 или php 7 или php x).
Manuzhai
Кто-то где-то уже отмечал, что выполнение этих внедрений довольно тяжело для разработчиков. По крайней мере, намного тяжелее, чем просто загрузка PHP файлов. Это большие полномочия и ответственность разработчиков приложения, которые держат в руках процессы долгого выполнения для всякой всячины.
Yansky
А разве mod_python не так же прост в использовании, как и mod_php?
Joe Cooper
Обратите внимание, что проблема заключается не только в отсутствии эквивалента mod_php для Ruby, а Python mod_php, слава богу, больше не используется на большинстве провайдеров виртуального хостинга. Это просто не безопасный способ работы приложения в среде виртуального хостинга. Чтобы ты не использовал, то ли это mod_fcgid, то ли mod_fastcgi или некий модуль специфики языка, необходимо скооперироваться с mod_suexec. RоR и Django можно установить в среде виртуального хостинга, если проксирование выборочно. Virtualmin обрабатывает это для RоR, создавая несколько суррогатов и конфигурируя proxy правила в Apache.
Я бы просто предпочел увидеть поддержку FastCGI интерфейса на всех главных структурах приложения. Он не совершенен, а проблемы, возникающие с ним, хорошо известны (хотя многие не пользовались mod_fcgid, который исправляет большую часть фиксов в mod_fastcgi). Но он действительно решает большую часть проблем и доступен в большинстве средах виртуального хостинга. Если бы RоR, Django, Catalyst и т.п. считали FastCGI первоначальной целью для внедрения, жизнь тех, кто обитает в виртуальной среде, стала бы намного легче, а непоследовательность красноречия DreamHost и ответов DHH была бы просто не нужна.
dev/null
Джо знает, о чем идет речь. Вы никогда не сможете просто запустить django или Ruby. Они скорее обеспечат доступ ко всем данным пользователя, поэтому необходим suexec или что-то в этом роде. Проксирование вызывает некоторое сложности, которые не все можно решить. Создание нескольких суррогатов это, в конечном счете, хороший способ решения проблем.
Поиск «идеального хоста» в архивах рассылок пользователей django выдает приблизительно пятьсот результатов, большинство из которых прилагают все усилия для его работы. Я предполагаю, что подобные поиски списка архивов других структур вызовут похожее количество проблем.
Я считаю, что это довольно интересно, когда появляются проблемы с работой Django на Dreamhost. Я следовал указаниям Джеффа Крофта при инсталлировании нескольких вариантов в течение последних нескольких месяцев.
Главный дефект Dreamhost, как вы и подчеркивали, заключается в отсутствии контроля над инсталлированными и поддерживаемыми модулями Python.
Тем не менее, я сталкивался с Django, работающим на Webfaction. Очень прост в выполнении. (Один клик и установка завершена)
Doug Napoleone
Грэм Дамплтон усердно трудится, чтобы mod_wsgi соответствовал всем потребностям потребительского хостинга. Ему это удается. Как только он достигнет 3.0 версии, я думаю, что он будет применяться на потребительском хостинге. Я надеюсь, что webfaction также будет его применять. Мне нравится, как внедрили Django, но это внедрение интенсивно использующее память, для множества сайтов (1 apache образец на mod_python), и расходы, связанные с новой услугой, основаны на памяти/диске/полосе частот. Использование mod_wsgi должно сократить объем занимаемой памяти до более 70%.
Мы использовали mod_wsgi для сайта PyCon и он работал намного лучше, нежели mod_python, или fastcgi flup. У нас были сложности с mod_python из-за применения mod_php, который компилировался, несмотря на специфические виртуальные библиотеки. Мы не могли перейти к более новому mod_python для последующей конференции. Поэтому использовали fastcgi + flup, но обнаружили, что дополнительные процессы/потоки медленно запускаются, а небольшая атака могла вызвать проблемы. К тому же, flup не пуленепробиваем для заголовков запроса искаженного http. И в результате, мы имеем кучу зависших процессов.
В одно время, у нас были проблемы с ботом, который оказался ошибкой в 1.0 версии mod_wsgi (скомпилированный для очень старого apache). Как только мы разрешили вопрос с плохим кодом django, мы обработали бот подключения с более 800 параллельными запросами. Это заняло 5 секунд, и это были атаки спама (148352 байта в пост заголовке). Он отлично обрабатывает искаженные заголовки.
В прошлом году был рассмотрен график приложений для использования на конференциях. В этом году ожидаются вдвое больше загрузки, тогда как скорость и память также представляют интерес. Я уверен, что все пройдет хорошо, но у django есть некоторые mod_wsgi приложения, планируемые для работы с чрезмерной загрузкой. Вопрос о приостановке этих вопросов довольно приоритетен для django.
Bryant Cutler
Я полагаю, что частично, проблема заключается в том, что некоторые веб хосты, в том числе Dreamhost, так сосредоточены на PHP хостинге, что они не предоставляют доступ ко всем остальным виджетам и программкам в процессе внедрения, и нужно приложить усилия, чтобы что-нибудь похожее на Django или Rails заработало. Я несколько месяцев потратил на то, чтобы Django приложение «Привет Мир» безошибочно работало на Dreamhost и каждый раз сталкивался с непреодолимыми проблемами. Я перешел на TextDrive (сейчас Joyent) и написал блог за два дня. Если вы хотите пользоваться Django или Rails, найдите хостинг Django или Rails вместо узла, стоимость которого за год меньше, чем стоимость Интернета.
Gabe da Silveira
Отложим в сторону проблемы предоставления доступа фанатикам для создания процессов долгого выполнения на виртуальном хосте, так как фундаментальным вопросом является невероятная нагрузка ресурса, которую структуры возлагают на сервер. Так как он находится в памяти, то это увеличивает базовое количество ресурсов, необходимое для каждого сайта.
Рынок виртуального хостинга процветает, так как большинство сайтов вообще не получают никакого трафика. В течение многих лет непрерывное распространение открытых приложений PHP увеличило применение CPU/базы данных, что привело к ничтожному опыту работы на виртуальном хостинге (десять лет назад виртуальный хостинг всегда был быстрым, даже для Perl CGIs). Хостам подобно Dreamhost приходилось компенсировать это, сокращая число сайтов на блоке или применять более жесткие меры для управления загрузкой. И даже в этом случае, в мире виртуального хостинга постоянно имеют место проколы и неудачи. Выбросите долгосрочную память и модель полностью разрушиться. Вам тот час же придется сократить число пользователей на блоке до 90%, чтобы только сохранить обмен диска, и предпринять решительные меры, как, например, динамичный FCGI, и надеяться, что не все сайты одновременно станут популярными. Более того, у вас есть поддержка множества новых библиотек.
Dreamhost быстро возложил вину на разработчиков структуры, но устранить недоработки (например) в внедрении Rails намного проще, нежели разрешить проблемы виртуального хостинга. Я не думаю, что главная цель виртуального веб хостинга заключается в предложении качественной структуры хостинг продукта. Хосты подобно Slicehost свидетельствуют, что $20 в месяц предоставляют вам приличное количество налаженных ресурсов для работы приложения структуры. Но это невыполнимо при стоимости $5 в месяц. Мой прогноз заключается в том, что основные структуры начнут сталкиваться с некоторыми специализированными виртуальными хостами, на которых будет сосредоточена финансовая поддержка. Но если и так, то пользователи, которые считают, что $20 в месяц это дорого, не являются экспертами в новой технологии структур. И вы не разбогатеете, если каждый месяц придется тратиться на поддержку.
Baxter
Не так уж плохо заставить Django работать на Dreamhost. Руководство Джеффа это довольно неплохой обзор. Django предоставляют информацию о его работе с fcgi, и у Dreamhost непосредственно тоже много информации, если учесть, что они не поддерживают ее официально.
Но проблема заключается в том, чтобы небольшой сайт Django продолжал работать.
Ian Bicking
Я не думаю, что хостинговые компании очень полезны. Неплохо знать, что Joyent предоставляет исправления, но это просто исключение. Даже, предоставление ярлыков было бы большим усовершенствованием. WebFaction решил большинство проблем, но решение проблем помогает только их клиентам. Это не помогает остальным (возможно, я ошибаюсь, и в WebFaction уже предоставляют эти структуры, но я об этом не подозревал).
Абсолютный минимум не достаточен для поддержки библиотеки. У вас должны быть необходимые драйвера для баз данных, которые вы поддерживаете, и конечно же PIL. Это не так уж сложно, и вопрос только в том, не все ли равно провайдеру хостинга. Только лень объясняет отсутствие этих пакетов. Что-либо помимо них не столь необходимо или полезно.
mod_wsgi является наиболее перспективной опцией. Он помогает разрешить CGI вопрос с опцией демона, который позволяет вам ограничивать время активного процесса долгого выполнения и избегать проблемные линии поведения (например, утечки памяти). Это также позволяет приложениям оставаться в пассивном состоянии (я думаю), поэтому приложения низкой нагрузки не принимают ресурсы, если они не используются. Я не знаю, работает ли это или функционально как mod_suexec (думаю, что нет), но это может быть проблемой. Также, .htaccess конфигурация является сложностью.
FastCGI должен быть правильным решением в этом случае, но у меня всегда было такое впечатление, что это просто лажа, без четкого дизайна, реализации или необходимых функций для создания устойчивой основы для разработки приложений. Если бы можно было заново воплотить концепцию, то, возможно, что-нибудь из этого и вышло бы.
Dave Lowe
Я могу подтвердить, что опыт работы с приложениями Django на WebFaction просто превосходен. Особенно в сравнении с Dreamhost. Как сказал Baxter, не так уж сложно заставить Django работать на Dreamhost, но проблема заключается в том, чтобы он продолжал работать. У меня есть один сайт на Dreamhost среднего размера работающий на Django, который все еще работает (только иногда с незначительными заминками), но мне пришлось переместить другой с Dreamhost почти год назад, из-за того, что сайт вдруг перестал реагировать и постоянно уведомлял о странной ошибке.
Я все еще волнуюсь, что тоже произойдет и с другими сайтами. Я это называю хост-фобией.
Я, как и другие, рекомендую найти хост, который “официально” поддерживает что-либо в вашем пользовании и отлично с этим справляется.
mark l.
Виртуальные хосты, подобно Dreamhost, вымирающий вид. Их хныканье только выявляет тот факт, что они уже давно продаются и это не может долго продолжаться. Те, кто серьезно относиться к разработке, берет внедрение среды в свои руки. Я рекомендую VPS и сам пользуюсь одним из Slicehost. Вы получаете контроль и полномочия выделенного сервера по низкой цене. Вам придется замарать руки, но намного проще получить приложение Rails или Django, работающее сегодня, нежели год назад.
fernando
Нет никакой причины не получить VPS, я очень доволен Rimuhosting.
Orion
Вы должны проверить Heroku. Это разработка и внедрение Rails посредством одного клика. Система в бета, но может увеличиваться, если увеличивается загрузка, и уменьшается., если она понижается. Поэтому, вы платите за нее, как за утилит.
http://heroku.com/
Chui Tey
Python необходимо понятие «защищенный» модуль, который можно использовать в виртуальном хостинге. Таким образом, постоянный процесс Python может быть использован для многих виртуальных хостов, если предварительно загружать защищенные модули структуры, и загружать только специфические модули сайта, когда приходит запрос и удалять их по его окончанию. Это предоставляет python необходимое потребление производительности/ресурса наравне с PHP.
Jeff Croft
Мне нравится, что пришлось сказать DHH по этому вопросу на Snakes против Rubies (BTW, когда Snakes против Rubies II – это должно произойти!). Он сказал: «Кому есть дело до того, что есть множество виртуальных хостов, выполняющих прекрасный Python/Ruby хостинг. Сколько хостов вам нужно? Вероятно только один. Пять хороших - вот и все, что нам действительно нужно».
Существует абсурдное мнение, что чем больше хостов, тем лучше. Но почти никто не пользуется более чем одним виртуальным хостом. Поэтому вам действительно нужно всего несколько, чтобы выбрать один. А что если их у PHP миллион? Вам нужен миллион?
David
Но можете ли вы перечислить 5 хороших виртуальных python/django хостов?
Существует более 5, которые хорошо работают, но мне трудно отыскать эти 5 простых, быстрых и стабильных.
eelco
При поиске способа сократить время IT-проектов, центром внимания организации почти всегда является закодированная часть, несмотря на то, что кодирование занимает всего10-15% работы (в значительной степени благодаря более ранней оптимизации разработки). Получается, что приложения это обычно более тяжелая часть (по крайней мере, там, где работаю я).
Как вы отмечаете, структуры подобно Rails и Django (также) концентрируются на простоте разработки, и пока они над этим трудятся, только малая часть проблем решается. Даже простая разработка требует внимания. Трудно поверить, что те, кто создают эти красивые и изящные структуры разработки, не могут придумать структуру упаковки, у которой внедрение веб приложения Рython, было бы таким же простым, как и у приложений php. Как только это будет сделано, хосты будут этим руководствоваться.
Steve Ivy
Я написал об этом всего за несколько дней до этой публикации на Dreamhost, и я слегка изменил свое мнение.
Я полагал, что, установка приложения/структуры, основанной на ruby или python на виртуальном хосте, так же проста, как и установка Wordpress или другого приложения, основанного на php. Читая этот пост и некоторые другие, я начинаю полагать, что установку приложения можно выполнить с помощью большинства инсталляторов-в-один-клик, но это является проблемой для пользователя со средними техническими навыками, способного загрузить и активизировать модули/расширения к этому приложению.
Также как Dreamhost предлагает установку Wordpress в один клик, я видел, как он предлагает инсталляцию приложения в один клик на предварительно установленной/сконфигурированной системе структуры. Если процесс загрузки/конфигурации модуля или темы можно упростить для конечного пользователя, то я думаю, надежда еще не потеряна.
JOHNb
Не вижу уместность виртуального хостинга в мире разработчика. Если вы действительно серьезно относитесь к разработке сайта, основанного на одной из выше указанных структур, то следует начать (как минимум) с VPS решения, о котором уже упоминали. Но как только этап фанатика остается позади, следующий шаг - получить полнофункциональный выделенный сервер (для начала, уйма хостов предлагает их по цене около $100 в месяц).
Я уже давно пользуюсь выделенным сервером и если мне нужна новая структура для проекта клиента, я ее просто инсталлирую. Если я хочу использовать новый модуль или плагин для одного из моих существующих проектов, я его загружаю. Большинство виртуальных хостов распродают характеристики их технических средств и надеются, что ни один из их клиентов никогда не сгенерирует трафик. На блоке redhat Linux 7 у меня было 35 или около того статических HTML сайтов, другие 10 или около того были Perl/PHP сайты, и 5 мои собственные RоR сайты, и даже с обработкой почты, фильтрацией спама, вспомогательными процессами и всеми сайтами, мне еще нужно побить 50%-ный рекорд использования ресурса.
Виртуальный хостинг IMHO создан для фанатиков и аналогичных «копирование-и-вставка» кодеров. Если вы добросовестный разработчик, то не должны бояться марать руки время от времени.
Steve
Не вижу уместность виртуального хостинга в мире разработчика.
Это зависит от рынка. Я не в курсе твоего мнения о разработчиках Wordpress, но они умные ребята, и уделяют довольно много времени, разрабатывая программное обеспечение, с которым могут справиться пользователи. Несмотря на ваше мнение об их платформе, создание программного обеспечения для «обыкновенных людей» и фанатиков - благородное дело.
Виртуальный хостинг IMHO создан для фанатиков и аналогичных «копирование-и-вставка» кодеров. Если вы добросовестный разработчик, то не должны бояться марать руки время от времени.
Я нахожу это отношение оскорбительным, Джон. Я - разработчик и действительно хочу замарать свои руки, но я хочу написать программное обеспечение, которым смогут пользоваться не-программисты, для кого виртуальный хостинг является приемлемым решением.
Возможно, эти структуры никогда не будут соответствовать миру, где столько драгоценно использование CPU и памяти. Возможно, виртуальный хостинг последует путем динозавра, но этот веб был создан и популяризирован «аналогичными «копирование-и-вставка» кодерами», которые продолжают искать и создавать новые проекты. Насмехаться над ними просто низко.
Jon Rosebaugh
Конечно же, mod_wsgi страдает от собственных проблем. Внедрение процесса Python в Apache в основном превращает ваши веб приложения в неизолированную программную среду (не-песочницу). И также расширяет площадь Apache, как и удерживает вас от изучения альтернативных серверов. mod_python, которые сталкивались с этой проблемой. А mod_wsgi поддерживает это, так как его установка по умолчанию . mod_wsgi предлагает альтернативу, «режим демона», который, насколько я могу судить (протокол, на удивление, неописан в документации, даже никаких комментов в коде), использует протокол подобный CGI для связи с порожденными процессами приложения о сокетах Unix.
Моя любимая установка это запуск сервера приложения (paste.httpserver предоставляет превосходный и стабильный сервер WSGI) и обратный прокси к нему с вашего клиент-сервера на выбор. В данный момент я пользуюсь Apache mod_proxy, потому что мне нужно поддерживать SVN, но я также мог бы использовать lighttpd или ngnix. И так как это стандартный протокол, у HTTP есть полный набор инструментов для отладки, баланса загрузки, записи информации, и так далее. Безусловно, вам нужен сервер, работающий на порту через webapp, и вам еще нужен внешний сервер, работающий (хотя, у меня еще не было сбоев с paste.httpserver за исключением ошибок синтаксиса, в котором Python просто отказывается загружать код). Но это решаемая проблема для тех, кому нравится Dreamhost и кто желает потратить немного времени на него.
Tom Armitage
Неплохой пункт о предварительно инсталлированных модулях.
Адаптеры базы данных действительно являются вершиной айсберга. Большинство приложений Rails заканчиваются в зависимости от других «gems» или внешних модулей. Я уверен, что Django/Turbogears/другие Python приложения заканчиваются на других зависимостях.
Пункт «виртуальный хостинг» заключается в том, что каждый получает то же самое. Большинство компаний, особенно на небольшом, более товарном и более ограниченном рынке, не собираются инсталлировать новые плагины (особенно основанные на C, которым необходимо компилирование) только для вашего приложения. И они не позволят сделать это вам самим. PHP никогда не предъявлял подобные требования. Как только код скомпилирован и готов к применению, им начинает пользоваться каждый, каким бы отвратительным он не был.
Идеальным решением может быть помещение в «песочницу» (“sandbox”) каждого эккаунта, но вы потом начинаете серьезно использовать память, и это уже напоминает VPS.
Нет ничего лучше PHP, в отличие от любого другого упомянутого языка, даже Perl, который концентрируется на развитии веб. Второй комментатор - “ she ” - некорректна, предполагая, что языки нужно менять для соответствия запросов развития веб. Языки четко разрабатываются, независимо от их следующего использования.
Я всегда сравниваю с аргументом «недорогих продуктов». «Недорогие продукты» это, обычно, иллюзия. Дело не в том, что другие продукты дороже, а в том, что эти неестественно дешевые благодаря некоему массовому производству за счет качества. Хостинг стал довольно недорогим товаром, но, откровенно говоря, это просто иллюзия. Только потому, что mod_php делает это возможным, совершенно не означает, что это правильное решение для каждого. Если вы посмотрите на Python/Rails/Java/.NET сообщества, то увидите, что почти все их веб разработки структурируются на подходе «сервер приложения». Для этого необходимо больше памяти, но также позволяет разработчику больше контролировать среду. В конечном итоге, от сервера, над которым у вас нет контроля, рано или поздно не будет никакой пользы. Здорово, что существует РHP. Я использую его для большинства быстрого/грязного внедрения, именно потому, что я могу загрузить кучу всего на любой веб сервер в мире. Но его простота в внедрении происходит за счет другого. Не нужно допускать, что самая дешевая, самая простая опция должна стать нормой.
Nick
Прежде всего, новая волна популярных структур полностью отстранилась от традиционной модели интерфейса CGI, в котором приложение легко загружается и выполняется при каждом запросе. Это необходимое изменение (перезагрузка такой структуры, как Rails или Django, при каждом запросе приводила бы к трудоемкой работе), но единственное, которое вызывает головную боль у веб хостов.
ASP.NET наследовал эту модель некоторое время и доступен на вирутальном хостинге. У нас есть несколько приложений MonoRail (что то похожее на Rails для C#, но сейчас они отклоняются от их собственной идиоматической формы), внедренных в среде виртуального хостинга, и они отлично работают.
Большинство провайдеров виртуального хостинга ограничивают безопасность, а это подразумевает отсутствие неуправляемого кода или COM interop, но большинству веб сайтов это в любом случае не нужно. Полная надежная модель это, в основном, результат системы исторически искаженных разрешений на Windows, но она сама обеспечивает защиту внутри кода, то есть, ограничивая использование отображения, чтобы предотвратить злонамеренную самомодификацию, ограничивая использование сокетов и реестра, и т.п. (Есть ли в мире открытого исходного кода что-либо подобное? У меня было полно работы с PHP, и, более того, кроме «безопасного режима»).
Дело в том, что эта часть проблемы, по крайней, мере, решаема. Без использования 45-фунтовой кувалды, как в случае с VPS.
Это мои пять копеек для того, кто работал как для РHP, так и для «лояльных» компаний.
Alex
Существует довольно много способов работы с более новыми веб приложениями, как, например, Rails и Django, но, тем не менее, это не так уж и просто.
Как администратор, который впервые работает с Django, вы читаете документацию и пробуйте mod_python, так как это рекомендовано. Первое, что вы делаете, это инсталлируете mod_python, так как до этого никогда не пользовались веб приложением Python, и первое, на что вы обращаете внимание, это то, что веб сервер обрывается с ошибками в сегментации из-за проблем с библиотекой MYSQL.
А теперь сравните это с каким-нибудь приложением PHP, в котором администратор инсталлирует mod_php и он работает, так как от него ожидают. Вы можете немного изменить настройки в .htaccess файлах в Apache с директивами, как, например, php_flag. Это также просто для массового веб хостинга. Любые запросы для веб хостов, которые не используются и как правило не занимают много ресурсов, занимают всего немного времени с Apache/PHP на запросах страницы.
Необходимо решение для всех остальных структур языков. Хотя mod_wsgi довольно потенциальное решение, он мне не поможет, если другой пользователь моего сервера захочет инсталлировать Ruby на Rails, так как mod_wsgi только для Python! Сейчас mod_fastcgi разумное решение, как и mod_fcgid, но ни один из них не совершенен. Печально, но .htaccess файлы не предоставляют достаточно контроля пользователям с решениями FASTCGI.
Я начал с mod_fcgid, но это едва ли лучшее решение, если вы хотите разместить много сайтов на одном сервере.
Steve Boyd
Rails/Django - обе довольно мощные веб структуры. Такие мощные, что находятся вне понимания любого фанатика /новичка.
С другой стороны, облегченные копии rails, как, например, CakePHP справляются с 80% того, с чем справляется rails, но, гораздо вероятнее, работают без каких-либо сложностей на всех приличных виртуальных хостах.
Есть несколько неплохих копий rails и с каждый днем они становятся все лучше и лучше. Я не удивлюсь, если, в конечном итоге, они заменят rails.
Arthur
Я потратил кучу времени, пробуя компилировать mod_python с правильными библиотеками на моем блоке Linux, на который я потратил несколько долларов на эккаунте WebFaction, где все уже было для меня инсталлировано. Все остальное работает вне блока.
Tom
Возможно я ненормальный, но мне кажется, что если можно программировать в таких языках, как Python и Ruby, то можно установить простой веб сервер.
rev_matt_y
Мой хостинг уже давно размещен на highspeedrails.com (раньше назывался zettai) и ни разу не сталкивался с трудностями. Поддержка просто супер и период работы (uptime) составляет более 98%. Я не пользовался PHP или Rails с их обслуживанием, но у меня там были хостинги Zope и Django, и они довольно легко все делали.
Frederico
А как насчет контейнеров GridServer MediaTemple? Не решение ли это для «продвинутого» виртуального хостинга? Вы получаете все преимущества виртуального хостинга, плюс среда приложения, которая находится вне остальных виртуальных ресурсов. Я согласен, что разработчик должен знать, как установить необходимый сервер или VPS, но довольно неплохо иметь уже установленную и налаженную защиту, электронную почту, ftp и т.д. На одну проблему меньше.
