Care.Card UX Contest: React Native + UX Design for better healthcare. Join Now & Win 100 000 SOLVE!
×Закрыть

Инфраструктура Ruby on Rails

rails

С Ruby on Rails в рунете сложилась непростая ситуация: вроде, есть блогеры, о нем пишущие, есть специализированные сайты, но почему-то людям, желающим попробовать рельсы и начинающим rails-разработчикам, найти полезную информацию по Rails крайне трудно.

Знаете, что происходит в итоге? Рождается масса заблуждений препятствующих распространению мощной технологии. Например:

  • «Гибкая разработка веб-приложений в среде Rails» — лучшая книга для любого Rails-разработчика" — бред собачий! Это книга «для чайников», не отражающая реалий rails-разработки.
  • «Rails — это вещь в себе» — еще больший бред. Rails, вообще-то, обладает мощной инфраструктурой, включающей множество сторонних сервисов и библиотек.

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

Развертывание приложения

capistrano

В Ruby есть очень мощный инструмент для работы с удаленными unix-серверами — Capistrano. Он же является стандартом де-факто для развертывания рельсов на production/staging серверах.

Принцип работы Capistrano в контексте рельсов простой — разработчик с локальной машины запускает capistrano, который в свою очередь подсоединяется к удаленному серверу через SSH и выполняет ряд команд: вытягивает свежую версию приложения из репозитория, создает для нее отдельную директорию и устанавливает символические ссылки для директорий со статическим контентом, перегружает веб-сервер и другие сервера (например, сервер для полнотекстовой индексации и поиска данных). Большим плюсом Capistrano в сравнении с аналогичными инструментами является поддержка rollback’ ов. То есть в случае неудачного развертывания проекта Capistrano откатит все в исходное состояние.

Выше описан простейший пример работы Capistrano, который обычно выполняется с помощью его стандартных рецептов (скриптов). Вообще же с помощью капистрано можно можно разворачивать приложения в нескольких окружениях, можно разворачивать приложения сразу на кластерах серверов, можно на этих кластерах удаленно чистить кеш и вообще выполнять любые команды, которые можно выполнить в консоли unix-сервера. Существуют отдельные наборы рецептов капистрано, например capistrano-ext, Dump или rubaidhstrano, позволяющие автоматизировать резервное копирование баз данных и синхронизировать статические файлы (как и базы данных) в локальном окружении разработчика с production’ ом.

Кстати, capistrano совсем не обязательно использовать с рельсами, впервые я с ним столкнулся полтора года назад, тогда с помощью Capistrano мы разворачивали PHP (symfony) -приложения на кластерах серверов.

Нет предела совершенству. В след за Capistrano появились проекты Shadow Puppet и Moonshine. Shadow Puppet — это инструмент для автоматизации настройки самих unix-серверов, с его помощью можно автоматизировать установку всего софта, библиотек, создание пользователей, настройки безопасности — очень полезный инструмент системного администратора. Moonshine представляет собой надстройку над Capistrano и Shadow puppet, позволяющую автоматически настроить «голый» удаленный сервер и развернуть на нем Rails-приложение, имея на удаленном сервере всего лишь пользователя с sudo-правами. К сожалению, в настоящий момент Moonshine поддерживает только Ubuntu Server 8.10 и Git-репозитории.

Существует альтернатива Capistrano — Vlad the Deployer, он проще в использовании, но на фоне Capistrano функционал Влада кажется скудным.

Профилирование, мониторинг производительности, слежение за ошибками

Представим, что вы запустили свой rails-проект. Он оказался настолько удачным, что новость о нем появилась на главной странице Wired или Digg. После чего проект в лучшем случае стал работать очень-очень медленно, в худшем же просто повалился на**й. После этого работа резко принимает авральный характер, вы анализируете тонны логов, заново прогоняете стресс-тесты и прочими способами пытаетесь найти узкие места в системе и устранить проблемы.

