Każdy kto choć odrobinkę siedział w administracji serwerami zna temat hostowania aplikacji. Gdy mowa o PHP zazwyczaj mówi się tylko o mod_php i temat jest prosty. Znacznie
ciekawiej maluje się hostowanie aplikacji napisanych w innych językach: między innymi ruby czy python.
Starsi wujkowieBardziej wymagający użytkownicy, których aplikacje miały działać z uprawnieniami właściciela pliku albo być wrappowane przez suexeca konfigurowało się z wykorzystaniem CGI lub jego bardziej wydajnego kolegi
FastCGI. Istniejące w różnych odmianach dobrze służyły aplikacjom webowym serwowanym z odrębnymi uprawnieniami, zwiększając bezpieczeństwo i wygodę operowania na zasobach znajdujących się po stronie serwera.
Wraz z wkroczeniem w świat Pythona czy Rubego w sieci zaroiło się od
"rails-serwerów" taki jak
Thin,
Ebb,
Mongrel. Frameworki Pythona takie jak Web2Py, Django, Pylons były wyposażone we własne wydajne serwery developerskie, które nie jednej osobie posłużyły również w środowisku produkcyjnym.
Próba wejścia w świat ApacheRównocześnie na arenie zaczęły pojawiać się inne rozwiązanie, te przypominające w swojej budowie mod_php:
mod_python,
mod_passenger. Swój debiut miał nawet
mod_ruby.
Również dedykowane serwery "zagościły" pod piórem Apache. Obsługiwane przez wynalazki rodziny modułów
mod_proxy zapytania, trafiały na silnie skalowalne, wydajne klastry serwerów dedykowananych, takich jak wcześniej wspomniany Thin, Ebb czy Mongrel. Pozwalało to obsługiwać w wydajny sposób zapytania, równocześnie nie zdejmując z głowy pióropusza wodzowi plemienia Apachów.
WSGIzachwytO WSGI po raz pierwszy przeczytałem gdy w ramach nauki języka angielskiego postanowiłem przeczytać całe
PEP-333. Posiadała wszelkie zalety:
- Technologia nie działała stricte jako moduł - tym samym zawieszenie się hostowanej z jej użyciem aplikacji nie powodowało zawieszenia serwera a jedynie samej aplikacji
- Kolejne zapytania były przesyłane do kolejnych procesów i obsługiwane w kolejnych wątkach podobnie jak FastCGI. Wykorzystywało więc zalety maszyn zarówno wieloprocesorowych jak i procesorów z kilkoma rdzeniami
- Pozwalało ad-hoc bez zewnętrznych wrapperów, jak suexec, uruchamiać aplikacje działające w imieniu konkretnego użytkownika i grupy. Wszystko out-of-the-box.
Specyfikacja mnie urzekła. Koniec z nieprzespanymi nocami spędzonymi nad pisaniem łatek do suexeca, z wiszącymi bez celu procesami FastCGI, koniec z koszmarami o sprytnych użytkownikach zawieszającymi serwer swoimi skryptami :]
WSGIrozczarowanieBajka o tytule "Pylons na WSGI hostowane pod Apache/
mod_wsgi w Linuksie" skończyła się w dniu, gdy miałem napisać prostą witrynę w IIS, bez użycia frameworka.
Na starcie okazało się, że standard w ogóle nie przewiduje hostowania plików statycznych. Trzeba się uciekać do sztuczek:
- przekierowywania ścieżek na poziomie serwera
- używania subdomen dla plików statycznych
- serwowania plików przez naszą aplikację
- unikania plików statycznych
Echa tych problemów można zauważyć w poradnikach konfiguracji serwerów dla frameworków czy kodzie aplikacji. Narzędzie, które tworzyłem miało być proste w użyciu, skalowalne i przenośne. Możliwe do wykorzystania w kilka chwil. Skoro tak - osobne konfigurowanie serwera odpadało, a rezygnacja z plików statycznych niestety nie wchodziła tutaj w grę.
Z czasem prosty skrypt zaczął rozrastać się do rangi frameworka. System szablonów Mako, paste i kod przekopiowany żywcem z Pylonsów pozwalający serwować pliki statyczne - czułem, że wymyślam koło na nowo a z prostego projektu zaczyna robić się kolosalne przedsięwzięcie. Projekt, którego znaczną część stanowi jakaś otoczka, kompletnie zaciemniająca najważniejsze - kod samego narzędzia.
Wszystko działo się w ramach
isapi-wsgi. Potencjał jaki posiada dawał podstawy do wstrzyknięcie odpowiedniej konfiguracji do witryny IIS automatycznie. Pojawiły się problemy.
Każdorazowa zmiana w działaniu skryptu wymuszała restart serwera. Na produkcyjnym, rozwiązaniem tego problemu, było resetowanie osobnej puli zasobów IIS'a, do której przydzielona została aplikacja z Pythonem. Jedyną metodą aby to wykonać było posiadanie praw administratora lub pisanie do takowego - gdy coś się zmieniło.
W międzyczasie okazało się, że isapi-wsgi posiadał, na szczęście banalny do naprawienia, błąd. Wskazywał on na to iż twórca skupia się na tworzeniu modułu dla IIS for clients natomiast nie testuje go w warunkach IIS for servers.
A żaba chińczyka co z tego wynikaCała przygoda skończyła się na przeprojektowaniu wszystkiego tak aby działało w trybie CGI. To kolejna historia, która skłania mnie do refleksji, że z jakiś przyczyn Windows jest środowiskiem, "zasadowym" - dla rozwiązań genialnie funkcjonujących w świecie Open Source. Pracując coraz więcej z produktami Microsoftu odczuwam stwierdzenia w stylu "Python jest multiplatformowym" jako postawienie równości z kompletnym pominięciem wygody użytkowania.
Zapewnia ją dopiero korzystanie z analogicznych implementacji wprowadzanych przez MS. Każde z nich świetnie wkomponowuje się w funkcjonujący ekosystem rozwiązań ze stajni Redmond. Mechanizmy i integracja stoją na oszałamiającym poziomie. Tworzone w ich ramach narzędzia uzyskują genialne efekty i możliwości. Tym samym dając wygodę użytkowania analogiczną dla systemów bazujących na rozwiązaniach opensourcowych.
Moim skromnym zdaniem zachwyt nad geniuszem produktów Microsoftu może osiągnąć zenit wyłącznie na poziomie rozwiązań jemu dedykowanych. Tak jak osiąga zenit zachwyt nad przygotowanym środowiskiem pracy Mac'a - Apple. Nikt, decydując się na Linuksa, nie dziwi iż programy spod Windows często nie działają. Nikt nie narzeka kupując Mac'a, że nie ma tam MS Office. Wszyscy nagminnie korzystają z aplikacji nie pisanych przez Microsoft narzekając na Windows.
P.S. Wpis jest dzieckiem zachwytu nad wygodą i wydajnością pracy w środowisku zbudowanym
wyłącznie z użyciem produktów Microsoft. Oszołomienia, w jak wielkim stopniu, tak jednolite technologicznie środowisko przekracza bariery, których osiągnięcie (sic!) byłoby niewyobrażalnie trudniejsze w świecie Open Source.
