Passenger mod_rails

Jarosław Zabiełło — Sat, 19 Apr 2008 05:31:00 +0200

Choć sam Rails jest intuicyjny i prosty w użyciu, to już sposób użycia go na serwerze produkcyjnym (gdzie liczy się głównie szybkość i stabilność) nie jest takie oczywiste z powodu istnienia wielu, alternatywnych rozwiązań. Powstały niedawno moduł dla Apache – mod_rails – może wszystko zmienić. Dzięki niemu uruchomienie Rails na serwerze staje się praktycznie tak samo trywialne jak w przypadku PHP i modułu mod_php!

Muszę przyznać, że początkowo byłem dosyć sceptycznie nastawiony do pomysłu mod_rails. Przede wszystkim, dziwnym wydawało się tworzyć moduł do Apache’a dla frameworka, czyli w sumie aplikacji, a nie dla samego języka Ruby. Niestety, istniejący od jakiegoś czasu mod_ruby był niedopracowany i krytykowany do tego stopnia że użycie go do Rails jest po prostu niezalecane. Dlatego od samego początku, gdy pojawił się Rails, promowano inne rozwiązanie (oparte na FastCGI). Pierwsze wydanie “Agile Web Development with Rails” jeszcze to promowało. W drugim wydaniu (wydanym również po polsku) autorzy przyznali że to rozwiązanie nie było wolne od szerego problemów. Na szczęście pojawił się Mongrel i bardzo szybko kombinacja szybkiego serwera HTTP z przodu + load balancing do klastera z mongreli stała się główną metodą używania Rails na serwerze produkcyjnym. I choć później pojawiły się jeszcze rozwiązania asynchroniczne (Swiftiply i evented_mongrel, Thin, Ebb), to zasadniczo niewiele wnosiły do rozwiązania standardowego poza trochę większą szybkością i innym (właśnie asynchronicznym) typem pracy.

Do tej pory sympatycy Ruby on Rails trochę smętnie poglądali na prostotę uruchamiania aplikacji “tego paskudnego pehapa” za pomocą modułu mod_php. To dzięki niemu PHP zdobył swoją popularność. Stworzenie prostej strony webowej stało się banalnie proste i nie wymagało dodatkowej wiedzy o load balancingu, ustawianiu buforowania, sposobie restartu klastera mongreli itp. Po prostu wrzucam plik i działa. Nawet sam DHH zaczął ostatnio wzdychać za taką prostotą uruchamiania aplikacji.

Stworzony mod_rails ma ambicję aby uruchomienie Railsów było tak proste jak to tylko możliwe. Z tego co mogłem sprawdzić, faktycznie działa to świetnie. Praktycznie nie jest wymagana żadna konfiguracja. Wystarczy raz ustawić Apache’a i można skupić się na budowaniu aplikacji. Domyślnie mod_rails uruchamia Rails w trybie produkcyjnym więc zmiana kodu wymaga przeładowanie aplikacji. Jednakże cała taka operacja sprowadza się do stworzenia pustego pliku restart.txt w podkatalogu tmp. Gdy Apache znajdzie taki plik, błyskawicznie przeładowuje pliki Rubiego i usuwa plik. Nie trzeba też zastanawiać się jak wyklucząć przetwarzanie plików statycznych i tworzonych przez mechanizm cache w RoR, mod_rails robi to automatycznie. Do tego zapewniona jest także ładna obsługa błędów. Po prostu wygląda to rewelacyjnie.

Jak z wydajnością? Jest całkiem nieźle. Autorzy twierdzą, że mod_rails jest trochę szybszy od thin’a. Mnie wyszło trochę odwrotnie, ale też nie robiłem zbyt drobiazgowych porównań. Nawet jeśli klaster serwerów thin czy ebb pracuje trochę wydajniej, to pokusa prostoty i wygody użycia mod_rails jest trudna do odparcia. Szkoda tylko, że mod_rails, jak sama nazwa wskazuje, pracuje tylko z Ruby on Rails. Dobrze by było, żeby później powstała podobna obsługa dla Merb’a (Choć Rails się także rozwija, Merb wciąż go mocno wyprzedza wydajnościowo. Tak z prostych testów mi wyszło, że potrafi być szybszy nawet 2-3 razy). Nie można jednak autorom mod_rails mieć przecież za złe, że poświęcili się najpopularniejszemu frameworkowi.

Passenger mod_rails to nie ostatnie słowo w sprawie deployingu Railsów. Podobną prostotą charakteryzuje się JRuby on Rails, ale o tym następnym razem.

"Passenger mod_rails" by Aleisterc

Mon, 21 Apr 2008 17:16:49 +0200

Ciekawe czy to poprawi sytuacje na rynku hostingu dla RoR…?

"Passenger mod_rails" by Jan Koprowski

Mon, 21 Apr 2008 07:32:28 +0200

Bardzo chciałbym zobaczyć coś takiego w mod_php i mod_python oraz mod_ruby i innych. Swoją drogą … na dzień dzisiejszy jedyne rozwiązanie to spawn-fcgi albo fastcgi + execwrap ale na serwery gdzie jest 7000 userów nie nadają się ponieważ jeden spawn procesu PHP zajmuje już 25 MB o django na flup (ok 50MB) nie wspomnę – serwer po prostu by się zarżnął.

"Passenger mod_rails" by Pawel Rutkowski

Sun, 20 Apr 2008 20:46:15 +0200

hmmmm :) brzmi ciekawie i zachecajaco :) Bede musial sie chyba tym pobawic. Ale uzywanie mod_rails wydaje mi sie troche malo geekowe ;)

"Passenger mod_rails" by Jarosław Zabiełło

Sat, 19 Apr 2008 21:10:01 +0200

Właśnie sprawdziłem. Działa doskonale. mod_rails rozpoznaje właściciela plików i uruchamia RoR w aspekcie tego usera. Jeśli user nie istnieje w systemie albo jest nim root, to wtedy jest aplikacja RoR jest odpalana w aspekcie usera domyślnego, którego można ustawić (jeśli nie, to będzie to user nobody). mod_rails nigdy nie uruchomi aplikacji RoR w aspekcie roota jeśli o to chodzi.

"Passenger mod_rails" by Pawel Rutkowski

Sat, 19 Apr 2008 09:52:47 +0200

A jak wyglada kwestia uprawnien ? Niby pisza ze jest “user switching” i aplikacja wykona sie z uprawnieniami ownera config/enviroment.rb ale za to apache musi byc odpalony jako root (domyslam sie ze chodzi o to zeby nie zrzucal uprawnien (sic!)). Testowales ten aspekt ?

Jarosław Zabiełło - BLOG: Passenger mod_rails

Passenger mod_rails

"Passenger mod_rails" by Aleisterc

"Passenger mod_rails" by Jan Koprowski

"Passenger mod_rails" by Pawel Rutkowski

"Passenger mod_rails" by Jarosław Zabiełło

"Passenger mod_rails" by Pawel Rutkowski