Задачу профилирования и мониторинга производительности решают такие сервисы, как Five Runs, New Relic и Scout. Функциональность у всех трех похожа, потому расскажу о таких средствах на примере NewRelic’ а, являющегося лидером тройки.

Когда приложение развернуто в production-окружении, начинает работать специальный rails-плагин NewRelic RPM. Он собирает информацию о каждом запросе к приложению, о каждом запросе к базе данных, времени выполнения этих запросов (и, соответственно, времени загрузки страниц), нагрузке на процессор, вызванной этими запросами. Время от времени эти данные отправляются на сервер NewRelic фоновым процессом. После этого на сайте NewRelic’ а можно посмотреть множество отчетов, показывающих, например, самые медленные контроллеры, самые медленные SQL-запросы и отдельные транзакции, причем, легко можно посмотреть использование индексов в запросах. Кроме того, NewRelic хранит статистику, потому можно отслеживать динамику нагрузок, удобно сгруппированные отчеты об ошибках (мы же не хотим читать длинные логи?) и многое другое.

Естественно, можно использовать NewRelic и в development-окружении, в этом случае он является больше инструментом профилирования, нежели мониторинга и статистики.

Для тех, кому не нужна настолько подробная (и дорогая) статистика, которую дает NewRelic, но нужно удобно отслеживать ошибки, происходящие на production-серверах, есть простой сервис — HopToad. Можно, конечно, для этой цели пользоваться rails-плагином с говорящим именем «Exception Notifier», но он может в определенных ситуациях может неприятно заспамить ваш почтовый ящик.

Тестирование, проверка качества кода

Честно говоря, автоматическое тестирование — один из моих любимых аспектов Rails, такое обилие разнообразных крутых инструментов тестирования я видел, пожалуй, только в Java.

По умолчанию рельсы используют стандартный рубишный Test: Unit в качестве тест-фреймворка. Однако, в последнее время все более модным становится т.н. Behavior Driven Development, и в руби появился свой BDD-фреймворк — RSpec, который плотно интегрируется с рельсами. Судя по коду разных современных проектов, RSpec в ruby-мире сейчас даже более популярен, чем Test: Unit.

В RSpec входит собственное средство для создания mock-объектов (необходимых, например, при тестировании контроллеров), однако вместо него можно использовать более развитые Mocha и Flex Mock.

С целью минимизации времени, затрачиваемого на рутинное написание тестов, был разработан Shoulda — набор макросов для совместного использования Rails и Test: Unit. Посмотрите, насколько более простым и читабельным он делает код тестов. Специально для людей, предпочитающих RSpec был выпущен аналог Shoulda под названием Remarkable.

Для заполнения приложения тестовыми данными в рельсах по умолчанию применяется механизм fixtures, однако это не всегда удобно, например, в случаях, когда нужно сгенерировать много сущностей, — в таких случаях на помощь приходит генерация через фабрики объектов, наиболее известным средством для этого в рельсах является factory_girl.

Хотите «настоящего» BDD, чтобы можно было описывать требования к будущему функционалу простым языком и в итоге превращать их в функциональные/интеграционные тесты? — попробуйте Cucumber. Если вам, как и мне, Cucumber кажется излишеством, существует другой мощный инструмент — WebRat. Задача «крысы» — интеграционное тестирование, то есть пройтись по страницам сайта, прокликать формы, убедиться в том, что сервер вернул ожидаемый результат. Сценарии WebRat писать очень просто и он интегрируется с любыми тест-фреймворками для Ruby. В обычном режиме работы WebRat’ у даже не нужен броузер для прогона тестов. Однако бывают ситуации, когда нам необходимо тестировать операции, выполняемые JavaScript’ ом, в этом случае WebRat можно запустить в другом режиме работы: он будет использовать Selenium (который, в свою очередь, использует броузер) для прогона тестов. Поддерживать же подобные webrat-тесты ощутимо проще, чем чистые Selenium-тесты.

Специально для проверки уровня покрытия кода тестами существует инструмент RCov. Кроме RCov, существуют инструменты для автоматической проверки сложности кода и просто «детекторы г*внокода». Их можно запускать по отдельности, а можно воспользоваться metric_fu, включающим в себя все эти проверки вместе с rcov.

