TOC

Как использовать Apache в качестве обратного прокси с mod_proxy на CentOS 7

Вступление

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

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

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

Предпосылки

Чтобы следовать этому уроку, вам понадобится:

Шаг 1 - Представляем необходимые модули Apache

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

  • + mod_proxy +, основной прокси-модуль Apache, модуль для перенаправления соединений; это позволяет Apache выступать в качестве шлюза к базовым серверам приложений.

  • + mod_proxy_http +, который добавляет поддержку прокси-соединений HTTP.

  • + mod_proxy_balancer + и + mod_lbmethod_byrequests +, которые добавляют функции балансировки нагрузки для нескольких внутренних серверов.

Все четыре модуля включены по умолчанию при новой установке CentOS 7. Вы можете проверить, что они включены, запустив:

httpd -M

Вывод команды выведет список всех включенных модулей Apache. Четыре строки, которые вы ищете, - это названные выше имена модулей:

Output. . .

. . .

. . .

. . .

. . .

Если модули не включены, вы можете включить их, открыв + / etc / httpd / conf.modules.d / 00-proxy.conf + с помощью + nano +:

sudo nano /etc/httpd/conf.modules.d/00-proxy.conf

и раскомментируйте строки необходимыми модулями, удалив знак «+ # +» в начале строки, чтобы файл выглядел следующим образом:

/etc/httpd/conf.modules.d/00-proxy.conf

. . .

. . .

. . .

. . .

. . .

Чтобы изменения вступили в силу, сохраните файл и перезапустите Apache.

sudo systemctl restart httpd

Теперь Apache готов действовать в качестве обратного прокси-сервера для HTTP-запросов. На следующем шаге мы создадим два очень базовых серверных сервера. Это поможет нам проверить, правильно ли работает конфигурация, но если у вас уже есть свои собственные серверные приложения, вы можете перейти к шагу 3.

Шаг 2 - Создание тестовых серверов Backend

Запуск некоторых простых бэкэнд-серверов - это простой способ проверить правильность работы конфигурации Apache. Здесь мы создадим два тестовых сервера, которые отвечают на HTTP-запросы с печатью строки текста. Один сервер скажет * Привет, мир! *, А другой скажет * Привет, мир! *.

Flask - это микросхема Python для создания веб-приложений. Мы используем Flask для создания тестовых серверов, потому что базовое приложение требует всего несколько строк кода. Вам не нужно знать Python, чтобы настроить их, но если вы хотите учиться, вы можете посмотреть these учебники по Python ,

Давайте сначала установим файлы репозитория пакетов IUS. IUS (Inline with Upstream Stable) - это проект сообщества, который предоставляет новейшие версии некоторых программ для CentOS, включая Python 3.

sudo yum -y install https://centos7.iuscommunity.org/ius-release.rpm

Затем установите Python 3 и Pip, рекомендуемый менеджер пакетов Python.

sudo yum -y install python35u python35u-pip

Используйте Pip для установки Flask.

sudo pip3.5 install flask

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

nano ~/backend1.py

Скопируйте следующий код в файл, затем сохраните и закройте его.

~ / Backend1.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return 'Hello world!'

Первые две строки инициализируют структуру Flask. Существует одна функция + home () +, которая возвращает строку текста (+ Hello world! +). Строка [email protected] ('/') + над определением функции + home () + указывает Flask использовать возвращаемое значение + home () + в качестве ответа на HTTP-запросы, направленные на + / + корневой URL приложения.

Второй внутренний сервер точно такой же, как и первый, за исключением возврата к другой строке текста, поэтому начните с дублирования первого файла.

cp ~/backend1.py ~/backend2.py

Откройте только что скопированный файл.

nano ~/backend2.py

Измените сообщение, которое будет возвращено с * Hello world! * На * Howdy world! *, Затем сохраните и закройте файл.

~ / Backend2.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return ''

Используйте следующую команду для запуска первого фонового сервера на порту + 8080 +. Это также перенаправляет вывод Flask в + / dev / null i, потому что в дальнейшем он будет замаскировать вывод консоли.

FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &

Здесь мы предшествуем команде + flask +, устанавливая переменную окружения + FLASK_APP + в той же строке. Переменные среды - это удобный способ передачи информации в процессы, порожденные из оболочки. Вы можете узнать больше о переменных среды в How To Прочитайте и установите переменные среды и оболочки в VPS Linux.

В этом случае использование переменной окружения гарантирует, что настройка применяется только к выполняемой команде и не будет оставаться доступной после этого, так как мы будем передавать другое имя файла таким же образом, чтобы сообщить команде + flask + запуск второго сервера.

Точно так же используйте эту команду для запуска второго сервера на порту + 8081 +. Обратите внимание на другое значение для переменной среды + FLASK_APP.

FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &

Вы можете проверить, что оба сервера работают, используя + curl. Протестируйте первый сервер:

curl http://127.0.0.1:8080/

Это выведет * Hello world! * В терминал. Протестируйте второй сервер:

curl http://127.0.0.1:8081/

Это выведет * Привет мир! * Вместо.

