Среда и конфигурирование Rails

Rails вызывает такой интерес не в последнюю очередь потому,
что я не пытался угодить людям, не испытывающим тех же
проблем, что я сам. Отделение эксплуатационной среды
от среды разработки составляло для меня серьезную проблему,
и я решил ее наилучшим способом, который смог придумать.
Дэвид Хейнемейер Хэнссон

Приложения для Rails заранее конфигурируются в трех стандартных режимах: разработка, тестирование и эксплуатация. Каждый из них соответствует некоторой среде исполнения и ассоциирован с набором параметров, которые определяют, например, к какой базе данных подключаться и надо ли перезагружать составляющие приложение классы при каждом запросе. При желании совсем нетрудно создать собственную среду.

Текущая среда задается переменной окружения RAILS_ENV, которая содержит имя требуемого режима работы и соответствует файлу с параметрами среды в папке config/environment. Поскольку параметры среды
управляют рядом фундаментальных аспектов поведения Rails, в частности загрузкой классов, то для понимания пути Rails вы должны хорошо представлять себе назначение параметров среды.

Мы познакомимся с тем, как Rails запускается и обрабатывает запросы, для чего рассмотрим сценарии boot.rb и environments.rb, а также параметры трех стандартных режимов. Кроме того, мы затронем тему определения собственной среды и поговорим о причинах, покоторым это может понадобиться.

Запуск

Одна из первых задач любого процесса, обрабатывающего запросы к Rails (например, сервера Webrick), – загрузка файла config/environment.rb. Взгляните, например, на строку в начале файла public/dispatch.rb: require File.dirname(__FILE__) + “/../config/environment” Другим процессам, которым необходима вся среда Rails (например,
консоли и вашим тестам) также требуется файл config/environment.rb, поэтому вы обнаружите предложение require в начале таких файлов, как test/test_helper.rb.

Параметры среды по умолчанию

Последовательно рассмотрим параметры в подразумеваемом по умолчанию файле environment.rb, который читается в процессе начальной загрузки приложения для Rails 1.2.

Переопределение режима
Первый параметр касается только тех, кто развертывает приложение в среде виртуального хостинга (shared hosting). Он закомментирован, так как устанавливать режим работы Rails в этом месте приходится редко:

# Раскомментируйте следующую строку, чтобы принудительно перевести Rails
# в режим эксплуатации, если вы не контролируете веб-сервер или сервер
# приложений и не можете настроить его правильно
# ENV[‘RAILS_ENV’] ||= ‘production’

Предостережение. Если здесь вы присвоите переменной окружения RAILS_ENV или, если на то пошло, константной переменной RAILS_ENV значение production, то все в Rails будет работать в режиме эксплуатации. Например, ваш набор тестов будет функционировать неправильно, поскольку сценарий test_helper.rb устанавливает RAILS_ENV в test непосредственно перед загрузкой среды.

Версия Rails Gem
Напомним, что в этот момент среда Rails еще не загружена. На самом деле, сценарий должен найти и загрузить платформу до совершения других действий. Этот параметр говорит сценарию, какую версию Rails загружать:

# Задает используемую версию gem-пакета Rails, когда каталог
# vendor/rails отсутствует
RAILS_GEM_VERSION = ‘1.2.3’

Как видите, на момент написания этой главы последняя версия Rails (которую я на самом деле установил в виде gem-пакета) имела номер 1.2.3.

Этот параметр не принимается во внимание, если вы «сидите на острие» (running edge). Под этим в сообществе понимают, что вы запускаете замороженный образ Rails, хранящийся в подкаталоге vendor/rails вашего проекта. Чтобы скопировать последнюю версию Rails из репозитория в свой каталог vendor/rails, включите в проект команду rakerails:freeze:edge.

Начальная загрузка

Следующие строки в файле environment.rb – это место, где колеса начинают крутиться после загрузки файла config/boot.rb:

# Начальная загрузка среды Rails, платформа и конфигурации по умолчанию
require File.join(File.dirname(__FILE__), ‘boot’)

