Opcje serwera Ruby on Rails [zamknięte]

Słowo "rozmieszczenie" może mieć dwa znaczenia w zależności od kontekstu. Mylisz również role Apache/Nginx z rolami innych komponentów.

Uwaga historyczna: ten artykuł został pierwotnie napisany 6 listopada 2010, kiedy ekosystem aplikacji Ruby został ograniczony. Zaktualizowałem ten artykuł w marcu 15 2013 ze wszystkimi najnowszymi aktualizacjami w ekosystemie.

Disclaimer: jestem jednym z autorów Phusion Passenger, jednej z aplikacji serwery.

Apache vs Nginx

To oba serwery www. Mogą obsługiwać pliki statyczne, ale-z odpowiednimi modułami - mogą również obsługiwać dynamiczne aplikacje internetowe, np. te napisane w PHP. Apache jest bardziej popularny i ma więcej funkcji, Nginx jest mniejszy i szybszy i ma mniej funkcji.

Ani Apache, ani Nginx nie mogą obsługiwać aplikacji Ruby od razu po wyjęciu z pudełka, aby to zrobić, musisz użyć Apache/Nginx w połączeniu z jakimś dodatkiem, opisanym później.

Apache i Nginx mogą również działają jako odwrotne proxy, co oznacza, że mogą przyjmować przychodzące żądanie HTTP i przekazywać je do innego serwera, który również mówi HTTP. Gdy serwer odpowie odpowiedzią HTTP, Apache / Nginx przekaże odpowiedź z powrotem do klienta; dowiesz się później, dlaczego jest to istotne.

Kundel i inne serwery aplikacji produkcyjnych vs WEBrick

Mongrel to Ruby "serwer aplikacji": w konkretnych kategoriach oznacza to, że Mongrel jest aplikacją, która:

1. ładuje Twoje Aplikacja Ruby wewnątrz własnej przestrzeni procesowej.
2. Ustawia Gniazdo TCP, pozwalając mu komunikować się ze światem zewnętrznym (np. Internetem). Kundel nasłuchuje żądań HTTP na tym gnieździe i przekazuje dane żądania do aplikacji internetowej Ruby.
3. Aplikacja Ruby zwraca obiekt, który opisuje, jak powinna wyglądać odpowiedź HTTP, a Kundel zajmuje się konwersją jej na rzeczywistą odpowiedź HTTP (rzeczywiste bajty) i wysyła ją z powrotem przez Gniazdo.

Jednak Kundel jest dość przestarzały, obecnie nie jest już utrzymywany. Nowsze alternatywne serwery aplikacji to:

• Pasażer Phusion
• Jednorożec
• cienki
• Puma
• Trinidad (tylko JRuby)
• TorqueBox (tylko JRuby)

Omówię je później i opiszę, jak różnią się od siebie i od Kundla.

WEBrick robi to samo co Kundel, ale różnice są:

[21]}WEBrick nie nadaje się do produkcji, w przeciwieństwie do wszystkiego, o czym wspomniałem wcześniej. WEBrick jest napisany w całości w Ruby. Mongrel (i większość innych serwerów aplikacji Ruby) jest częścią Ruby i częścią C (głównie Ruby), ale jego parser HTTP jest napisany w języku C dla wydajności. WEBrick jest wolniejszy i mniej wytrzymały. Ma pewne znane wycieki pamięci i pewne znane problemy z parsowaniem HTTP.
• WEBrick jest zwykle używany tylko jako domyślny serwer podczas rozwoju, ponieważ WEBrick jest domyślnie dołączony do Ruby. Kundel i inne serwery aplikacji muszą być zainstalowane osobno. Nie zaleca się używania WEBrick w środowiskach produkcyjnych, choć z jakiegoś powodu Heroku wybrał WEBrick jako domyślny serwer. Używali Thin wcześniej, więc nie mam pojęcia, dlaczego przełączyli się na WEBrick.

Serwer aplikacji i świat