Непрерывная интеграция

При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «****** в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция». Для Ruby в целом и рельсов в частности существует своя версия известного CI-средства — CruiseControl.rb. Существует также альтернатива — Integrity, но ее я ни разу не пробовал.

Сервера приложений

mongrel

Стандартным сервером приложений Rails является однопоточный Mongrel. Как правило, его запускают кластером из нескольких серверов, после чего балансируют нагрузку между ними при помощи apache или nginx. Такой способ запуска Rails-приложений является наименее эффективным (с точки зрения потребления ресурсов) из всех возможных.

passenger

Лучшим решением запуска rails-приложений является Phusion Passenger (также известный как mod_rack и mod_rails). Passenger встраивается модулем в веб-серверы Apache и Nginx и динамически выделяет ресурсы рельсам, подобно mod_wsgi для python и mod_php для PHP. Естественно, это позволяет экономнее расходовать ресурсы сервера и упрощает развертывание приложений.

Для полноты картины стоит отметить Thin. Это сервер, работающий аналогично Mongrel’ у, но быстрее и потребляя при этом меньше ресурсов.

Асинхронное выполнение задач

Существует ряд задач, которые выполняются сравнительно долго, например, конвертация видео или загрузка файлов на Amazon S3. Такие задачи желательно (а во многих случаях — обязательно) выполнять в фоне. Долгое время наиболее распространенным инструментом асинхронного выполнения задач в рельсах был BackgroundRB, однако brb потребляет неприлично много ресурсов, потому рекомендую альтернативный инструмент — Workling.

По умолчанию Workling работает в паре с message queue сервером Starling, разработаным изначально для Twitter’ а, однако не советую использовать Starling в production’ е. Вместо старлинга можно использовать любой amqp-совместимый сервер, например, RabbitMQ или ActiveMQ.

Мониторинг процессов

Одним из главных недостатков Ruby являются утечки памяти. В Ruby Enterprise Edition и Ruby 1.9 эту проблему частично решили. Но в суровые времена, когда все гоняли рельсы сугубо на Mongrel’ ах и Ruby 1.8.6, проблема стояла значительно серьезнее, чем сейчас, потому необходимым было средство, которое следило бы за процессами Mongrel’ а и перегружало его при достижении лимита потребляемой памяти. Чаще всего для этих целей использовали совсем не рубишный Monit и его Ruby-аналог — God (который, на мой взгляд, значительно удобней и гибче в конфигурации). Доходило даже до того, что все процессы мониторили God’ ом, а сам God — Monit’ ом.

К счастью, ситуация стала лучше, но God и Monit (который использовался и используется для мониторинга баз данных, веб-серверов и многих других вещей в unix-системах) все еще остаются простыми и удобными средствами мониторинга процессов, сфера применения которых выходит далеко за рамки перегрузки Mongrel’ а при достижении лимита памяти.

Запуск консольных команд

Давно уже для Ruby разработали Rake — инструмент для автоматизации сборки программного кода по типу GNU Make или Apache ANT. Но, в отличие от Make и ANT, Rake-скрипты пишутся на самом Ruby, что сделало их легко расширяемыми и более удобными в написании. В итоге в Rails стали использовать Rake для выполнения любых консольных команд, например, для запуска тестов, миграций или обновления Rails.

Также существуют дополнительные наборы Rake-задач, выполняющие рутинные операции, например: создание резервных копий базы данных и статических файлов rails-приложения, отображение информации о внешних ключах в базе данных, для которых нет индексов, и многие другие. Отличные примеры дополнительных rake-задач для Rails — limerick_rake и dump.

Визуализация объектной модели

В данном случае лучше один раз увидеть. RailRoad рисует диаграммы объектной модели ваших Rails-приложений. Посмотрите примеры моделей и контроллеров.

Специализированый хостинг

