Najlepsza strategia wdrażania dla aplikacji PlayFramework?

Question

To pytanie jest zorientowane na serwer. Mam hostowany serwer (raczej niewielki, 1,6Ghz atomu, 2Go, 200 GO) z kilkoma (4 lub 5) aplikacjami do odtwarzania i kolejnymi. Większość z tych aplikacji ma naprawdę niewielkie zastosowanie, powiedzmy sto żądań dziennie.

1. Czy lepiej wdrożyć każdą z tych aplikacji przy użyciu wbudowanego serwera gry Play! i w ten sposób użyć 64 MB pamięci dla każdej aplikacji?

2. Lub wdrożyć Tomcat ze wszystkimi aplikacjami wewnątrz tomcat? Z większą pamięcią współdzieloną przez wszystkie aplikacje?

EDIT:

dodam trochę dalsze informacje o mojej sytuacji. Serwer znajduje się również:

• O 10,15 PHP stron internetowych na Apache2
• Serwer SVN przeżywa Apache mod_dav_svn
• kocur wykorzystywane do Sonar
• Samodzielny montaż z Jenkins (przez Jetty)

Mój pierwotny plan polegał na rozmieszczeniu wszystkich tych rzeczy w Tomcat. Posiadając aplikacje, Sonar & Jenkins działający na Tomcat i Apache2 dla statycznych zasobów res. (obrazy, skrypty)

KOMENTARZ

Ostatni punkt, jestem świadomy, że posiadanie Sonar & Jenkins, ciągłe systemy integracyjne w środowisku produkcyjnym nie jest to optymalne. Ale ponieważ działają one tylko w nocy (automatyczne kompilacje), nie przeciążają systemu. Plus Jestem studentem, finansowo dodatkowy "CI/build" serwer jest poza moimi możliwościami finansowymi.

Answer 1

Najlepszym sposobem jest użycie dołączonego serwera Play, wprowadzenie NGinx jako odwrotne proxy przed nim, aby zająć się zarządzaniem wszystkimi przekierowaniami/żądaniami.

Dlaczego to, a nie Tomcat? Możesz zacząć od this article, która porównuje skuteczność. Dodatkowym argumentem jest to, że Tomcat ładuje całe środowisko Java EE, którego Play nie wymaga ani nie wykorzystuje, zużywając pamięć i zasoby, które chcesz bezpłatnie dla swoich aplikacji (szczególnie jeśli korzystasz z buforowania w pamięci).

Na Nginxie jako odwrotnym proxy, this powinien dać wskazówkę, dlaczego należy go używać zamiast Apache.

EDIT (Edytuj pytanie za):

W sytuacji, można zoptymalizować swoje zasoby.

Najpierw zastąp Apache 2 przez Nginx. Nginx może obsługiwać PHP, całkiem dobrze (jeśli używasz Ubuntu, zobacz this). Będzie służył Play bardzo wydajnie i może być używany jako serwer proxy dla serwerów Java.

Następnie możesz przenieść wszystkie aplikacje Java na Jetty i pozbyć się Tomcat. Molo zużywa średnio mniej zasobów, a nawet jeśli twoje aplikacje działają tylko w nocy, serwer nadal działa i gromadzi pamięć RAM. Im mniej, tym lepiej.

Co z SVN? Niestety, będziesz potrzebował Apache 2 i Nginx jako odwrotnego proxy do Apache 2. Dlaczego nie zachować Apache? Argumentem byłoby użycie. Teoretycznie aplikacje PHP będą miały większy ruch niż serwer SVN, co sprawia, że ​​bardziej istotne jest zużycie zasobów, jakie mają. Dzięki nginx, RAM i cpu przydzielone do obsługi PHP będą mniej sprawiały, że Twoja maszyna będzie bardziej responsywna. Apache zadziała tylko wtedy, gdy użyjesz SVN, co nie będzie tak często.

Jeśli nie chcesz wkładać wysiłku w przenoszenie rzeczy na Nginx (co rozumiem), po prostu przenieś aplikacje Java na Jetty i użyj Apache 2 jako odwrotnego proxy dla Play. Ale użyj wbudowanego serwera Play, nie ładuj aplikacji w Tomcat. W ten sposób będzie bardziej wydajny.

Answer 2

Zacznę dla każdej aplikacji serwer odtwarzania. Łatwiej w konfiguracji i łatwiej mieć oddzielne pliki dziennika. Co więcej, możesz ponownie uruchomić każdą aplikację osobno, bez problemów. Redeploy na tomcat to często praca, której wynikiem są błędy.

Wada: Musisz skonfigurować odwrotnego proxy jak lighttp dostać ładne adresy URL jak mydomain.org/app1 i mydomain.org/app2

Answer 3

wdrożeń produkcyjnych biegnę używasz Juz wbudowanego serwera. To sprawia, że ​​sposobem na życie prostsze niż Tomcat, zwłaszcza przesunięcie - uruchomić serwery pod ekranie, a upgrade składa się z „Ctrl-C”, „strzałka w górę”, „Enter”, wykonanie:

% git stash; git pull; git stash apply; play run 

Z 2G pamięci, nie martwiłbym się zbytnio o obciążenie związane z procesem. Jest to z pewnością cena, którą warto zapłacić, aby pozbyć się zawiłości Tomcat.

(the stashing git pozwala mi mieć jakieś non-git-popełnione configs leżące wokół na produkcji - więcej niż lenistwo potrzebie, choć :-))