Wszystkie obecne Serwery aplikacji Ruby mówią HTTP, jednak niektóre serwery aplikacji mogą być bezpośrednio narażone na dostęp do Internetu na porcie 80, podczas gdy inne mogą nie.

[21]} serwery aplikacji, które mogą być bezpośrednio wystawione na działanie Internetu: Phusion Passenger, Rainbows [22]}
• serwery aplikacji, które mogą nie być bezpośrednio narażone na działanie Internetu: Kundel, Jednorożec, cienki, Puma. Te serwery aplikacji muszą być umieszczone za serwer WWW odwrotnego proxy jak Apache i Nginx.
• Nie wiem wystarczająco dużo o Trinidadzie i TorqueBox, więc pominąłem je.

Dlaczego niektóre serwery aplikacji muszą być umieszczone za odwrotnym proxy?

• niektóre serwery aplikacji mogą obsługiwać tylko 1 żądanie jednocześnie, na proces. Jeśli chcesz obsługiwać 2 żądania jednocześnie, musisz uruchomić wiele instancji app server, z których każda obsługuje tę samą aplikację Ruby. Ten zestaw procesów serwera aplikacji nazywa się app server cluster (stąd nazwa Kundel Cluster, Thin Cluster, etc). Następnie musisz skonfigurować Apache lub Nginx, aby odwrócić proxy do tego klastra. Apache / Nginx zajmie się dystrybucją żądań między instancjami w klastrze (więcej na ten temat w sekcja"modele współbieżności We/Wy").
Serwer WWW może buforować żądania i odpowiedzi, chroniąc serwer aplikacji przed "powolnymi klientami" - klientami HTTP, które nie wysyłają ani nie akceptują danych bardzo szybko. Nie chcesz, aby twój serwer aplikacji nic nie robił, czekając, aż klient wyśle pełne żądanie lub otrzyma pełną odpowiedź, ponieważ w tym czasie serwer aplikacji może nie być w stanie zrobić nic innego. Apache i Nginx są bardzo dobrzy w robieniu wielu rzeczy w tym samym czasie, ponieważ są albo wielowątkowy, albo eventowy.
• większość serwerów aplikacji może obsługiwać pliki statyczne, ale nie są w tym szczególnie dobre. Apache i Nginx potrafią to zrobić szybciej.
• ludzie zazwyczaj konfigurują Apache / Nginx do bezpośredniego serwowania plików statycznych, ale przesyłają żądania, które nie odpowiadają plikom statycznym do serwera aplikacji, jest to dobra praktyka bezpieczeństwa. Apache i Nginx są bardzo dojrzałe i mogą chronić serwer aplikacji przed (być może złośliwie) uszkodzonymi żądaniami.

Dlaczego jakaś aplikacja serwery są bezpośrednio narażone na działanie Internetu?

Phusion Passenger to zupełnie inna bestia niż wszystkie inne serwery aplikacji. Jedną z jego unikalnych cech jest to, że integruje się z serwerem WWW.
• Autor tęczy publicznie stwierdził, że można go bezpośrednio ujawnić w Internecie. Autor jest dość pewien, że w parserze HTTP (i podobnych) nie ma luk w zabezpieczeniach. Mimo to autor nie udziela żadnej gwarancji i twierdzi, że użytkowanie jest we własnym zakresie ryzyko.

Porównanie serwerów aplikacji

W tym dziale porównam większość serwerów aplikacji, o których wspomniałem, ale nie Phusion. Phusion Passenger to tak inna bestia od reszty, że dałem jej dedykowaną sekcję. Pominąłem również Trinidad i TorqueBox, ponieważ nie znam ich wystarczająco dobrze, ale i tak są istotne tylko jeśli używasz JRuby.

