Назад | Перейти на главную страницу

Apache + Tomcat против автономного Tomcat или GlassFish

Я настраиваю сервер Debian для обслуживания веб-приложений Java. Я провел довольно много исследований в течение нескольких недель. На веб-сайте Tomcat говорится, что для повышения скорости лучше использовать автономный Tomcat, если вы не выполняете кластеризацию. Однако я видел, как многие люди предполагают, что использование Apache + Tomcat обеспечивает лучшую безопасность и защиту от атак.

Предположим, что процесс будет запущен на 80-м порту от имени непривилегированного пользователя. Я предполагаю, что если вы используете брандмауэр перед сервером, Tomcat должен быть в порядке. Однако, если вы просто хотите запустить открытый веб-сервер с помощью брандмауэра Linux, какой вариант лучше?

Или, может быть, кто-то может порекомендовать другой веб-сервер с открытым исходным кодом. Я стараюсь сделать решение как можно более легким, поскольку эти веб-приложения будут работать в контейнерах.

Все мнения приветствуются и ценятся.

По моему собственному опыту, разумно держать что-то перед Tomcat, чтобы немного защитить это от внешнего мира. Если вы запустите tomcat с собственным расширением Tomcat, ввод-вывод будет очень быстрым, и Tomcat будет вести себя очень хорошо.

Также Tomcat может работать на порте 80 без использования root, используя jsvc, который, если он не входит в комплект поставки вашего дистрибутива, очень прост в сборке и использовании.

Однако сохранение простого веб-интерфейса на всякий случай также полезно: поскольку этот интерфейс может дать вам небольшую гибкость, которой вы никогда не получите с Tomcat (gzip на лету, правила перезаписи, обрабатывать более одного tomcat на одном IP: Порт с использованием простого сопоставления виртуального хоста и прокси, ...)

Apache2 может быть этим интерфейсом, используя mod_proxy + AJP. AJP обрабатывает заголовки и переадресацию исходного IP-адреса в Tomcat, и вы никогда не будете намного счастливее, если вам придется добавить RewriteRules в свой домен, потому что Apache предоставляет это очень простым способом.

Однако AJP очень медленно выбирает изменение статуса веб-приложения, и необходимость ждать 30 секунд, когда ваше веб-приложение перезапускается, чтобы снова увидеть его доступным в Интернете, ОЧЕНЬ разочаровывает. В последней комбинации AJP + Tomcat также есть некоторые не очень приятные проблемы, приводящие к пустым страницам и неработающему типу контента (хотя это можно исправить, но отказавшись от улучшений, встроенных в tomcat ...).

Простой HTTP Mod_proxy также можно использовать, но не будучи настоящим прокси (Apache меняет заголовок Host :, исходный IP становится прокси-адресом, ...) мне не очень нравится.

Другие хорошие альтернативы включают:

  • HAProxy: Очень умный и простой прокси, очень хорошо справляется с нагрузкой, довольно прост в настройке, надежен и настоящий HTTP-прокси, может пересылать исходный IP-адрес через обычный заголовок X-Forwarded-For. Я использую это в производстве и очень этому рад. Он может масштабироваться до тысяч живых подключений, ограничивая количество активных подключений к вашему бэкэнду, и имеет множество встроенных полезных функций. Однако, вероятно, не стоит делать что-то более умное, чем маршрутизация HTTP (например, RewriteRules).

  • Nginx: Я слышал, что этот сервер действительно поддерживает AJP. Будучи легче, чем Apache, и более полнофункциональным, чем HAProxy, я, вероятно, попробую это сегодня, если бы у меня была возможность.

Вывод

  • Если у вас есть время на тестирование, попробуйте Nginx,
  • Если вы предпочитаете простой и надежный интерфейс, выберите HAProxy,
  • Если вы предпочитаете "традиционный" маршрут, выберите Apache2 + AJP,
  • Если вы думаете, что Tomcat будет достаточно сильным и предоставит вам все необходимые функции, используйте jsvc и установите Tomcat на порт 80.

Следуя ответу @deutsch, Tomcat НЕ должен запускаться с правами root в UNIX. Если вы устанавливаете его из пакета, например RPM tomcat6 для Fedora / CentOS / Red Hat, он будет работать от имени пользователя tomcat с ограниченным набором привилегий.

Сказав это, я согласен с последним абзацем @ Deutsch; используйте Apache в качестве внешнего интерфейса для Tomcat, если только у вас не истек крайний срок для развертывания. Даже если вы еще не так хорошо с ним знакомы, легко получить базовое развертывание с mod_proxy перед Tomcat, и вы почти наверняка выиграете от повышения гибкости и безопасности в будущем.

Проблема, с которой я столкнулся как с Tomcat, так и с Glassfish в UNIX, заключается в том, что (поскольку они, я полагаю, являются приложениями Java) они не могут привязаться к порту 80, а затем отбросить привилегии root. Запуск таких вещей от имени root - не лучшая практика, поэтому остается два варианта:

(1) Запустите сервер приложений как обычный пользователь, привязанный к высокому порту (скажем, 8080), и используйте что-то вроде правила iptables для перенаправления трафика порта 80 на порт 8080. Я сделал это с некоторыми серверами Glassfish в Linux, и это сработало. отлично.

(2) Запустите сервер приложений от имени обычного пользователя Apache. Apache может связываться с портом 80, отбрасывать привилегии, а затем проксировать запросы на ваш сервер приложений на высоком порту.

Я предпочитаю второе, но в основном потому, что я давно работаю с Apache и считаю его удобным в настройке и управлении. Так что, если вы знаете, что Apache хорошо его использует, вы будете счастливы, когда вам понадобится переписать некоторые URL-адреса на лету или настроить заголовки истечения срока действия. С другой стороны, если у вас нет опыта работы с Apache (или в данном случае, поскольку вам нужно, чтобы все было как можно легче), может быть проще придерживаться только Tomcat и использовать iptables.