Показать статистику
0 голосов
от (500 баллов)
1.5тыс. просмотров 1 ответов

1 Ответ

0 голосов
от (26.4тыс. баллов)
редактировать от

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

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

Мы будем использовать протокол AJP, который можно использовать между веб-серверами и контейнерами приложений на основе Java, чтобы обеспечить возможность балансировать нагрузкой между несколькими серверами приложений, однако настройка балансировщика нагрузки выходит за рамки данного руководства. 

Мы настроим нашу настройку на Red Hat Linux 7.5, но веб-сервер Apache, модуль AJP и контейнер приложений Apache Tomcat доступны везде, и, таким образом, эта установка переносима с небольшими изменениями, такими как пути файловой системы или имена служб.

Установка необходимого программного обеспечения

Сначала нам нужно установить сервисы, которые мы будем использовать. При настройке с балансировкой нагрузки сервер(ы) Tomcat могут находиться на разных компьютерах, и часто они предоставляют ферму контейнеров, которые создают сервис.

# yum install httpd tomcat tomcat-webapps

Мы устанавливаем tomcat-webapps для целей тестирования, в этом пакете есть примеры веб-приложений, развернутых на нашем сервере Tomcat при установке. Мы будем использовать это приложение, чтобы проверить, что наша установка работает как задумано. 
Теперь мы можем включить и запустить наш сервер Tomcat:

# systemctl enable tomcat
# systemctl start tomcat

И наш веб-сервер:

# systemctl enable httpd
# systemctl start httpd

Установка по умолчанию httpd содержит нужные нам прокси-модули. Чтобы убедиться, что это так, мы можем запросить веб-сервер с помощью apachectl:

# apachectl -M | grep ajp
 proxy_ajp_module (shared)

1.x версии Apache используют mod_jk модуль вместо proxy_ajp.


Конфигурация httpd

Примеры веб-приложений, развернутых в Tomcat, по умолчанию публикуются после установки server-url:8080/examples. Мы будем отправлять прокси-запросы, поступающие на порт 80 сервера (порт http по умолчанию), запрашивающие что-либо из того, что в server-url/examples должно быть обработано examples веб-приложением, развернутым в Tomcat. Запросы, поступающие на любой другой URL на сервере, будут обслуживаться веб-сервером. Мы настроим некоторый статический контент, чтобы показать эту функциональность. 

В нашем примере сервер называется ws.foobar.com. Чтобы прокси работал, создайте текстовый файл с вашим любимым редактором в каталоге конфигурации выпадающего веб-сервера, который находится /etc/httpd/conf.d в версиях Red Hat, с расширением .conf. Нашей установке не требуется, чтобы Tomcat был доступен напрямую, поэтому мы используем в localhost в качестве целевого хоста /etc/httpd/conf.d/example_proxy.conf файл:

<VirtualHost ws.foobar.com:80>
  ServerName ws.foobar.com
ProxyRequests Off
ProxyPass /examples ajp://localhost:8009/examples
ProxyPassReverse /examples ajp://localhost:8009/examples
</VirtualHost>

Чтобы быть в безопасности, мы можем проверить правильность нашей конфигурации перед применением с apachectl:

# apachectl configtest
Syntax OK

Если тест конфигурации возвращает ошибку, подобную следующей:

Could not resolve host name ws.foobar.com -- ignoring!

Это означает, что наша ServerName директива недействительна, так как она не может быть разрешена веб-сервером. Либо нам нужно зарегистрировать его в (локальном или глобальном) DNS, либо указать в /etc/hosts файле строку, содержащую публичный IP-адрес хоста, за которым следует имя, которое мы дали в приведенной выше конфигурации. Если файл hosts уже содержит IP с другим именем (может быть, реальным именем хоста), мы можем добавить имя сервера после имени хоста (ов) в той же строке, настройка будет работать. 

После успешного тестирования нам нужно применить новую конфигурацию, перезапустив веб-сервер:

# systemctl restart httpd
от (26.4тыс. баллов)
редактировать от
0

Продолжая тему:

Конфигурация Tomcat

При установке по умолчанию контейнер Tomcat будет прослушивать запросы AJP на всех интерфейсах через порт 8009. Это можно проверить в основном файле конфигурации:

# view /usr/share/tomcat/conf/server.xml
[..]
<!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
[..]

