ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
Обратный прокси – сервер представляет собой тип прокси-сервера, который принимает HTTP(S) запросы и прозрачно распределяет их на один или несколько внутренних серверов. Обратные прокси-серверы являются полезными, поскольку многие современные веб – приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, которые не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.
Вы можете использовать обратный прокси-сервер для предотвращения непосредственной доступности основных серверов приложений. Они также могут быть использованы для распределения нагрузки от входящих запросов на нескольких различных серверах приложений, увеличивая производительность в масштабе и обеспечение отказоустойчивости. Они могут заполнить пробелы с функциями сервера приложений, которые они не предоставляют, такие как кэширование, сжатие а также шифрование SSL.
В этом учебном пособии вы настроите Apache в качестве основного обратного прокси – сервера с помощью расширения mod_proxy для перенаправления входящих подключений к одному или нескольким внутренним серверам, работающих в той же сети. Этот учебник используется простой бэкенд, написанный с Flask web framework, но вы можете использовать любой сервер данных, которые вы предпочитаете.
Следуя этому руководству, вам потребуется:
nano установленный с помощью команды yum install nano. CentOS поставляется с текстовым редактором vi по умолчанию, но nano может быть более удобным для пользователей.Модули, которые необходимы для использования 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-запросов. На следующем шаге мы создадим два самых основных внутренних сервера. Это поможет нам проверить, если конфигурация работает правильно.
Запуск некоторых простых внутренних серверов является простой способ проверить, что ваша конфигурация Apache работает должным образом . Здесь мы создадим два тестовых сервера, которые отвечают HTTP – запросам с печатью строки текста. Один сервер будет сказать Привет, мир! а другой скажет Мой мир!
ПримечаниеВ настоящих установках, Backend серверы, как правило, возвращают один и тот же тип содержимого. Тем не менее, для этого теста, в частности, имея два сервера, которые возвращают различные сообщения, позволяет легко проверить, что механизм балансировки нагрузки использует оба.
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/
Это выведет Мой мир!
ПримечаниеДля того, чтобы закрыть оба тестовых сервера после того, как вы больше не нуждаетесь в них, после того как вы закончите этот урок, вы можете просто выполнить killall flask.
На следующем шаге мы будем изменять конфигурационный файл Apache, чтобы включить его использование в качестве обратного прокси-сервера.
В этом разделе мы настроим виртуальный хост Apache по умолчанию, чтобы использовать в качестве обратного прокси-сервера для одного сервера бэкэнда или массива с балансировкой нагрузки внутренних серверов.
В этом руководстве мы применяем настройки на уровне виртуального хоста. При установке по умолчанию Apache, нет настроенных виртуальных хостов. Мы будем создавать единый виртуальный хост по умолчанию, который будет ловить весь трафик. Тем не менее, вы можете использовать все эти фрагменты конфигурации на других виртуальных хостов.
Если ваш сервер работает на Apache как HTTP и HTTPS-сервер, ваша конфигурация обратного прокси-сервера должна быть размещена как в HTTP и HTTPS виртуальных хостов.
Создание нового виртуального хоста по умолчанию, создав новый пустой файл конфигурации Apache в каталоге /etc/httpd/conf.d, используя nano или ваш любимый текстовый редактор.
sudo nano /etc/httpd/conf.d/default-site.conf
В первом примере ниже показано, как настроить виртуальный хост по умолчанию для обратного прокси-сервера для одного сервера, а второй устанавливает балансировку нагрузки обратного прокси для нескольких внутренних серверов.
Вставьте следующее содержимое в файл 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/exampleProxyPassReverse должен иметь ту же конфигурацию, что и ProxyPass. Это говорит Apache, чтобы изменить заголовки ответа от сервера бэкэнда. Это гарантирует, что если внутренний сервер возвращает заголовок перенаправления местоположения, браузер клиента будет перенаправлен на адрес прокси – сервера и не адреса сервера, бэкенда, который не будет работать, как предполагалось.Чтобы изменения вступили в силу, перезапустите Apache.
sudo systemctl restart httpd
Теперь, если вы получаете доступ к http://your_server_ip через веб – браузер, вы увидите ответ сервера бэкэнда вместо стандартной страницы приветствия Apache. Если вы следовали инструкциям Шаг 2, то вы будете видеть Привет мир!
Если у вас есть несколько внутренних серверов, хороший способ, чтобы распределить трафик между ними, когда проксирование заключается в использовании балансировки нагрузки функцией 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.