Большинство коммерческих Rails-проектов хостятся на VPS’ ах, выделенных серверах и cloud-хостингах вроде Amazon EC2. Однако существуют и специализированные Rails-хостинги (большая их часть — это все те же VPS’ ы и надстройки над EC2, куда уже установлены популярные ruby/rails библиотеки, apache с passenger’ ом и.т.п.).

Среды разработки

Существует стереотип, будто все rails-разработчики используют для разработки либо TextMate на маке, либо юниксовые vim/emacs/gedit, и для Ruby/Rails нет «взрослых» IDE.

Отчасти это правда, действительно подавляющее большинство Rails-разработчиков не пользуются IDE, но далеко не все! Качественные IDE для Ruby существуют: Aptana RadRails на основе Eclipse, JetBrains RubyMine на основе IntelliJ Idea, NetBeans (который мне не удалось запустить на маке). Лично я предпочитаю RubyMine за его отслеживание ошибок в коде, автодополнение, удобный поиск внутри проекта, отладку кода прямо в IDE и автоматизацию рефакторинга.

В целом, как мне кажется, ситуация с IDE для Ruby хуже чем у Java и.NET, но лучше, чем у Python и PHP.

Вместо заключения

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

Источник: mourk.com

LinkedIn

25 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

: вроде, есть блогеры,

Просто отличный показатель для языка, в ковычках

Спасибо автору за обзор.> tobto: Я имел ввиду, что система забюрократизирована — дизайнеры, svn, релизы, откаты, тестирование.Правильно, надо сразу править на продакшен сервере. Все начнется с ’поставить прочерк’, а закончится тестированием на сервере клиента.

Статья — одна из тех немногих жемчужин, которые крайне редко рождаются в бескрайнем океане информации Нета."Инфраструктура Ruby on Rails" — кладезь практических советов. Автору респект! (Блог Александра уже в «Избранном» )

Спасибо большое за потраченное время, если я захочу начать изучать руби (а я захочу:)), то стартапом будет эта статья.

Вообще-то стиль написания никакой. Воспринимается как — вы все бредите, а я один знаю истину. Насчет поиска полезной инфы — учите английский, господа.

2paules — я в порядке2Александр Маненко — спасибо! Я имел ввиду, что система забюрократизирована — дизайнеры, svn, релизы, откаты, тестирование.

тобто: если текст хранится в базе, то должен быть интерфейс редактирования к нему. Вот в нём и меняете. Если же текст на страничке, то тоже нет проблем.Вообще же вопрос меня поверг в смятение, мне он показался синонимом к «как нажать знак подчёркивания на клавиатуре». Наверное я не так понял?

имеется ввиду, что мне нужно сделать in-site optimisation, те — поработать с html/css или с текстом/контентом. Я прошу добавить прочерк у одного слова. И? Опишите прохождение моего запроса, плз, в рубиновой стране.

Не совсем понял, о чём статья. Перечисление околорельсовых вещей? Совет новичку? Попытка донести хорошие идеи в массы? Для меня выглядит как «I know Kung-Fu! ».

и покажите мне — способ как вводить изменения в текст чтобы увидеть реальную отдачу контента.

А можно поподробнее? Я лично ничего не понял: о)

поработав с позиции seo с рельсами — могу сказать, что рельсы и оптимизация, все равно, что Шварцнегер на воздушном шаре. идея прекрасная, но недоработанная. и покажите мне — способ как вводить изменения в текст чтобы увидеть реальную отдачу контента. вы не поверите — ЭТО НЕДЕЛИ! у меня нет времени ставить рельсовые понты. Я работаю с xhtml/css. И если девелопмент движется как улитка, обрастая комментами, коммитами, сверками, мониторингом, разрушенными билдами, «с целью минимизации времени, затрачиваемого на рутинное написание тестов»... я не верю в такие предсказания. добавьте 150 чел, которые прокладывают рельсы, руководствуясь «тестированием и непрерывной интеграцией, отладкой и профилированием, автоматизацией проверки качества кода, выполнением асинхронных задач, развертыванием приложений на серверах и его мониторинг»... н е е е е ет! не нужно! Дайте пистолет!!!

