Zamierzam użyć jednego VPS do wdrożenia wielu aplikacji CherryPy o niskim natężeniu ruchu jako podkatalogów; np example.com/app1, example.com/app2itp

Po zbadaniu wdrożenia WSGI wygląda na to, że preferowaną metodą wdrażania aplikacji jest użycie serwera WSGI (Gunicorn, uWSGI itp.) I NGinx w konfiguracji odwrotnego proxy. Korzystanie z dwóch serwerów sieciowych w tandemie wydaje się przesadą - zwłaszcza, że ​​moja aplikacja CherryPy sama jest serwerem sieciowym - ale nie chcę odrzucać tego pomysłu, ponieważ pojawia się wszędzie . Z pewnością nie jestem ekspertem, więc chciałbym o tym porozmawiać.

Widzę trzy opcje:

• Wdróż CherryPy samodzielnie.
• Wdróż pod Gunicorn lub innym serwerem WSGI.
• Wdróż pod serwerem WSGI i odwrotnym proxy do NGinx, który wydaje się być rozwiązaniem dla wszystkich.

Moje pytania:

• Jaki jest główny powód, dla którego wszędzie widzę ten wzór? Nginx jest tylko , że dobry?
• Czy w przypadku aplikacji o niskim natężeniu ruchu natywny serwer CherryPy jest wystarczająco dobry, czy powinienem nawet nie próbować?

Wszelkie porady są mile widziane, dziękuję.

Powodem, dla którego wszyscy umieszczają nginx (lub inny serwer, taki jak Apache) przed swoimi serwerami aplikacji jest to, że każdy ma statyczną zawartość, taką jak obrazy, CSS i JavaScript, oraz dziwne wymagania, które są unikalne dla ich aplikacji.

Serwer aplikacji (CherryPy, gunicorn, cokolwiek) jest zoptymalizowany pod kątem uruchamiania aplikacji i udostępniania jej danych wyjściowych. Chociaż serwer aplikacji może również obsługiwać zawartość statyczną, prawie nigdy nie jest dobrze zoptymalizowany do tego zadania, ponieważ ma to drugorzędne znaczenie w stosunku do głównego celu serwera aplikacji. (Niektóre serwery aplikacji również pomogą, minimalizując i kompresując CSS i JS, dzięki czemu serwer WWW z przodu może obsługiwać te zasoby jeszcze szybciej.)

Ponadto rzeczywisty serwer internetowy może znacznie więcej niż serwować treści o wysokiej wydajności. Rzeczy takie jak buforowanie, manipulowanie nagłówkami, przepisywanie adresów URL, geolokalizacja i wiele innych funkcji, które po prostu spowodowałyby, że serwer aplikacji byłby bezużyteczny.

Zazwyczaj serwer aplikacji uruchamia się sam tylko podczas tworzenia aplikacji, gdy jesteś jedynym użytkownikiem, a wydajność nie stanowi problemu. Nawet jeśli Twoja witryna ma mały ruch, chciałbyś, aby była szybsza, prawda? Powolne witryny o niskim natężeniu ruchu zwykle nie stają się witrynami o dużym natężeniu ruchu ...

Dlaczego ludzie stawiają Nginx na pierwszym planie?

1. Nginx jest asynchronicznym serwerem WWW. Oznacza to, że nie poświęca wątku ani procesu na połączenie. Zamiast tego korzysta z preferowanej przez system operacyjny biblioteki odpytywania gniazd, dzięki czemu jest w stanie obsłużyć setki tysięcy połączeń. Dlaczego jako programista aplikacji powinieneś się tym przejmować? Ponieważ Nginx buforuje połączenia i przekazuje żądanie do instancji nadrzędnej CherryPy tylko wtedy, gdy żądanie jest w pełni odczytane. To samo dotyczy odpowiedzi. W ten sposób twoja aplikacja CherryPy, która jest serwerem wątkowym, pod wieloma względami za Nginx, staje się asynchroniczna. W szczególności machasz ręką do problemu wolnego klienta i powolnych ataków DOS na Lorisa.
2. Nginx ma ograniczanie szybkości połączenia po wyjęciu z pudełka. Powiedz, że nie chcę więcej niż 8 jednoczesnych połączeń z tego samego adresu IP.
3. CherryPy ma problem z SSL . Nginx nie.
4. Python może wysyłać bajty tam iz powrotem prawie tak dobrze, jak C. Python's zlibjest tylko opakowaniem wokół biblioteki C. Ponieważ jednak Nginx skutecznie obsługuje połączenia, dobrym pomysłem jest odciążenie wątków roboczych CherryPy od udostępniania treści statycznych w produkcji i poświęcanie się tylko zawartościom dynamicznym.
5. Multipleksowanie kilku instancji CherryPy na tym samym porcie, domenie, ścieżce itp. Zasadniczo dodatkowa elastyczność innego poziomu konfiguracji.

Czy samo korzystanie z CherryPy jest bezpieczne?

Według jednej z oryginalnych autorów, tak . Większość istotnych dla sieci rzeczy, które możesz zrobić samodzielnie dzięki CherryPy.

CherryPy ma pojęcie o aplikacji i możesz obsługiwać kilka aplikacji za pomocą jednej instancji CherryPy. CherryPy może również obsługiwać inne aplikacje WSGI .

Wdrażanie CherryPy

W tradycyjnym wdrożeniu w stylu * nix piszesz skrypt inicjujący, demontujesz przetwarzany, upuszczasz jego uprawnienia, piszesz PID itp. Nie jest to wielka sprawa, jeśli masz kilka instancji CherryPy. Gdy masz ich kilkadziesiąt, staje się to żmudne i sensowne jest przekazanie zarządzania procesami do Gunicorn lub uWGSI i przełączenie instancji CherryPy z HTTP na WSGI.

Napisałem szkielet samouczka / projektu, cherrypy-webapp-szkielet , którego celem było wypełnienie luk we wdrażaniu (tradycyjnej) rzeczywistej aplikacji CherryPy na Debianie dla programisty.

Zakończyć

1. Mały ruch, brak specjalnych wymagań → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Duży ruch, specjalne wymagania → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Dziesiątki osobnych instancji CherryPy na tym samym serwerze, żądnych przesady wszystkich rozwiązań → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.