Tomcat 7 с mod_jk

Я нахожусь на перекрестке в принятии решения, использовать ли mod_jk или mod_proxy для настройки системы балансировки нагрузки с Apache 2 и Tomcat 7. Я читал обычное сравнение, что mod_jk более мощный, но сложный в настройке и т. Д., Но все, что я читаю, это немного устаревший (2007-2010) и основанный на моих текущих требованиях, я могу пойти любым путем.

Теперь посмотрим на документацию Tomcat 7 по разъемам! Я вижу, что они по сути осуждают все, кроме mod_proxy:

Другие собственные разъемы, поддерживающие AJP, могут работать, но больше не поддерживаются.

Значит ли это, что новое использование должно идти с mod_proxy?

Источник

2 ответа

Решение

mod_proxy - это модуль HTTP-сервера Apache, а не модуль Apache Tomcat.

Эта страница говорит о том, что Tomcat поддерживает либо JK1.2, либо протокол AJP, предоставляемый модулем mod_proxy в Apache HTTP.

Исторически вам приходилось использовать mod_jk для обеспечения поддержки AJP1.3 серверу Apache HTTP, а в Apache HTTP 2.2 это теперь предусмотрено в модуле mod_proxy - см. Http://httpd.apache.org/docs/2.2/. mod / mod_proxy.html, в котором говорится:

Этот модуль реализует прокси / шлюз для Apache. Он реализует возможности прокси для AJP13 (Apache JServe Protocol версии 1.3), FTP, CONNECT (для SSL), HTTP/0.9, HTTP/1.0 и HTTP/1.1.

Это дает вам пару вариантов:

  1. Используйте коннектор HTTP в Tomcat и подключите конечных клиентов напрямую к этому.
  2. Используйте коннектор HTTP в Tomcat и прокси-сервер с помощью HTTP-прокси mod_proxy.
  3. Используйте коннектор AJP1.3 в Tomcat и прокси-сервер с помощью функции прокси-сервера HTTP mod_proxy.
  4. Используйте коннектор AJP1.2 в Tomcat и подключитесь к нему с помощью модуля AJP HTTP mod_jk в Apache.

Моя рекомендация будет заключаться в варианте 3.

Конкретной страницей с информацией о настройке этого в Apache является http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html

Источник

За прошедшие годы было разработано несколько коннекторов, позволяющих Apache httpd взаимодействовать с Tomcat, которые использовали различные протоколы. При поиске в Интернете информации о том, как это сделать, нет ничего необычного в том, чтобы наткнуться на действительно плохой, устаревший совет. Итак, прежде всего единственные варианты, которые вы должны рассмотреть для этого:

  • mod_jk
  • mod_proxy_http
  • mod_proxy_ajp

Все остальные опции не поддерживаются в течение ряда лет, поэтому вам следует избегать mod_jk2, mod_jserv, mod_webapp и любых других модулей, которые здесь не обсуждаются. Там три, прежде всего, в настоящее время поддерживаются и все активно развиваются.

Мой опыт в оказании поддержки клиентам на рабочем месте состоит в том, что в наши дни типичный клиент с большей вероятностью обнаружит ошибку в mod_proxy_ajp, чем в mod_jk или mod_proxy_http. (Несколько лет назад mod_proxy_ajp не был таким зрелым, но сейчас я не вижу никакой разницы.)

Это подводит нас к сложному вопросу: HTTP (mod_proxy_http) или AJP (mod_proxy_ajp или mod_jk)? И ответ? Это зависит! Оба протокола имеют свои сильные и слабые стороны. Какой из них подходит вам, будет зависеть от ваших обстоятельств. Факторы, которые обычно влияют на этот выбор:

  • Один протокол / модуль уже используется?
  • Нужно ли шифровать связь между httpd и Tomcat?
  • Имеет ли httpd терминал SSL, но информация о SSL должна быть передана Tomcat?

Если вы уже используете mod_jk, mod_proxy_http или mod_proxy_ajp и он отвечает всем вашим требованиям, то вряд ли есть веская причина для его изменения. Было бы лучше придерживаться того, что вы в настоящее время используете, и иметь согласованность между вашими экземплярами httpd.

Если вам нужно зашифровать связь между httpd и Tomcat, это значительно упрощает mod_proxy_http, так как вы можете просто переключиться с http на протокол https. mod_jk и mod_proxy_ajp используют протокол AJP, который не поддерживает шифрование, поэтому вы должны реализовать его отдельно через туннель SSH, IPSec или аналогичный. Это может значительно усложнить настройку канала связи httpd-Tomcat.

Когда httpd завершает SSL, предоставляя атрибуты SSL (две простые директивы), тогда mod_jk и mod_proxy_ajp автоматически передают эту информацию Tomcat, и Tomcat делает ее доступной для веб-приложений без какой-либо дополнительной настройки. Чтобы добиться того же результата с mod_proxy_http, необходимо настроить httpd для добавления информации SSL в качестве заголовков http, а в Tomcat необходимо настроить Valve, чтобы извлечь эту информацию и сделать ее доступной для веб-приложений. Поэтому сделать информацию SSL доступной для Tomcat немного сложнее с mod_proxy_http.

mod_jk и mod_proxy_ * также имеют очень разные стили конфигурации. Директивы mod_proxy_ * согласуются с другими директивами httpd, тогда как mod_jk использует внешний файл свойств. Для системных администраторов, знакомых с httpd, подход mod_jk может показаться немного странным.

В итоге:

  • Если вам нужно зашифровать канал httpd для Tomcat, используйте mod_proxy_http
  • Если вам нужно предоставить информацию SSL для вашего веб-приложения, используйте mod_jk или mod_proxy_ajp
  • Если вы уже используете один из этих модулей, то изменение может вызвать больше хлопот, чем экономит
  • Если бы у меня был совершенно свободный выбор, я бы использовал mod_proxy_http только потому, что конфигурация более совместима с другими модулями httpd, его легче отлаживать с помощью Wireshark, и он может использовать ваши существующие HTTP-коннекторы в Tomcat.

См. Также презентацию, которую я написал ( http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies.pdf) и дополнительные комментарии Райнера Юнга к этой презентации ( http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies-notes-rjung.txt)

Источник
Другие вопросы по тегам