Неуспешность операции, если вылетело исключение ruby (это, например, если процесс вернул ненулевой код)

А как осуществляется откат операции? Если у меня, например, была операция «отправить все письма из тестовой очереди»? Как их вернуть назад?

А с миграциями дело обстоит вот так: http://guides.rubyonrails.org/...Собственно это ж такая простая штука, какие проблемы могут быть с ними в том же python’е?

Операция простая, но осуществляется по разному. В рельсах миграции оперируют низкоуровневыми понятиями таблицы и колонки, для джанговских моделей есть несколько реализаций миграции, начиная от SQL-only до работающих исключительно на уровне ORM-моделей. По поводу проблематики миграций в приложении к Django, а также если есть желание ознакомиться с существующими решениями, я бы порекомендовал почитать вот эту статью. Лично мне нравится South — работает в основном на уровне моделей, что удобно, но позволяет в случае необходимости переключаться на SQL, но есть и другое мнение на этот счет.

Сергей ТарковскийСпасибо за Fabric, не знал о такой классной штуке.

спасибо за статью — весьма позитивная и развернутая, узнал кое-что новое.несколько дополнений: 1) «Гибкая разработка веб-приложений в среде Rails» — адекватная книга, признанная многими разработчиками, которая написана в соавторстве в основателей Rails! Интересно, какая из глав не понравилась автору данной статьи, но я читаю эту книгу увлеченно и без остановки. Меня интересует, читал ли автор этой статьи 3-е издание, выпущенное весной этого года, в которой очень много поправок и доработок? Какие еще из празнанных бестселлеров (http://www.pragprog.com/titles) собирается неаргументированно разгромить автор?:) 2) «Rails — это вещь в себе» — за полтора года ни разу ни каком из форумов, рассылок не встречал подобной фразы. Все знают, что более 90% ресльсовых проектов используют сторонние библиотеки. Достаточно хотя бы посмотреть код любого крупнго/среднего опен-сорс проекта на github.com3) Развертывание приложения — дополню: капистрано работает в 2-х режимах, а именно а) делает svn export на локальный комп, архивирует и делает scp на удаленный сервер, б) делает svn export прям на удаленном сервере, что, естественно, быстрее. Это существенная деталь.Настроить сервер для рельс — я написал статью, с помощью которой за 1 час ты имеешь хорошо сконфигурированный сервера для любого rails приложеня http://habrahabr.ru/blogs/ruby.../4) Профилирование, мониторинг производительности, слежение за ошибками — FiveRuns беспатная в течение первого месяца и имеет ужасный суппорт, мне пришлось отказаться от этого сервиса. Приложение глючит из-за этого плагина, проверено неоднократно.Hoptoad — отличная замена exeptions notifier, первый я использую более полугода, отличный вебсервис — коллектор исключений. Насколько мне известно, он только для Rails. Есть похожий сервис, написанный новосибирской компанией yoursway.com, который разрабытывается для разных языков и платформ, но он будет платный.5) Непрерывная интеграция — CruiseControl.rb отличная штука, видел в действии, потрясает:) 6) Сервера приложений — ничего не сказано про Ruby Enterprise Edition, который позволяет экономить до 30% памяти в связке с mod_rails. Про thin замечено совершенно верно — он экономнее, нежели mongrel, но! mongrel юзают Rails Core Team и рано списывать его со счетов. Кроме того, Thin не поддерживается долгое время, соотвественно, не рекомендуется его использовать в продакшин окружении — будет ли команда разраработчиков Thin отвечать на баг репорты?:) 7) Асинхронное выполнение задач — автор статьи просто выпал из реальной жизни, он видимо не пробывал BackgroundRB, Workling. Заставить работать эти плагины сродни пересборке ядра линукса руками секретарши:) Есть замечательный плагин DelayedJob, который был вычленен из Shopify. Его используют очень многие, в том числе и я.8) Запуск консольных команд — весьма скудное описание того, что делает rake. Нет упоминание о том, что rake позволяет показать список таблицы маршутизации приложения, очистить кэш, лог файлы, настроить TimeZones, запустить DelayedJob, установить плагины, облегчить создание документации приложения, выполнить создание базы данных, запустить миграции, запустить кастомные rake задачи.9) Визуализация объектной модели — от использования RailRoad отказались многие, ибо это недостаточно хороший инструмент, если не сказать — бесполезный. Я неоднократно использовал его, но не получил никаких бенефитов — хотя бы потому, что не понимает популярные полиморфные ассоциации между моделями.10) Специализированый хостинг — весьма скудный обзор! нет упоминания про linode.com, mosso cloud. Нет описания как работает очень популярный гем heroku — это не просто хостинг, а полноценная автоматизированная площадка для развертывания приложений. к сожалению, цены на их услуги немного кусаются:) 11) Среды разработки — автор упоминает RubyMine за его преимущества, хотя они давно уже есть в NetBeans IDE, которые уже более 2-х лет разрабытывается модуль для Ruby. RubyMine — разрабатывается русскими девелоперами не так много времени, а также он платный. Кстати, на mac ставится за полчаса, нет ничего сложного.В целом статья неплохая, но местами некомпитентность автора и выдергивание текста напрямую мешает восприятию статьи. Тем не менее, спасибо автору

Неуспешность операции, если вылетело исключение ruby (это, например, если процесс вернул ненулевой код) А с миграциями дело обстоит вот так: http://guides.rubyonrails.org/...Собственно это ж такая простая штука, какие проблемы могут быть с ними в том же python’е?

Очень интересно обсудить поднятую тему в сравнении аналогичными средствами из мира Python. Касательно деплоймента (предлагаю начать сравнение с этого) — я пользуюсь Fabric, и других хороших средств я не знаю. Судя по всему, вряд ли уровень Фабрика дотягивает до Капистрано, но во всяком случае, что касается практических нужд, он сэкономил мне немало времени и нервов:) Умеет выполнять локально и удаленно команды оболочки, в том числе и от имени суперюзера, передавать туда и обратно файлы, может обрабатывать массово несколько удаленных хостов.Интересно, как в Капистрано реализован откат операции? На основании чего определяется ее успешность/неуспешность? P.S. И, кстати, не раскрыта тема миграций БД в рельсах — я был бы благодарен за освещение (в одной из последующих статей?) этой преинтереснейшей области.

