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

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

18 голосов
/ 30 июня 2011

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

COMMENT

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

Ответы [ 3 ]

13 голосов
/ 30 июня 2011

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

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

На Nginx в качестве обратного прокси-сервера это должно дать подсказку о том, почему его следует использовать вместо Apache.

РЕДАКТИРОВАТЬ (при редактировании вопроса):

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

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

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

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

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

6 голосов
/ 30 июня 2011

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

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

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

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

2 голосов
/ 30 июня 2011

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

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

.
...