Нет подходящих цитат

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

FavoriteLoadingДобавить в избранное
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...
2 февраля 2017
Как использовать Apache в качестве обратного прокси с mod_proxy на Debian 8
Обратный прокси – сервер представляет собой тип прокси-сервера, который принимает HTTP(S) запросы и прозрачно распределяет их на один или несколько внутренних серверов. Обратные прокси-серверы являются полезными, поскольку многие современные веб – приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, которые не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.

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

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

Предпосылки

Следуя этому руководству, вам потребуется:

Шаг 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

 

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

/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 – запросам с печатью строки текста. Один сервер будет сказать Привет, мир! а другой скажет Мой мир!

Примечание
В настоящих установках, 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

 

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

~ / 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

 

Измените сообщение, которое будет возвращено, не Привет, мир! а Мой мир! , затем сохраните и закройте файл.

~ / 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, чтобы включить его использование в качестве обратного прокси-сервера.

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

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

 

Примечание

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

Если ваш сервер работает на Apache как HTTP и HTTPS-сервер, ваша конфигурация обратного прокси-сервера должна быть размещена как в HTTP и HTTPS виртуальных хостов.

Создание нового виртуального хоста по умолчанию, создав новый пустой файл конфигурации 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
<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 следующими, так чтобы ваш файл конфигурации выглядел следующим образом:

/etc/httpd/conf.d/default-site.conf
<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.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Просмотров: 172

Если статья понравилась, то поделитесь ей в социальных сетях:

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!

badge
Обратный звонок 1
Отправить
galka

Спасибо! Ваша заявка принята

close
galka

Спасибо! Ваша заявка принята

close