Если нам не требуется, чтобы контейнер Tomcat и приложения внутри него были доступны сами по себе, мы можем настроить каждый соединитель на прослушивание только на localhost:

Connector address="127.0.0.1" port=..."

Чтобы подать заявку, мы можем перезапустить Tomcat с помощью:

# systemctl restart tomcat

В нашей лаборатории машина не будет этого делать, так как мы должны видеть, что нам подают одинаковый контент как на порт 80, так и на порт 8080.

Тестирование

Наша минимальная настройка прокси AJP завершена, мы можем ее протестировать. Из командной строки мы можем вызвать examples приложение напрямую через порт 8080:

$ wget http://ws.foobar.com:8080/examples
--2019-02-14 10:23:58--  http://ws.foobar.com:8080/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:8080... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2019-02-14 10:23:58--  http://ws.foobar.com:8080/examples/
Reusing existing connection to ws.foobar.com:8080.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples'

100%[=========================================================================================================================================================================>] 1,253       --.-K/s   in 0s      

2019-02-14 10:23:58 (104 MB/s) - 'examples' saved [1248/1248]


И посмотрите на предоставленное содержимое:

$ tail examples
<h3>Apache Tomcat Examples</H3>
<p></p>
<ul>
<li><a href="/servlets">Servlets examples</a></li>
<li><a href="/jsp">JSP Examples</a></li>
<li><a href="/websocket/index.xhtml">WebSocket (JSR356) Examples</a></li>
<li><a href="/websocket-deprecated">WebSocket Examples using the deprecated
    Apache Tomcat proprietary API</a></li>
</ul>
</body></html>

И если мы вызываем одно и то же приложение через наш AJP-прокси, мы также должны получить ответ, пока в корне документа веб-сервера нет содержимого:

$ wget http://ws.foobar.com/examples
--2019-02-14 10:24:06--  http://ws.foobar.com/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2019-02-14 10:24:06--  http://ws.foobar.com/examples/
Reusing existing connection to ws.foobar.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples.1'

100%[=========================================================================================================================================================================>] 1,253       --.-K/s   in 0s      

2019-02-14 10:24:06 (101 MB/s) - 'examples.1' saved [1253/1253]


Если все работает, мы получим ответ с тем же содержанием, так как окончательный ответ предоставляется тем же приложением в контейнере:

$ tail examples.1
<h3>Apache Tomcat Examples</h3>
[...]

Мы также можем проверить наши настройки с помощью браузера. Нам нужно назвать все URL с именем сервера в качестве хоста (по крайней мере, тот, который проксируется). Для этого машина, на которой запущен браузер, должна иметь возможность разрешать имя сервера с помощью файла DNS или хоста. 

В нашей лабораторной среде мы не отключили прослушивание Tomcat в общедоступном интерфейсе, поэтому мы можем видеть, что предоставляется при запросе непосредственно через порт 8080:

Мы можем получить тот же контент через прокси AJP, предоставляемый веб-сервером через порт 80:

Действуя как прокси, httpd может обслуживать любой другой контент. Мы можем создать статический контент, доступный по другому URL на том же сервере: 

# mkdir /var/www/html/static_content 
# echo "<html><body>Static content</body></html>" > /var/www/html/static_content/static.html


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

Итог

Веб-сервер Apache расширяется за счет модулей, одним из которых является прокси-модуль AJP. В приведенном выше руководстве используется один компьютер и предоставляется одно приложение с прокси-сервером, но один и тот же веб-сервер может предоставить одну запись многим приложениям, возможно, на многих хостах, на которых выполняются контейнеры приложений, и в то же время предоставлять другой веб-контент. 

В сочетании с другими модулями, такими как mod_security мы можем добавить многие функции к нашему сервису без необходимости разрабатывать их внутри приложения или, если возникнет такая необходимость, перенаправить прокси-сервер на другую конечную точку с помощью одной редакции файла конфигурации и перезагрузить веб-сервер, выполнив миграцию или Представление новой версии приложения занимает считанные секунды. Та же самая перезагрузка может привести посетителя к странице, объясняющей запланированное время простоя, в то время как обслуживание выполняется на серверах приложений - варианты использования прокси-сервера AJP ограничены только воображением ИТ-персонала.

...