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

Tomcat 7 с mod_jk

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

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

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

Значит ли это, что mod_proxy следует использовать в новых целях?

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

  • mod_jk
  • mod_proxy_http
  • mod_proxy_ajp

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

Мой опыт оказания поддержки клиентам в $ work показывает, что в наши дни типичный клиент не более вероятно столкнется с ошибкой в ​​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)

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

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

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

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

Это дает вам несколько вариантов:

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

Я бы рекомендовал выбрать вариант 3.

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