На следующем шаге мы изменим файл конфигурации Apache, чтобы разрешить его использование в качестве обратного прокси-сервера.

Шаг 3 - Изменение конфигурации по умолчанию для включения обратного прокси

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

Создайте новый виртуальный хост по умолчанию, создав новый пустой файл конфигурации Apache в каталоге + / etc / httpd / conf.d +, используя + nano + или ваш любимый текстовый редактор.

sudo nano /etc/httpd/conf.d/default-site.conf

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

Пример 1 - обратный прокси-сервер для одного внутреннего сервера

Вставьте следующее содержимое в файл + default-site.conf +, чтобы ваш файл конфигурации выглядел следующим образом:

/etc/httpd/conf.d/default-site.conf

Если вы следовали примеру серверов в шаге 2, используйте +127.0.0.1: 8080 +, как написано в предыдущем блоке. Если у вас есть свои собственные серверы приложений, используйте их адреса.

Здесь есть три директивы:

  • + ProxyPreserveHost + заставляет Apache передавать исходный заголовок + Host + бэкэнд-серверу. Это полезно, так как сервер уведомляет адрес, используемый для доступа к приложению.

  • + ProxyPass + - это основная директива конфигурации прокси. В этом случае он указывает, что все, что находится под корневым URL (+ / +), должно быть сопоставлено с внутренним сервером по указанному адресу. Например, если Apache получает запрос на «+ / example », он подключится к « http: /// example +» и вернет ответ исходному клиенту.

  • + ProxyPassReverse + должен иметь ту же конфигурацию, что и + ProxyPass +. Он сообщает Apache, что нужно изменить заголовки ответа от внутреннего сервера. Это гарантирует, что если внутренний сервер вернет заголовок перенаправления местоположения, браузер клиента будет перенаправлен на адрес прокси, а не на адрес внутреннего сервера, который не будет работать должным образом.

Чтобы эти изменения вступили в силу, перезапустите Apache.

sudo systemctl restart httpd

Теперь, если вы откроете + http: // + в веб-браузере, вы увидите ответ вашего внутреннего сервера вместо стандартной страницы приветствия Apache. Если вы выполнили шаг 2, это означает, что вы увидите * Hello world! *.

Пример 2. Балансировка нагрузки на нескольких внутренних серверах.

Если у вас несколько бэкэнд-серверов, хороший способ распределить трафик между ними при прокси - это использовать функции балансировки нагрузки + mod_proxy +.

Замените все содержимое в блоке + VirtualHost + следующим, чтобы ваш файл конфигурации выглядел следующим образом:

/etc/httpd/conf.d/default-site.conf

Конфигурация аналогична предыдущей, но вместо того, чтобы указывать один внутренний сервер напрямую, мы использовали дополнительный блок + Proxy + для определения нескольких серверов. Блок называется + balancer: // + (имя может быть свободно изменено) и состоит из одного или нескольких + BalancerMember +, которые указывают адреса базового сервера. Директивы + ProxyPass + и + ProxyPassReverse + используют пул балансировщика нагрузки с именем + mycluster + вместо определенного сервера.

Если вы следовали примеру серверов в шаге 2, используйте +127.0.0.1: 8080 + и +127.0.0.1: 8081 + для директив + BalancerMember +, как написано в предыдущем блоке. Если у вас есть свои собственные серверы приложений, используйте их адреса.

Чтобы эти изменения вступили в силу, перезапустите Apache.

sudo systemctl restart httpd

Если вы откроете + http: // + в веб-браузере, вы увидите ответы своих бэкэнд-серверов вместо стандартной страницы Apache. Если вы выполнили шаг 2, при многократном обновлении страницы должны отображаться * Hello world! * И * Howdy world! *, Что означает, что обратный прокси-сервер работает и выполняет балансировку нагрузки между обоими серверами.

Заключение

Теперь вы знаете, как настроить Apache в качестве обратного прокси-сервера для одного или нескольких базовых серверов приложений. + mod_proxy + может эффективно использоваться для настройки обратного прокси-сервера для серверов приложений, написанных на множестве языков и технологий, таких как Python и Django или Ruby и Ruby on Rails. Он также может использоваться для балансировки трафика между несколькими внутренними серверами для сайтов с большим трафиком или для обеспечения высокой доступности через несколько серверов, или для обеспечения безопасной поддержки SSL для внутренних серверов, не поддерживающих стандартную SSL.

Хотя + mod_proxy + с + mod_proxy_http + является, пожалуй, наиболее часто используемой комбинацией модулей, есть несколько других, которые поддерживают различные сетевые протоколы. Мы не использовали их здесь, но некоторые другие популярные модули включают в себя:

  • + mod_proxy_ftp + для FTP.

  • + mod_proxy_connect + для туннелирования SSL.

  • + mod_proxy_ajp + для AJP (Apache JServ Protocol), например, на базе Tomcat.

  • + mod_proxy_wstunnel + для веб-сокетов.

Чтобы узнать больше о + mod_proxy +, вы можете прочитать http://httpd.apache.org/docs/current/mod/mod_proxy.html так же официальную документацию Apache + mod_proxy +].

Related