Rails trafi pod strzechy – to już nieuniknione?

Rails jest fajnym narzędziem dla każdego webdevlopera. Móc pracować z tym frameworkiem to czysta radość. Przynajmniej tak długo jak zrządzający projektem jest w porządku. Zły PM zabije radość z każdego projektu :) ale to temat na niejeden post ;)

Jak dotąd był chyba jeden powód, dla którego Railsy nie stały się powszechne, jak nie przymierzając PHP ;) – braki w hostingu. A było tak nie bez przyczyny, gdyż Rails potrzebował dość skomplikowanej konfiguracji (w porównaniu z PHP) do pracy – serwer WWW we 'frontendzie’ działający jako reverse proxy, plus kilka instancji Rails wraz z serwerem WWW do obsługi zapytań HTTP (kilka, bo niestety Rails nie jest thread safe i zapytania HTTP są przetwarzane liniowo, po jednym). Dla większych aplikacji nie jest to problem, bo i tak względy wydajnościowe wymuszają taką architekturę. Niestety może to być problem w czasie pisania aplikacji, albo gdy aplikacja z założenia jest pisana z myślą o małym ruchu (wszelkie jednostrzałowce).

Było to problemem, bo wygląda na to, że mod_rails (a dokładniej Phusion Passenger aka mod_rails) zmienia radykalnie reguły gry. Jak nazwa wskazuje, jest to rozwiązanie dla serwerów Apache, oparte na takiej samej filozofii jak inne moduły. Czyli – zakładając, że Passenger oraz baza danych jest już skonfigurowana, wgrywamy po prostu pliki aplikacji Rails w katalog wskazany w konfiguracji Apache’a. I tyle. Czyli – Rails pod strzechy?

CC: by-sa by zakwitnij

Zalety? Gdy przychodzą kolejne zapytania HTTP do aplikacji Rails, mod_rails w razie potrzeby uruchamia kolejną instancję aplikacji aby sprawnie obsługiwać ruch. Maksymalna liczba instancji jest globalnym ustawieniem na cały serwer WWW (nie na hosta wirtualnego). Oznacza to, że jeśli mamy kilka ’drobnych’ aplikacji Rails na jednej maszynie zasoby będą przydzielane zgodnie z bieżącym obciążeniem (instancje są wyłączane po określonym czasie, gdy nie ma żadnego zapytania HTTP do tej konkretnej instancji). W wersji nginx/mongrel musimy określać na sztywno ile instancji jest przeznaczonych dla każdej aplikacji (działają one zawsze niezależnie do obciążenia, co oznacza, że pamięć też zajmują cały czas).

Wady? Na pewno takie są. Zarządzanie gemami będzie trochę więcej wymagało lokalnego instalowania (w aplikacji), ale to jest wspólna cecha współdzielonego hostingu. Ponadto, zdaje się, że wciąż grożą wycieki pamięci (ale topfunky jednak chwali ;) czyli niewątpliwie jest coś na rzeczy).

Z tego co widzę, mod_rails ma zdecydowaną przewagę nad mod_php w istotnym aspekcie. Każdy proces Rails jest odpalany z właścicielem ustawionym w pliku konfiguracyjnym Apache lub tak jaki użytkownik jest właścicielem config/environment.rb. W prawdziwie współdzielonym hostingu znaczy to tyle, że można zabezpieczyć kod aplikacji przed podglądnięciem przez innych użytkowników serwera. Jest to takie proste, gdyż Rails działa jako oddzielny proces a nie jak PHP, gdzie interpreter jest częścią serwera WWW, i co za tym działa domyślnie z uprawnieniami wspólnymi dla wszystkich. Dlatego katalogi z aplikacjami Rails mogą być dostępne do odczytu tylko dla właściciela.

Zmieni to obraz pola bitwy?

Sądzę, że tak. Na dłuższą metę jest to kolosalna zmiana zarówno z punktu widzenia społeczności Rails (stanie się znacznie bardziej popularne, czyli społeczność znacznie się rozrośnie), obecnie żyjących z pisania w Rails (zarówno większa konkurencja jak i znacznie większy tort do podziału) oraz biznesu (znaczne zwiększenie liczby programistów co zwiększa bezpieczeństwo wyboru Rails jako podstawy aplikacji).

Zmiany będą pewnie burzliwe i pewnie wielu będzie z nostalgią wspominało dawne czasy (ehhh panie, przed wojną, to były Railsy!) ale ja sądzę, że zmiany przyniosą też wiele dobrego – nowe pomysły, nowe idee. Ferment do tego jest niezbędny.

A wy co o tym sądzicie – czy dobrze, że Railsy zmierzają w stronę stania się naprawdę powszechnym narzędziem w web developerce?