Обратный прокси – сервер представляет собой тип прокси-сервера, который принимает HTTP(S) запросы и прозрачно распределяет их на один или несколько внутренних серверов. Обратные прокси-серверы являются полезными, поскольку многие современные веб – приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, которые не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.
Вы можете использовать обратный прокси-сервер для предотвращения непосредственной доступности основных серверов приложений. Они также могут быть использованы для распределения нагрузки от входящих запросов на нескольких различных серверах приложений, увеличивая производительность в масштабе и обеспечение отказоустойчивости. Они могут заполнить пробелы с функциями сервера приложений, которые они не предоставляют, такие как кэширование, сжатие а также шифрование SSL.
В этом учебном пособии вы настроите Apache в качестве основного обратного прокси – сервера с помощью расширения mod_proxy
для перенаправления входящих подключений к одному или нескольким внутренним серверам, работающих в той же сети. Этот учебник используется простой бэкенд, написанный с Flask web framework, но вы можете использовать любой сервер данных, которые вы предпочитаете.
Предпосылки
Следуя этому руководству, вам потребуется:
- Один сервер CentOS 7 с начальной настройкой сервера CentOS 7, включая sudo а не суперпользователя.
- Apache 2, установленный на сервере, следуя шагу как установить Linux, Apache, MySQL, PHP (LAMP) на CentOS 7.
- Необязательно, текстовый редактор
nano
установленный с помощью командыyum install nano
. CentOS поставляется с текстовым редакторомvi
по умолчанию, ноnano
может быть более удобным для пользователей.
Шаг 1 – Введение в необходимые модули Apache
Модули, которые необходимы для использования Apache в качестве обратного прокси – сервера включают в себя mod_proxy
и некоторые из его дополнительных модулей, которые расширяют ее функциональные возможности для поддержки различных сетевых протоколов. В частности, мы будем использовать:
mod_proxy
, главный прокси-модуль модуля Apache для перенаправления соединений; который позволяет Apache выступать в качестве шлюза для основных серверов приложений.mod_proxy_http
, добавляет поддержку проксирования HTTP соединений.mod_proxy_balancer
иmod_lbmethod_byrequests
, что добавлять новые функции балансировки нагрузки для нескольких внутренних серверов.
Все четыре модуля включены по умолчанию на новой установке CentOS 7. Вы можете убедиться, что они разрешены командой:
httpd -M
Выводом команды будет список всех включенных модулей Apache.
. . . proxy_module (shared) . . . lbmethod_byrequests_module (shared) . . . proxy_balancer_module (shared) . . . proxy_http_module (shared) . . .
В случае , если модули не включены, вы можете включить их, открыв /etc/httpd/conf.modules.d/00-proxy.conf
с помощью текстового редактора nano
:
sudo nano /etc/httpd/conf.modules.d/00-proxy.conf
и раскомментировать линии с необходимыми модулями, удалив #
знак в начале строки, так что файл выглядит следующим образом :
. . . LoadModule proxy_module modules/mod_proxy.so . . . LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so . . . LoadModule proxy_balancer_module modules/mod_proxy_balancer.so . . . LoadModule proxy_http_module modules/mod_proxy_http.so . . .
Для того, чтобы изменения вступили в силу, сохраните файл и перезапустить Apache.
sudo systemctl restart httpd
Apache теперь готов действовать в качестве обратного прокси-сервера для HTTP-запросов. На следующем шаге мы создадим два самых основных внутренних сервера. Это поможет нам проверить, если конфигурация работает правильно.
Шаг 2 – Создание внутренних тестовых серверов
Запуск некоторых простых внутренних серверов является простой способ проверить, что ваша конфигурация Apache работает должным образом . Здесь мы создадим два тестовых сервера, которые отвечают HTTP – запросам с печатью строки текста. Один сервер будет сказать Привет, мир! а другой скажет Мой мир!
Flask является microframework Python для создания веб – приложений. Мы используем Flask для создания тестовых серверов, так как основное приложение требует всего несколько строк кода. Вам не нужно знать 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
Скопируйте следующий код в файл, а затем сохраните и закройте его.
from flask import Flask
app = Flask(__name__)
@app.route('/')
def home():
return 'Привет мир!'
Первые две строки инициализации Flask framework. Существует одна функция, home()
, которая возвращает строку текста (Привет мир!
). Строка @app.route('/')
над home()
говорит Flask использовать home()
возвращаемое значение в качестве ответа на HTTP – запросы, направленных на /
корневой URL приложения.
Второй сервер Бэкэнд точно так же, как и первый, кроме возвращения другой строки текста, поэтому начните путем дублирования первого файла.
cp ~/backend1.py ~/backend2.py
Откройте вновь скопированный файл.
nano ~/backend2.py
Измените сообщение, которое будет возвращено, не Привет, мир! а Мой мир! , затем сохраните и закройте файл.
from flask import Flask
app = Flask(__name__)
@app.route('/')
def home():
return 'Мой мир!'
Используйте следующую команду, чтобы запустить первый фоновый сервер на порту 8080
.
FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &
Здесь мы использовали команду flask
, установив переменную окружения FLASK_APP
в той же строке. Переменные окружения представляют собой удобный способ передачи информации о процессах, которые порождаются из оболочки.
В этом случае, используя переменную окружения гарантирует, что параметр применим только к запущенной команде и не будет оставаться доступным после того, как мы будет использовать другое имя файла точно так же использовать команду flask
, чтобы запустить второй сервер
Аналогичным образом, используйте эту команду, чтобы запустить второй сервер на порту 8081
. Обратите внимание на другое значение для переменной окружения FLASK_APP
.
FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &
Вы можете проверить, что оба сервера работают с использованием curl
. Тестирование первого сервера:
curl http://127.0.0.1:8080/
Это выведет Привет, мир! в терминале. Проверка второго сервера:
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
, так что ваш файл конфигурации выглядит следующим образом:
<VirtualHost *:80> ProxyPreserveHost On ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ </VirtualHost>
Если вы следовали вместе с серверами, например, на шаге 2, используйте 127.0.0.1:8080
как написано в блоке выше. Если у вас есть свои собственные серверы приложений, используйте их адреса вместо этих.
Есть три директивы здесь:
ProxyPreserveHost
передают Apache оригинальныйHost
заголовок на внутренний сервер. Это полезно, так как это делает сервер бэкенд осознаный адрес, используемый для доступа к приложению.ProxyPass
главная директива конфигурации прокси. В этом случае, он указывает, что все в корневом URL (/
) должен быть отображен на внутренний сервер по указанному адресу. Например, если Apache получает запрос на/example
, он будет подключаться и вернет ответ на оригинальный клиент.http://your_backend_server/example
ProxyPassReverse
должен иметь ту же конфигурацию, что иProxyPass
. Это говорит Apache, чтобы изменить заголовки ответа от сервера бэкэнда. Это гарантирует, что если внутренний сервер возвращает заголовок перенаправления местоположения, браузер клиента будет перенаправлен на адрес прокси – сервера и не адреса сервера, бэкенда, который не будет работать, как предполагалось.
Чтобы изменения вступили в силу, перезапустите Apache.
sudo systemctl restart httpd
Теперь, если вы получаете доступ к http://your_server_ip через веб – браузер, вы увидите ответ сервера бэкэнда вместо стандартной страницы приветствия Apache. Если вы следовали инструкциям Шаг 2, то вы будете видеть Привет мир!
Пример 2 – балансировки нагрузки между несколькими серверами Backend
Если у вас есть несколько внутренних серверов, хороший способ, чтобы распределить трафик между ними, когда проксирование заключается в использовании балансировки нагрузки функцией mod_proxy
.
Заменить все содержимое внутри блока VirtualHost
следующими, так чтобы ваш файл конфигурации выглядел следующим образом:
<VirtualHost *:80> <Proxy balancer://mycluster> BalancerMember http://127.0.0.1:8080 BalancerMember http://127.0.0.1:8081 </Proxy> ProxyPreserveHost On ProxyPass / balancer://mycluster/ ProxyPassReverse / balancer://mycluster/ </VirtualHost>
Конфигурация аналогична предыдущей, но вместо указания одного сервера бэкэнд напрямую, мы использовали дополнительный блок Proxy
для определения нескольких серверов. Блок с именем balancer://mycluster
(имя может быть свободно изменено) и состоит из одного или нескольких BalancerMember
, которые определяют, лежащие в основе адреса бэкенда сервера. ProxyPass
и директива ProxyPassReverse
используют пул балансировки нагрузки с именем mycluster
вместо конкретного сервера.
Если вы следовали примеру на шаге 2, используя 127.0.0.1:8080
и 127.0.0.1:8081
для директивы BalancerMember
, как написано в блоке выше. Если у вас есть свои собственные серверы приложений, используйте их адреса вместо этих.
Чтобы изменения вступили в силу, перезапустите Apache.
sudo systemctl restart httpd
Зайдите в веб – браузере по адресу http://your_server_ip, вы увидите бэкэнд сервера вместо стандартной страницы Apache. Если вы следовали инструкциям на Шаге 2, обновите страницу несколько раз должен показать Привет, мир! и AndreyEx мир!, То есть обратный прокси – сервер работал и балансировка нагрузки между обоими серверами.
Вывод
Теперь вы знаете, как настроить 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
, вы можете прочитать на официальном сайте Apache документацию о mod_proxy
.