Лучшая стратегия развертывания приложений PlayFramework?

Этот вопрос ориентирован на сервер. У меня есть хостинг-сервер (довольно маленький, 1,6 ГГц, 2Go, 200 GO) с несколькими (4 или 5) игровыми приложениями и более подходящими. Большинство из этих приложений имеют реальное малое использование, скажем, сто запросов в день каждый.

  • Лучше ли развертывать каждое из этих приложений с помощью встроенного сервера Play! и, следовательно, использовать 64 МБ памяти для каждого приложения?

  • Или разверните Tomcat со всеми приложениями внутри tomcat? С большой памятью, доступной всем приложениям?

EDIT:

Я добавлю немного дополнительную информацию о моей ситуации. На сервере также находятся:

  • Около 10,15 PHP веб-сайтов на Apache2
  • Сервер SVN, проходящий через Apache mod_dav_svn
  • Tomcat, используемый для Sonar
  • Автономная установка Jenkins (через Jetty)

Мой первоначальный план состоял в том, чтобы развернуть все эти вещи в Tomcat. Наличие приложений, Sonar и Jenkins, работающих на Tomcat и Apache2 для статических ресурсов. (Изображения, скрипты)

К.П

В последнем случае я знаю, что наличие Sonar и Jenkins, систем непрерывной интеграции в производственной среде не является оптимальным. Но поскольку они работают только ночью (автоматические сборки), они не перегружают систему. Кроме того, я студент, в финансовом отношении дополнительный сервер "CI/build" не входит в мои финансовые возможности.

Ответы

Ответ 1

Наилучший подход - использовать включенный сервер Play, помещая NGinx в качестве обратного прокси перед ним, чтобы справиться со всем управлением перенаправлением/запросом.

Почему это, а не Tomcat? Вы можете начать с этой статьи, которая сравнивает производительность. Дополнительным аргументом будет то, что Tomcat загружает всю среду Java EE, которую Play не требует и не использует, потребляя память и ресурсы, которые вы хотите бесплатно для своих приложений (особенно, если вы используете кэширование в памяти).

В Nginx как обратный прокси, this должен дать подсказку, почему использовать его вместо Apache.

ИЗМЕНИТЬ (по вопросу редактирования):

В вашей ситуации вы можете оптимизировать свои ресурсы.

Сначала замените Apache 2 на Nginx. Nginx может служить PHP, достаточно хорошо (если вы используете Ubuntu, см. this). Он будет работать с Play очень эффективно и может использоваться как прокси-сервер для серверов Java.

Затем вы можете перенести все свои Java-приложения на Jetty и избавиться от Tomcat. Jetty потребляет меньше ресурсов в среднем, и даже если ваши приложения будут работать только ночью, сервер все еще работает в сети и накапливает RAM. Чем меньше он, тем лучше.

Как насчет SVN? К сожалению, вам понадобится Apache 2 и Nginx в качестве обратного прокси-сервера для Apache 2. Почему бы не сохранить Apache? Аргументом будет использование. Теоретически приложения PHP будут иметь больше трафика, чем сервер SVN, что делает более актуальным потребление ресурсов у них. С nginx, ram и cpu, выделенные для обслуживания PHP, будут меньше делать вашу машину более отзывчивой. Apache будет действовать только при использовании SVN, который будет не так часто.

Если вы не хотите прикладывать усилия к перемещению материала в Nginx (что я могу понять), просто переместите приложения Java в Jetty и используйте Apache 2 в качестве обратного прокси для Play. Но используйте Play embedded server, не загружайте приложение в Tomcat. Это будет более эффективно.

Ответ 2

Производственные развертывания, которые я запускаю, используют встроенный сервер Play. Это делает жизнь проще, чем Tomcat, особенно передислоцировать - я запускаю серверы под экраном, а обновление состоит из "Ctrl-C", "Up-Arrow", "Enter", выполнение:

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

С 2G памяти я не стал бы слишком беспокоиться о накладных расходах. Это, безусловно, цена, которая стоит заплатить, чтобы избавиться от сложностей Tomcat.

(git stashing позволяет мне иметь не-w21 > -конфигурированные конфиги, лежащие вокруг на производстве, - больше лень, чем необходимость, -:))

Ответ 3

Я бы начал для каждого приложения игровым сервером. Это проще в конфигурации и проще иметь отдельные лог файлы. Кроме того, вы можете перезапустить каждое приложение отдельно без проблем. Повторное развертывание на tomcat часто представляет собой работу с результатами ошибок.

Недостаток: вы должны настроить обратный прокси, например lighttp, для получения хороших URL-адресов, таких как mydomain.org/app1 и mydomain.org/app2