NetBeans прекрасные IDE, есть практически всё. Единственное чего не хватает, так это генерирование диаграмм по типу RailRoad.Ксати в RubyMine’е это есть, да и сам он намного по-приятнее, всё сделан на основе IntelliJ Idea, но пока еще сыроват. Сам постепенно на него перехожу.

Не согласен с автором насчет того, что Cucumber — излишество, в остальном — статья отличная. Отдельное спасибо за RailRoad и Shadow Puppet. 5/5

мда. обсуждение жгёт... 80% каментов относятся к ~0.1% статьи.

Поддерживать же подобные webrat-тесты ощутимо проще, чем чистые Selenium-тесты.

а в чём это выражается? у крысы есть адаптер-конвертер в селениум на лету или как?

Судя по комментариям читатели кроме мата ничего в статье не поняли или, по крайней мере, не нашли более достойных тем для обсуждения.Меня удивили проблемы с запуском NetBeans под маком. Большинство функций которые автору нравятся в RubyMine в NetBeans тоже есть.

Спасибо за большое количество интересной информации. Лично я тоже против мата. ИМХО он уместен в некоторых контекстах, в которые не входит качественная техническая статья для широкой публики.;)

Для меня мат не ассоциируется с чем-то серьёзным. А статья вроде как серьёзная и познавательная. Это как взять и посолить чай. Да и не люблю я мат.

Хорошая статья. Хотя я пока еще новичок в рубях, но весьма позновательно.

А меня не порадовало наличие мата, так не надо писать.

Подписаться на комментарии