Обратите внимание, что этот сценарий загрузки генерируется как часть вашего Rails-приложения, но редактировать его не следует. Я вкратце опишу, что он делает, так как это может оказаться полезно для поиска причин ошибок при установке Rails.

Сначала сценарий начальной загрузки убеждается, что установлена переменная окружения RAILS_ROOT; она содержит путь к корню текущего проекта Rails. Переменная RAILS_ROOT повсеместно используется в коде Rails для поиска различных файлов, в том числе шаблонов представления. Если она не установлена, то в качестве значения задается путь к каталогу на один уровень выше текущего (напомню, что мы находимся в каталоге config).

«Острие Rails»

Есть такое выражение: «Если ты не сидишь на острие, то занимаешь слишком много места». Для большинства разработчиков на платформе Rails «сидеть на острие» означает пользоваться последней (и, хочется надеяться, самой лучшей) версией Ruby on Rails.

Разработчики ядра Rails выкладывают свои файлы в открытый репозиторий системы управления версиями Subversion. С давних пор тех, кто запускает свои приложения в официально не выпущенной версии Rails, чтобы воспользоваться новыми функциями и не сталкиваться с уже исправленными ошибками, принято называть сидящими на острие Rails. Для этого вам нужнолишь извлечь код Rails из хранилища в каталог vendor/rails своего приложения.

В октябре 2005 года в стандартный rakefile Rails были добавлены задания для автоматизации процесса заморозки и разморозки приложения, то есть привязки его к конкретной версии «острия»: rails:freeze:edge и rails:unfreeze.

Если вы еще не знакомы с этим феноменом, то может возникнуть вопрос, зачем кому-то в здравом уме необходимо разрабатывать приложение на основе заведомо нестабильной версии ПО. Для большинства из нас мотивом служит желание иметь в своем распоряжении самые свежие возможности, и, к счастью, такое решение оказывается не столь уж безумным. История убеждает, что основная ветвь Rails остается вполне стабильной. В 2005 году, когда осу-
ществлялся переход к версии Rails 1.0, я разрабатывал, «сидя наострие», проект для большого корпоративного клиента. Мы осознавали риск, но в острие был ряд критически важных нововведений и исправлений ошибок, без которых мы не могли работать. На протяжении нескольких месяцев наша версия Rails обновлялась до двух раз в неделю, и был лишь один случай, когда неожиданная ошибка оказалась связана с проблемой в ядре Rails.

Своей стабильностью острие обязано прежде всего широкому тестовому покрытию Rails. Регрессионные тесты эффективно предотвращают проникновение ошибок в код ядра. Любая заплата, предлагаемая разработчикам ядра, должна включать адекватные автономные и функциональные тесты, иначе она даже не будет рассматриваться. Принципы гибкого программирования в Rails – это не просто общий курс, а религиозный догмат.

Но после выхода Rails 1.2 работа на острие перестала быть насущной необходимостью, поэтому разработчики ядра настоятельно отговаривают от такой практики. Официально выпущенные версии достаточно хороши для большинства разработчиков. И все же иногда острие Rails бывает полезно. Например, это позволило нам обсудить в данной книге многие особенности Rails 2.0 еще до выхода официальной версии 2.0.

На платформах, отличных от Windows, используется стандартная библиотека Ruby pathname, чтобы удалить из пути соседние символы косой черты и бесполезные точки:

unless RUBY_PLATFORM =~ /mswin32/
require 'pathname'
root_path = Pathname.new(root_path).cleanpath(true).to_s
end

Теперь сценарий загрузки должен определить, какую версию Rails использовать. Первым делом он проверяет, есть ли в вашем проекте подкаталог vendor/rails. Это означало бы, что вы «сидите на острие»:

File.directory?("#{RAILS_ROOT}/vendor/rails")

Это самый простой случай. Если же вы не «сидите на острие», а я подозреваю, что большинство разработчиков Rails не сидят, то сценарию придется еще поработать и найти пакет RubyGem, содержащий Rails.

КОММЕНТАРИИ