• Kundel był całkiem nagi. Jak wspomniano wcześniej, Kundel jest czysto jednowątkowy wielowątkowy, więc jest przydatny tylko w klastrze. Nie ma monitorowania procesu: jeśli proces w klastrze ulegnie awarii (np. z powodu błędu w aplikacji), należy go ręcznie uruchomić ponownie. Ludzie mają tendencję do korzystania z zewnętrznych narzędzi monitorowania procesów, takich jak Monit i Bóg.
• Jednorożec to widelec Kundla. Obsługuje ograniczone monitorowanie procesu: jeśli proces ulegnie awarii, jest automatycznie uruchamiany ponownie przez proces główny. Może sprawić, że wszystkie procesy słuchają na jednym wspólne gniazdo, zamiast osobnego gniazda dla każdego procesu. Upraszcza to konfigurację odwrotnego serwera proxy. Podobnie jak Kundel, jest to czysto jednowątkowy proces wielowątkowy.
• Thin wykorzystuje evented model We/Wy wykorzystując bibliotekę EventMachine. Poza używaniem parsera HTTP Kundel, nie jest on w żaden sposób oparty na kundlu. Jego tryb klastra nie ma monitorowania procesu, więc musisz monitorować awarie itp. Nie ma wspólnego gniazda podobnego do jednorożca, więc każdy proces słucha samodzielnie Gniazdo. Teoretycznie Model I/O Thin pozwala na wysoką współbieżność, ale w większości praktycznych sytuacji, do których jest używany Thin, jeden proces Thin może obsłużyć tylko 1 równoległe żądanie, więc nadal potrzebujesz klastra. Więcej o tej specyficznej właściwości w sekcji "modele współbieżności We/Wy".
• W przeciwieństwie do Unicorn, Puma jest przeznaczona wyłącznie do wielowątkowych. W związku z tym obecnie nie ma wbudowanego wsparcia klastra. Należy zachować szczególną ostrożność, aby upewnić się, że możesz używać wielu rdzeni (więcej o tym w sekcji "modele współbieżności We/Wy").
• Rainbows obsługuje wiele modeli współbieżności za pomocą różnych bibliotek.

Pasażer Phusion

Phusion Passenger działa zupełnie inaczej niż wszystkie pozostałe. Phusion Passenger integruje się bezpośrednio z Apache lub Nginx, a więc może być porównywany do mod_php dla Apache. Podobnie jak mod_php pozwala Apache na serwowanie aplikacji PHP, niemal magicznie, Phusion Passenger pozwala Apache (a także Nginx!) do obsługi aplikacji Ruby, niemal magicznie. Celem Phusion Passenger jest sprawienie, aby wszystko działało (tm) przy jak najmniejszym kłopocie.

1. edytujesz plik konfiguracyjny serwera WWW i określasz lokalizację swojej aplikacji Ruby katalog "publiczny".
2. nie ma kroku 2.

Cała konfiguracja odbywa się w pliku konfiguracyjnym serwera www. Pasażer Phusion automatyzuje prawie wszystko. Nie ma potrzeby uruchamiania klastra i zarządzania procesami. Uruchamianie / zatrzymywanie procesów, ponowne uruchamianie ich po awarii itp. - wszystko zautomatyzowane. W porównaniu do innych serwerów aplikacji, Phusion ma znacznie mniej ruchomych części. Ta łatwość obsługi jest jednym z głównych powodów, dla których ludzie używają Phusion Passenger.

Także w przeciwieństwie do innych serwerów aplikacji, Phusion jest napisany głównie w C++, dzięki czemu jest bardzo szybki.

Z powyższych powodów Phusion jest obecnie najpopularniejszym serwerem aplikacji Ruby, obsługującym ponad 150 000 stron internetowych, w tym Duże takie jak New York Times, Pixar, Airbnb, itd.

Phusion Passenger vs Inne Serwery aplikacji

Phusion oferuje o wiele więcej funkcji i zapewnia wiele zalet w stosunku do innych serwerów aplikacji, takich jak:

• dynamiczne dostosowywanie liczby procesów w oparciu o ruch. Uruchamiamy mnóstwo aplikacji Rails na naszym ograniczonym zasobem serwerze, które nie są publiczne i które ludzie w naszej organizacji używają najwyżej kilka razy dziennie. Takie rzeczy jak Gitlab, Redmine itp. Phusion Passenger can spin down these procesy, gdy nie są używane, i spinanie ich, gdy są używane, umożliwiając dostęp do większej ilości zasobów dla ważniejszych aplikacji. W przypadku innych serwerów aplikacji wszystkie procesy są włączone przez cały czas.
• niektóre serwery aplikacji z założenia nie są dobre w pewnych obciążeniach. Na przykład Unicorn jest przeznaczony tylko do szybkich żądań: Patrz strona Unicorn sekcja "w niektórych przypadkach tylko gorzej".

Obciążenia, w których Jednorożec nie jest dobry są:

• streamowanie obciążeń (np. rails 4 live streaming lub rails 4 template streaming).
• obciążenia, w których aplikacja wykonuje wywołania HTTP API.

• Inne Serwery aplikacji wymagają od użytkownika uruchomienia co najmniej jednej instancji na aplikację. Natomiast Phusion Passenger obsługuje wiele aplikacji w jednym przykład. To znacznie zmniejsza koszty administracyjne.
• automatyczne przełączanie użytkowników, wygodna funkcja bezpieczeństwa.
Phusion obsługuje wiele MRI Ruby, JRuby i Rubinius. Kundel, Jednorożec i cienki wspierają tylko MRI. Puma obsługuje również wszystkie 3.
• Phusion Passenger obsługuje więcej niż tylko Ruby! Obsługuje również Python WSGI, dzięki czemu może na przykład uruchamiać aplikacje Django i Flask. W rzeczywistości Phusion zmierza w kierunku stania się serwer poliglota. Węzeł.obsługa js na liście todo.
• Out-of-band garbage collection. Phusion Passenger może uruchomić Ruby garbage collector poza normalnym cyklem żądania / odpowiedzi, potencjalnie skracając czasy żądań o setki milisekund. Unicorn też ma podobną funkcję, ale Wersja Phusion jest bardziej elastyczna, ponieważ 1) nie jest ograniczony do GC i może być używany do arbitralnej pracy. 2) Wersja pasażera Phusion działa dobrze z aplikacjami wielowątkowymi, podczas gdy Jednorożec nie.
• Automatyczne wznawianie toczenia. Rolling restarts na Unicorn i innych serwerach wymaga trochę pracy skryptowej. Phusion Passenger Enterprise całkowicie automatyzuje ten sposób.

Jest więcej funkcji i zalet, ale lista jest naprawdę długa. Należy zapoznać się z obszerną instrukcją obsługi Phusion (wersja Apache, nginx wersja) lub Strona pasażera Phusion w celu uzyskania informacji.

Współbieżność We/Wy modele

