Skip to main content
Все материалы

Быстрая автоматическая установка Ruby on Rails на IIS 7

Оценить: 

Популярность фреймворка Ruby on Rails постоянно растет, общество становится шире и, если раньше об использовании Ruby на Windows говорилось редко, то сегодня это вполне реальная практика.

Такие проекты как RubyInstaller ( http://rubyinstaller.org/) и RailsInstaller ( http://railsinstaller.org/) значительно упрощают создание рабочей среды на Windows. Вы можете использовать нативный MRI 1.8 и 1.9, JRuby или даже IronRuby работающий на .NET. С Windows работает большинство gem-пакетов, причем благодаря DevKit ( https://github.com/oneclick/rubyinstaller/wiki/Development-Kit) «сишные» джемы можно собирать прямо из исходников. 

Однако, несмотря на активное развитие средств разработки, до сих пор Windows и в частности веб-сервер IIS практически не использовались как «продакшн» решение для развертки Rails приложений. Но с появлением нового инструмента Helicon Zoo на базе Web Platform Installer – эта ситуация поменялась.

Helicon Zoo

Helicon Zoo – это репозиторий веб фреймворков и приложений, позволяющий легко устанавливать и запускать Rails, Django (фактически любые rack, wsgi или FastCGI приложения) и Mojolicious на веб-сервере IIS.

Helcon Zoo использует Microsoft Web Platform Installer ( http://www.microsoft.com/web/downloads/platform.aspx). Это репозиторий и среда развертывания веб приложений и фреймворков от Microsoft, которая уже содержит в себе множество ASP.NET и PHP приложений. Для реализации функционала понадобилось лишь создать собственный feed с продуктами, чтобы пользователи получили возможность удобной и простой установки из репозитория. 

Однако просто добавить продукты в репозиторий недостаточно. Ядром Helicon Zoo является native IIS модуль, по сути, играющий роль моста между веб-сервером IIS и фреймворками на Ruby, Python и Perl и др. Модуль работает по протоколу FastCGI, который уже зарекомендовал себя как надежный и быстрый метод взаимодействия с веб сервером. Ввод-вывод обрабатывается асинхронно, используя технологию IOCP. В качестве транспорта используются именованные каналы либо сокеты. В ближайшее время разработчиками планируется полностью реализовать поддержку асинхронного FastCGI (к сожалению ни один из существующих на данный момент фреймворков асинхронный FastCGI не поддерживает). 

Поддерживаются IIS 7, IIS 7.5, а также IIS Express.

Устанавливаем Ruby on Rails

Скачайте Web Platform Installer ( http://www.microsoft.com/web/downloads/platform.aspx) и запустите его. В появившемся окне нажмите «Options»: 

В опциях необходимо добавить ссылку на feed Helicon Zoo:  www.helicontech.com/zoo/feed/ 

Теперь если выбрать вверху «Application» а в меню слева перейти на «Tools», вы увидите новые приложения: «Blank Ruby on Rails Project», «Blank Django Project», «Blank Perl Project» и «Blank Mojolicious Project»: 

Это пустые «Hello World» заготовки, которые устанавливают необходимые зависимости для дальнейшей разработки. 

Нажмите на кнопку «Add» напротив «Blank Ruby on Rails Project», а затем на кнопку «Install». 

Инсталлятор предложит установить следующие зависимости: 

После нажатия на кнопку «I Accept» нужные пакеты будут загружены и установлены, после чего вам будет предложено настроить сайт для нового приложения. 

Вы можете создать новый сайт либо выбрать существующий: 

Когда установка и настройка закончены, приложение готово к запуску: 

Под капотом

После установки «Blank Ruby on Rails Project» web.config файл для выбранного IIS-сайта выглядит следующим образом: 

<?xml version="1.0" encoding="UTF-8"?> 

<configuration>

<system.webServer>

<handlers>

<add name="rails.project.x86" scriptProcessor="ruby.1.9.pipe" path="*" verb="*" modules="HeliconZoo_x86" preCondition="bitness32" resourceType="Unspecified" requireAccess="Script" />

<add
 name="rails.project.x64" scriptProcessor="ruby.1.9.pipe" path="*" verb="*" modules="HeliconZoo_x64" preCondition="bitness64" resourceType="Unspecified" requireAccess="Script" />

</handlers>

</system.webServer>

</configuration>


По умолчанию в качестве транспорта между IIS-модулем и воркером Ruby on Rails используются именованные каналы. Чтобы использовать сокеты, достаточно заменить параметр «scriptProcessor» на «ruby.1.9.tcp». 

Все доступные скрипт-процессоры описаны в секции <heliconZooServer> файла applicationHost.config

Через web.config также можно влиять на работу Rails-приложения. Так, например, по умолчанию оно запускается в отладочном режиме (RAILS_ENV = development). Чтобы переключиться в продакшн режим, вы можете установить переменную RACK_ENV следующим образом: 

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<system.webServer>

<heliconZoo>

<application name="rails.project.x64" >

<environmentVariables>

<add
 name="RACK_ENV" value="production" />

</environmentVariables>

</application>

</heliconZoo>


Секция <heliconZoo> в файле web.config используется в основном для установки переменных окружения при вызове воркера. По сути, через секцию <environmentVariables> вы можете передавать в приложение любые необходимые параметры. В руби они будут доступны через глобальный хэш «ENV».

Что дальше?

Работа над проектом Helicon Zoo ведется очень активно, компания-разработчик  HeliconTech будет рада любым замечаниям и предложениям. На данный момент готовиться обновленная версия, в которой будет поддержка MRI 1.8, JRuby, а также Rails 2.3. 

Коллекция «Blank» заготовок в скором времени будет расширена другими руби-фреймворками в частности Sinatra и готовыми приложениями, такими как RedMine и другие.

<engine name="python.2.7.pipe"
     fullPath="c:\python27\python.exe"
     arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py"
     transport="pipe" />

Web.config

Конфигурация веб-приложений, работающих через Zoo осуществляется через файл web.config. Вот пример такого файла для конфигурирования Django-приложения для работы в 32-битном пуле:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
  <system.webServer>  
    <heliconZoo>   
      <application name="django.project.x86" >    
      <environmentVariables>     
        <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
        <add name="DJANGO_SETTINGS_MODULE" value="settings" />
        <add name="DEPLOY_FILE" value="deploy.py" />
        <add name="DEPLOY_LOG" value="log\deploy.log" />
      </environmentVariables>   
      </application>  
     </heliconZoo>  
    <handlers>   
    <add name="django.project.x86" scriptProcessor="python.2.7.pipe" path="*" verb="*" modules="HeliconZoo_x86" 
         preCondition="bitness32" resourceType="Unspecified" requireAccess="Script" />
    </handlers> 
  </system.webServer>
</configuration>

Вот важные моменты:

  • scriptProcess="python.2.7.pipe" — ссылка на FastCGI-движок определенный в applicationHost.config;
  • переменная окружения PYTHONPATH — путь, по которым python ищет свои модули; в нашем случае мы добавляем в PYTHONPATH путь к нашему django-приложению;
  • переменная окружения DJANGO_SETTINGS_MODULE — питоний путь к конфигурационному файлу settings.py Django-приложения, например, ‘mysite.settings’
  • переменная окружения ‘DEPLOY_FILE’ — путь к файлу внутри приложения, который будет запускаться перед выполнением первого запросу к приложению после рестарта IIS-приложения. В этом файле нужно выполнять, например, команды для синхронизации БД: ‘manage.py syncdb –noinput’;
  • переменная окружения ‘DEPLOY_LOG’ — путь внутри приложения к файлу, в который будет записываться вывод команды DEPLOY_FILE для отладочных целей. Директория, в которой находится этот лог-файл, должна иметь права на запись для пользователя, от которого работает IIS-приложение (обычно группа IIS_IUSRS).

Статический контент

орк Django не годится для быстрой и безопасной обработки статических файлов (изображений, скриптов, файлов стилей). Статику должен обрабатывать веб-сервер напрямую. Для этого нужно сложить все статические файлы в директорию и выключить в ней обработчик запросов в django-приложение:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
<system.webServer>  
  <handlers>   
    <remove name="django.project.x86" />  
  </handlers> 
</system.webServer>
</configuration>

Пример Django-проекта на IIS 7

Предположим наш django-проект состоит из трех приложений:

  • site — собственно сам сайт с шаблонами, статикой, urls.py и settings.py
  • blog
  • store

Статические файлы, расположенные в site/media будут доступны через виртуальную директорию /media/ (т.е. MEDIA_URL='/media/'). После установки Blank Django Project в корень сайта и копирования нашего django-проекта, получим такую структуру директорий:

/media/ — это виртуальная директория, которая указывает на site/media; в ней отключен Zoo модуль как описано выше. В корневом web.config PYTHONPATH указывает на корень сайта и DJANGO_SETTINGS_MODULE установлен в ‘site.settings’:

... 
<heliconZoo>
   <application name="django.project.x86" >
    <environmentVariables>
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="site.settings" />
    </environmentVariables>

Производительность

И напоследок самое интересное – тестирование производительности. Развернутое тестирование будет позже, сейчас пока «на скорую руку», но и по этим результатам вполне можно судить. Тестовая машина в качестве сервера — Core 2 Quad 2.4 Ghz, 8 Gb RAM, гигабитная сеть. Для генерации нагрузки использовался более мощный компьютер с Apache Benchmark. Для тестирования Apache и Nginx использовалась Ubuntu 11.04 Server x64. IIS 7 тесты работали на Windows Server 2008 R2. Никаких виртуалок — честное железо. В качестве транспорта на Nginx использовали самый продвинутый uwsgi, а также wsgi и fast_cgi для сравнения. Еще на IIS 7 сравнили с PyISAPIе.

В качестве тестовых страниц написали два небольших скрипта. Первый выводит текущее время с высоким разрешением – это сделано для того, чтобы была уверенность что, страницы не берутся из кеша. Второй делает то же самое, но предварительно сохраняет результат в базе данных. Все это через шаблон, чтобы задействовать реальную инфраструктуру Django, база данных – MySQL. Настройки везде по умолчанию, т.к. цель протестировать именно наиболее типичные конфигурации. Итак, результаты (в запросах в секунду):

Тут все более менее понятно и стабильно. Uwsgi впереди, видимо за счет более тесной интеграции с кодом Django — нужно будет его покурить… PyISAPIe сильно отстает, что и понятно.

А вот с базой данных результат не столь стабилен. Почему Nginx + fcgi + MySQL показал столь странные 175 запросов в секунду – не понятно. Результат MySQL на Windows тоже удручает, хотя на shared хостинге проблема возможно и не будет такой критичной. Дело в том что производительность падает в основном из-за каких-то внутренних блокировок в MySQL, сам же сервер практически не нагружен, пока генерирует эти 104 запроса. Можно предположить, что с ростом количества сайтов на сервере, и соответственно ростом количества баз данных, если они не будут блокироваться между собой, суммарная мощность сервера будет достаточной. 

Так что мы решили добавить MS SQL Express к тестам. Его результат тоже понятен – все упирается в сам Python и драйвера базы данных к нему, однако в целом выглядит вполне прилично. PyISAPIe с MS SQL Express не заработал.

Хочется отдельно отметить способность IIS 7 держать большое число подключений. Так IIS 7 + Helicon Zoo с легкостью выдерживал тысячи одновременных подключений (больше нам просто нечем было генерировать), в то время как Ubuntu, с настройками по умолчанию, с ростом числа подключений быстро пасовала. А Apache еще и оказался весьма прожорливым на память. Так с ростом числа подключений Apache потребил около 3-х Гб памяти за 20 секунд теста — дальше не проверяли.

Выводы

Представленное решение показывает стабильную работу и приличную производительность. Оно вполне готово для использования как в качестве среды разработки так и в продакшене. Особенно важной является возможность использования Helicon Zoo различными Windows хостингами, с целью предоставления сервисов Django своим клиентам. Хочется надеяться, что с ростом числа Django серверов на Windows, ее разработчики станут уделять больше внимания отладке и оптимизации своего кода под Windows платформу. Да и армия существующих Windows-разработчиков может стать неплохим подспорьем для нынешних open-source проектов.

Автор статьи: Владимир Юнев