• jednowątkowy wielowątkowy.{[6] } jest to tradycyjnie najpopularniejszy model I / O dla serwerów aplikacji Ruby, częściowo dlatego, że obsługa wielowątkowości w ekosystemie Ruby była bardzo zła. Każdy proces może obsłużyć dokładnie 1 żądanie na raz. Obciążenie serwera www balansuje między procesami. Model ten jest bardzo solidny i nie ma szans, aby programista wprowadził błędy współbieżności. Jednak jego współbieżność We/Wy jest bardzo ograniczona (ograniczona liczbą procesy). Ten model jest bardzo odpowiedni do szybkich, krótkotrwałych obciążeń. Jest to bardzo nieodpowiednie dla powolnych i długotrwałych obciążeń blokujących We/Wy, np. obciążeń związanych z wywołaniem interfejsów API HTTP.
• czysto wielowątkowy. obecnie ekosystem Ruby ma doskonałą obsługę wielowątkowości, więc ten model wejścia / Wyjścia stał się bardzo opłacalny. Wielowątkowość umożliwia wysoką współbieżność We / Wy, dzięki czemu nadaje się zarówno do krótkotrwałych, jak i długotrwałych obciążeń blokujących We/Wy. Programista jest bardziej prawdopodobnie wprowadzi błędy współbieżności, ale na szczęście większość frameworków internetowych jest zaprojektowana w taki sposób, że nadal jest to bardzo mało prawdopodobne. Należy jednak zauważyć, że interpreter MRI Ruby nie może wykorzystywać wielu rdzeni procesora, nawet jeśli istnieje wiele wątków, ze względu na użycie Global Interpreter Lock (Gil). Można to obejść, korzystając z wielu procesów wielowątkowych, ponieważ każdy proces może wykorzystać rdzeń PROCESORA. JRuby i Rubinius nie mają Gila, więc mogą w pełni wykorzystać wiele rdzenie w jednym procesie.
• Hybrydowy wielowątkowy wielowątkowy. zaimplementowany głównie przez Phusion Passenger Enterprise 4 i Później. Możesz łatwo przełączać się między jednowątkowymi procesami wielowątkowymi, czysto wielowątkowymi, a może nawet wieloma procesami, z których każdy ma wiele wątków. Ten model daje to, co najlepsze z obu światów.
• / Align = "left" / Ten model jest zupełnie inny od wspomnianego wcześniej modelu. Pozwala na bardzo wysoką współbieżność We/Wy i dlatego jest doskonałe do długotrwałego blokowania obciążeń we/wy. Aby go wykorzystać, wymagane jest wyraźne wsparcie ze strony aplikacji i frameworka. Jednak wszystkie główne frameworki, takie jak Rails i Sinatra, nie obsługują kodu typu evented. Dlatego w praktyce cienki proces nadal nie może obsłużyć więcej niż jednego żądania na raz, dzięki czemu zachowuje się tak samo jak jednowątkowy model wieloprocesowy. Istnieją wyspecjalizowane frameworki, które mogą korzystać z evented I / O, takie jak Skurcz.

Niedawno na blogu Phusion został opublikowany artykuł o optymalnym dostrojeniu liczby procesów i wątków pod względem obciążenia pracą. Zobacz Tuning Phusion ' s concurrency settings .

Capistrano

Capistrano to coś zupełnie innego. We wszystkich poprzednich sekcjach "wdrożenie" odnosi się do uruchomienia aplikacji Ruby na serwerze aplikacji, tak aby stała się dostępna dla odwiedzających, ale zanim to nastąpi, zazwyczaj trzeba wykonać jakieś prace przygotowawcze, takie jak:

• wgrywanie kodu i plików aplikacji Ruby na serwer.
• instalowanie bibliotek, od których zależy Twoja aplikacja.
• Konfigurowanie lub migracja bazy danych.
• uruchamianie i zatrzymywanie demonów, na których może polegać Twoja aplikacja, takich jak pracownicy Sidekiq/Resque czy cokolwiek innego.
• wszelkie inne rzeczy, które należy zrobić podczas konfigurowania aplikacji.

W kontekście Capistrano, "wdrożenie" odnosi się do wykonywania wszystkich tych prac przygotowawczych. Capistrano nie jest serwerem aplikacji. Zamiast tego jest to narzędzie do automatyzacji wszystkich prac przygotowawczych. Informujesz Capistrano, gdzie znajduje się twój serwer i które polecenia muszą być uruchamiane za każdym razem, gdy wdrażasz nową wersję aplikacji, a Capistrano zajmie się przesłaniem aplikacji Rails na serwer i uruchomieniem określonych poleceń.

Capistrano jest zawsze używany w połączeniu z serwerem aplikacji. Nie zastąp serwery aplikacji. Odwrotnie, serwery aplikacji nie zastępują Capistrano, mogą być używane w połączeniu z Capistrano.

Oczywiście, że nie musisz } używać Capistrano. Jeśli wolisz przesłać swoją aplikację Ruby za pomocą FTP i ręcznie uruchamiać za każdym razem te same kroki poleceń, możesz to zrobić. Inni ludzie się tym zmęczyli, więc zautomatyzowali te kroki w Capistrano.