Как использовать Apache в качестве обратного прокси при помощи mod_proxy на Ubuntu 16.04
04.04.2017 11:23
#Apache #Linux/Ubuntu #Python
Обратный прокси-сервер – это тип прокси-сервера, который ретранслирует HTTP/HTPPS-запросы на один или несколько бэкенд-серверов. Обратные прокси-серверы полезны, так как многие современные веб-приложения для обработки HTTP-запросов используют бэкенд-серверы приложений (к которым пользователи не должны иметь доступ напрямую), а также часто поддерживают только базовые функции HTTP.
Поэтому вы можете использовать обратный прокси-сервер для того, чтобы предупредить возможность пользователям получить прямой доступ к основным серверам приложений. Также использование обратного прокси-сервера поможет вам перераспределить нагрузку от поступающих запросов на несколько других серверов приложений. Благодаря этому улучшится производительность и увеличится отказоустойчивость.
Из этой статьи вы узнаете о том, как настроить Apache для использования в качестве обратного прокси-сервера при помощи mod_proxy – модуля Apache для перенаправления соединений на один или несколько бэкенд-серверов в этой же сети. В этом руководстве используется простой бэкенд, написанный с использованием фреймворка Flask, но вы можете использовать любой бэкенд на ваше усмотрение.
Требования
Для того, чтобы выполнить необходимые действия, вам понадобится:
- сервер с установленной ОС Ubuntu 16.04 и пользователем, который может выполнять команды sudo;
- установленный на вашем сервере Apache.
Шаг 1: включение необходимых модулей Apache
Существует множество модулей Apache, которые идут в комплекте и доступны к использованию, но не активированы после установки. Поэтому необходимо включить те модули, которые будут использоваться в этом руководстве.
Нужный нам модуль – это mod_proxy, а также несколько дополнений, которые расширяют его функционал и позволяют поддерживать различные сетевые протоколы. Если перечислять более конкретно, то понадобятся:
- mod_proxy – главный модуль Apache для перенаправления соединений; благодаря ему Apache может выступать в качестве шлюза для основных серверов приложений;
- mod_proxy_http – позволит использовать прокси для HTTP;
- mod_proxy_balancer и mod_lbmethod_byrequests – добавляют функции балансировки нагрузки для бэкенд-серверов.
Для того, чтобы активировать модули, выполните команды ниже в соответствующем порядке:
$ sudo a2enmod proxy $ sudo a2enmod proxy_http $ sudo a2enmod proxy_balancer $ sudo a2enmod lbmethod_byrequests
Затем перезапустите Apache для того, чтобы изменения вступили в силу.
$ sudo systemctl restart apache2
Теперь Apache будет выступать в качестве обратного прокси-сервера для HTTP-запросов. Следующий шаг не является обязательным, но он поможет протестировать работу Apache и убедиться, что все работает так, как нужно. Для этого необходимо создать два базовых бэкенд-сервера, однако если у вас они уже есть в наличии, то вы можете сразу перейти к шагу 3.
Шаг 2: создание тестовых бэкенд-серверов
Запуск нескольких базовых бэкенд-серверов – отличная возможность протестировать, корректно ли работает Apache. Поэтому необходимо создать два сервера, которые будут отвечать на HTTP-запросы, печатая строку текста. Один будет отвечать “Hello world!”, другой “ Hello Timeweb!”.
Примечание. Если говорить не о тестовом запуске, то обычно бэкенд-серверы отдают одинаковый тип контента. Однако для тестирования будет удобнее, если это будет два сервера с разными сообщениями, потому что так будет проще отследить, что балансировка нагрузки работает корректно.
Flask – это микрофреймворк Python, который используется для создания веб-приложений. В этом руководстве мы будем использовать Flask, так как для написания базового приложения требуется всего несколько строк. Вам необязательно знать Python для того, чтобы выполнить дальнейшие действия.
Для начала обновите список доступных пакетов:
Теперь установите Pip, рекомендованная система управления пакетами Python.
$ sudo apt-get -y install python3-pip
И уже при помощи Pip установите Flask:
Теперь, когда все необходимые компоненты установлены, можно перейти к созданию файла, в котором будет находиться необходимый для первого бэкенд-сервера код.
Файл можно создать в домашней директории пользователя, под которым вы авторизованы.
Скопируйте в файл текст, который приведен ниже, а затем сохраните и закройте файл.
from flask import Flask app = Flask(__name__) @app.route('/') def home(): return 'Hello world!'
Первые две строчки инициализируют фреймворк Flask. Единственная функция home() будет отдавать строку текста (“Hello world!”). А за то, чтобы этот текст появлялся в ответ на HTTP-запросы, отвечает @app.route('/').
Второй бэкенд-сервер будет точно таким же, как и первый, кроме единственного отличия в тексте.
Поэтому для начала необходимо скопировать первый файл:
$ cp ~/backend1.py ~/backend2.py
Теперь откройте новый скопированный файл:
И в последней строчке вместо “Hello world!” напишите, к примеру, “Hello Timeweb!”:
Команда ниже запустит первый бэкенд-сервер, его порт 8080.
$ FLASK_APP=~/backend1.py flask run –port=8080 >/dev/null 2>&1 &
Второй сервер тоже необходимо запустить, его порт 8081:
$ FLASK_APP=~/backend2.py flask run –port=8081 >/dev/null 2>&1 &
Теперь протестируем работу обоих серверов.
Сначала первого:
$ curl http://127.0.0.1:8080/
В ответ вы должны получить “Hello world!”.
Затем второй:
$ curl http://127.0.0.1:8081/
В этом случае вы увидите в терминале надпись “Hello Timeweb!”.
Примечание. Для того, чтобы закрыть оба тестовых сервера (например, после выполнения всех действий в этом руководстве), вы можете просто выполнить следующую команду: killall flask.
Далее мы изменим конфигурационный файл Apache для того, чтобы появилась возможность использовать его в качестве обратного прокси-сервера.
Шаг 3: изменение изначальных установок для включения прокси
В этой части необходимо внести изменения для того, чтобы изначальный виртуальный хост Apache выполнял роль обратного прокси-сервера для одного или нескольких бэкенд-серверов.
Сначала нужно открыть конфигурационный файл Apache в редакторе nano (или в другом редакторе на ваш выбор):
$ sudo nano /etc/apache2/sites-available/000-default.conf
Внутри этого файла найдите блок с первой строкой . Первый пример ниже продемонстрирует, как изменить этот файл так, чтобы использовать обратный прокси для одного бэкенд-сервера, а второй пример – для установки балансировки нагрузки для нескольких бэкенд-серверов.
1 пример: обратное прокси для одного бэкенд-сервера
Скопируйте текст ниже вместо всего текста, расположенного в блоке VirtualHost, то есть чтобы в итоге блок выглядел вот так:
ProxyPreserveHost On ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/
Если вы продолжаете следовать этому руководству и используете тестовые серверы, которые создали ранее, то скопируйте 127.0.0.1:8080, как и написано в примере. Если у вас есть свои собственные серверы приложений, то используйте их адреса.
В блоке используется три директивы:
- ProxyPreserveHost – заставляет Apache передать оригинальный заголовок Host бэкенд-серверу. Это полезно, так как в этом случае бэкенд-сервер получает адрес, который используется для доступа к приложению;
- ProxyPass – основная директива для настройки прокси. В данном случае она указывает, что все, что идет после корневого адреса URL (/), должно быть отправлено на бэкенд-сервер по указанному адресу. Например, если Apache получит запрос /primer, то он подключится к http://ваш_бэкенд-сервер/primer и отправит соответствующий ответ;
- ProxyPassReverse – должна иметь такие же настройки, как и ProxyPass. Она сообщает Apache, как изменить заголовки в ответе от бэкенд-сервера. Таким образом гарантируется, что браузер клиента будет перенаправлен на прокси-адрес, а не на адрес бэкенд-сервера.
После внесения изменений Apache необходимо перезапустить:
$ sudo systemctl restart apache2
Теперь, если вы наберете в браузере адрес своего сервера, вы увидите ответ от вашего бэкенд-сервера вместо приветственной страницы Apache.
2 пример: балансировка нагрузки между несколькими бэкенд-серверами
Если у вас есть несколько бэкенд-серверов, будет хорошей идеей при использовании прокси распределить трафик между ними; сделать это можно при помощи функции балансировки нагрузки утилиты mod_proxy.
Как и в первом примере, тут вам тоже необходимо заменить текст в блоке VirtualHost на следующий:
BalancerMember http://127.0.0.1:8080 BalancerMember http://127.0.0.1:8081 ProxyPreserveHost On ProxyPass / balancer://mycluster/ ProxyPassReverse / balancer://mycluster/
В целом текст похож на предыдущий, однако вместо указания одного бэкенд-сервера появляется новый блок Proxy, в котором указано несколько серверов. Блок называется balancer://mycluster (название можно изменить) и состоит из одного или нескольких BalancerMembers, которые определяют адреса лежащих в основе бэкенд-серверов.
Директивы ProxyPass и ProxyPassReverse используют пул балансировки нагрузки под названием mycluster вместо конкретного сервера.
Вы можете использовать адреса тестовых серверов (как указано выше), либо заменить их на адреса своих серверов.
Для того, чтобы изменения вступили в силу, перезапустите Apache:
$ sudo systemctl restart apache2
Теперь проведите такой же тест, как и в первом примере: введите IP-адрес вашего сервера в браузер и вместо стандартного приветствия Apache вы увидите один из ответов бэкенд-серверов. Если вы используете тестовые серверы, то это будет либо “Hello world!”, либо “Hello Timeweb!”. Обновите страницу несколько раз и, если вы увидели оба текста, значит все работает корректно.
Заключение
Теперь вы знаете, как настроить Apache в качестве обратного прокси-сервера для одного или нескольких внутренних серверов.
mod_proxy можно эффективно использоваться для того, чтобы настраивать обратный прокси для серверов с приложениями, написанных на различных языках программирования и технологиях, таких как Python, Django или Ruby и Ruby on Rails.
Также mod_proxy можно использовать для балансировки нагрузки между несколькими бэкенд-серверами для сайтов с большой нагрузкой, чтобы обеспечить высокую доступность таких ресурсов.
mod_proxy и mod_proxy_http самая популярная комбинация модулей, однако есть несколько других, которые поддерживают другие сетевые протоколы. Хотя в этом руководстве они не использовались, их тоже можно выделить отдельным списком:
- mod_proxy_ftp для FTP;
- mod_proxy_connect для SSL-туннеля;
- mod_proxy_ajp для протокола AJP (Apache JServ Protocol);
- mod_proxy_wstunnel для веб-сокетов.
Узнать более подробно о них вы можете в официальной документации mod_proxy Apache: http://httpd.apache.org/docs/current/mod/mod_proxy.html
Источник: https://timeweb.com/ru/community/articles/kak-ispolzovat-apache-v-kachestve-obratnogo-proksi-pri-pomoshchi-mod-proxy-na-ubuntu-16-04-1
Настройка mod_proxy в Apache
В общем, был такой таск: есть у нас локальная сетка и маршрутизатор Peplink. В локальной сетке на многих тазиках крутятся сайты, которые должны быть доступны извне. Как это сделать? Разносить по портам – не вариант, т. к. пользователю неудобно всё-таки набирать URL типа блаблабла:8081.
Решение – использовать HTTP-прокси, а на тазик с ним открыть в маршрутизаторе порты 80, 443. Для проксирования обычно используют nginx, но апач тоже отлично справляется с этой задачей.
Так сложилось, что тазик с прокси был Убунтой (клиент категорически н ехотел работать с другими дистрибутивами Linux), а “в Убунте всё не как у людей” (с) 🙂 потому конфигурация её несколько отличается от других дистрибутивов.
Но, приняв философию Убунты, я понял, что многие решения в ней очень даже удобны, хотя некоторые мне не нравятся – например, отсутствие пользователя root.
Но это уже философия, грозящая холиваром, потому перейдем к делу 🙂 В убунте манипулирование апачем происходит с помощью глобальных команд: включение/выключение виртуал хостов – a2ensite / a2dissite с одним аргументом – пути к конфигу, в котором прописан виртуал хост. Включение/выключение модов или расширений происводится командами a2enmod / a2dismod. В общем, алгоритм работы такой: 1) Нужно включить необходимые модули апача. Устанавливаем:
sudo apt-get install libapache2-mod-proxy-html libapache2-mod-gnutls
Разрешаем:
sudo a2enmod proxy
sudo a2enmod ssl
sudo a2enmod cache
sudo /etc/init.d/apache2 restart
2) Делаем конфиг виртуал хоста (по 1му файлу на 1 хост!) и помещаем его в /etc/apache2/sites-available. Пример HTTPS конфига проксирования на тазик с Confluence – это такая джавовская веб-морда для программистов и не только, работающая на Apache Tomcat (с портом 8444):
#мыло админа и документ рут не существующий – т. к. апач требует хоть какой-то обязательно
ServerAdmin [email protected]
DocumentRoot “/etc/httpd/docs/dummy-host.example.com”
#вот здесь внимательно заполняем теми данными, которые у нас есть в ДНС-ах
ServerName conf.mydomain.com
ServerAlias www.conf.mydomain.com
#настройки SSL – включение SSL и пути к файлам ключей
SSLEngine On
SSLCertificateFile /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/server.key
#включение прокси для данного виртуал хоста и некоторые настройки. Я в них особо не вчитывался – работает так отлично 🙂
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
ProxyVia full
Order deny,allow
Allow from all
#чего и куда проксируем / означает что проксируются все запросы к сайту, начиная с корня
ProxyPass / https://192.168.1.132:8444/
ProxyPassReverse / https://192.168.1.132:8444/
Замечание: Не забываем создать ssl-сертификаты либо положить с другой машины в папку /etc/ssl/ и выставить права (chmod 700 /etc/ssl/ и на файлы: chmod 600 /etc/ssl/server.crt и chmod 600 /etc/ssl/server.key)
Для HTTP virtual host убираются строчки, связанные с SSL и меняется порт 443 на 80, SSLProxyEngine On меняется наProxyEngine On. Ну и в директиве ProxyPass https на http – понятное дело.
Затем командой
sudo a2ensite /etc/apache2/sites-available/конфиг_виртуал_хоста
Активируем наш виртуал хост. После этого нужно перезагрузить апач:
sudo /etc/init.d/apache2 reload
Усё, будет проксировать. После долгого секса с Debian выяснил, что надо еще дополнительно сделать:
sudo a2enmod proxy_connect
sudo a2enmod proxy_html
sudo a2enmod proxy_ftp
Источник: http://geckich.blogspot.com/2011/11/modproxy-apache.html
Как использовать Apache в качестве обратного прокси с mod_proxy на..
Обратный прокси – сервер представляет собой тип прокси-сервера, который принимает HTTP(S) запросы и прозрачно распределяет их на один или несколько внутренних серверов.
Обратные прокси-серверы являются полезными, поскольку многие современные веб – приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, которые не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.
Вы можете использовать обратный прокси-сервер для предотвращения непосредственной доступности основных серверов приложений.
Они также могут быть использованы для распределения нагрузки от входящих запросов на нескольких различных серверах приложений, увеличивая производительность в масштабе и обеспечение отказоустойчивости. Они могут заполнить пробелы с функциями сервера приложений, которые они не предоставляют, такие как кэширование, сжатие а также шифрование SSL.
В этом учебном пособии вы настроите Apache в качестве основного обратного прокси – сервера с помощью расширения mod_proxy для перенаправления входящих подключений к одному или нескольким внутренним серверам, работающих в той же сети. Этот учебник используется простой бэкенд, написанный с Flask web framework, но вы можете использовать любой сервер данных, которые вы предпочитаете.
Следуя этому руководству, вам потребуется:
Модули, которые необходимы для использования 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-запросов. На следующем шаге мы создадим два самых основных внутренних сервера. Это поможет нам проверить, если конфигурация работает правильно.
Запуск некоторых простых внутренних серверов является простой способ проверить, что ваша конфигурация Apache работает должным образом . Здесь мы создадим два тестовых сервера, которые отвечают HTTP – запросам с печатью строки текста. Один сервер будет сказать Привет, мир!
Источник: https://andreyex.ru/centos-7/kak-ispolzovat-apache-v-kachestve-obratnogo-proksi-s-mod_proxy-na-centos-7/
Apache revers proxy и проброс IP клиента
by Денис Туляковin Web on 2016-07-17 | tags: Apache rpaf proxy remoteip | comments
Apache в роле реверсивного прокси сервера
Список модулей для проксирования
- mod_proxy – основной модуль Apache
- mod_proxy_ajp – для работы с протоколом AJP (Apache JServe Protocol version 1.3)
- mod_proxy_fcgi – для FastCGI
- mod_proxy_wstunnel – для сокетов (WS, WSS)
- mod_proxy_balancer – для балансировки
- mod_proxy_http – для протоколов HTTP/0.9, HTTP/1.0, и HTTP/1.1
- mod_proxy_hml – один из основных компонентов обратного прокси-сервера ProxyPassReverse
- mod_proxy_ftp – для протокола FTP
- mod_proxy_connect – для туннелирования SSL
- mod_cache – для кеширование
- mod_headers – для управление заголовками HTTP
- mod_deflate – для сжатие
- mod_remoteip – для передачи IP адреса user agent через прокси
Пример простого проксирования на внутренний серевр DMZ, Apache слушает на петле, порт 8080
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Order deny,allow Allow from all ServerAdmin [email protected] ServerName lib.example.org ServerAlias lib.example.org ProxyPreserveHost On ProxyRequests Off ProxyPass / http://lib.local:80/ ProxyPassReverse / http://lib.local:80/ LogLevel warn |
Пример для кластера
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
BalancerMember http://10.0.3.200:8080/ BalancerMember http://10.0.4.200:8080/ ProxyPass / balancer://mycluster ServerAdmin [email protected] ServerName lib.example.org ServerAlias lib.example.org ProxyRequests Off ProxyPass / balancer://mycluster ProxyPassReverse / balancer://mycluster LogLevel warn |
Пример SSL прокси
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Order deny,allow Allow from all SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /etc/ssl/example.org.crt SSLCertificateKeyFile /etc/ssl/example.org.key SSLProxyEngine on ProxyPreserveHost On ProxyRequests Off ProxyPass / https://backend.example.org ProxyPassReverse / https://backend.example.org ProxyPass / balancer://balancer_cluster_name LogLevel warn ErrorLog ${APACHE_LOG_DIR}/example.org-ssl-error.log TransferLog ${APACHE_LOG_DIR}/example.org-ssl-transfer.log CustomLog ${APACHE_LOG_DIR}/example.org-ssl-access.log combined |
Необходимые пакеты для SSL прокси
| sudo apt install libapache2-mod-proxy-html libapache2-mod-gnutls |
Apache за прокси сервером не важно за Nginx Varnish Apache или другим
Что надо сделать для того, что бы приезжал IP адрес user agent а не шлюза на котором установлен прокси.
| sudo apt install libapache2-mod-rpaf |
Пример настройки одного форума
| vi /etc/apache2/mods-enabled/rpaf.conf |
| RPAFenable On RPAFsethostname Off # Можно указать несколько (своих) адресов которые не должны попадать RPAFproxy_ips 127.0.0.1 10.0.3.1 # X-Forwarded-For to something of your choice: RPAFheader X-Real-IP |
У Apache есть свой модуль remoteip.
Но я его пока не пробовал использовать
Источник: http://www.dtulyakov.ru/apache_rproxy.html
Повышение уровня безопасности LAMP при помощи директивы Apache Proxy mod_proxy
Виртуальный хостинг с использованием различных пользовательских идентификаторов возможен
Ник Маинард (Nick Maynard)
Опубликовано 17.05.2007
Проект по разработке HTTP-сервера фонда Apache Software Foundation, известный как Apache, в настоящее время является преобладающим Web-сервером в Интернете, согласно статистическим данным он занимает более 60 процентов рынка.
Все больше и больше Apache используется как часть набора свободного программного обеспечения в конфигурации, известной как LAMP, Web-платформа, построенная на базе технологий с открытыми исходными кодами Linux®, Apache, MySQL и PHP. Из этой статьи вы узнаете о способе, позволяющем повысить безопасность установки LAMP путем использования модуля mod_proxy и нескольких внутренних серверов.
Я расскажу вам о достоинствах и недостатках такого подхода, и вы увидите пример конфигурации работающей установки.
PHP и Apache: проблемы безопасности
Одна из проблем, с которой сталкиваются администраторы LAMP — предоставление всех возможностей полной установки PHP и, в то же время, обеспечение безопасного окружения для всех пользователей системы.
Использование безопасного режима PHP — один из методов достижения этой цели, но это также может чрезмерно ограничить пользователей, и некоторые PHP-приложения просто не будут функционировать, когда включен этот режим.
Корень проблемы безопасности PHP лежит в том, как сконфигурировано большинство Apache-серверов. Поскольку большинство установок Apache работает под специальным пользовательским идентификатором www-data, весь пользовательский хостинг Web-сайта должен по умолчанию гарантировать, что файлы пользователей будут доступны для чтения этим пользователям.
Следовательно есть вероятность, что все пользовательские файлы, доступные через Web, будут доступны всем другим пользователям системы и могут подвергнуться атаке со стороны других, не имеющих отношения к данной системе. Положение становится даже более сложным, когда файлы или каталоги должны быть доступны для записи для пользователя www-data.
Вы можете отчасти избежать этой проблемы при запуске программ CGI, например, написанных с использованием популярных языков Perl и Python, используя механизм suEXEC.
Говоря коротко, suEXEC использует специальную промежуточную программу для выполнения программы CGI под пользовательским идентификатором, который является владельцем программы. (Ссылки на статьи с более подробным описанием см. в разделе Ресурсы.
) Это очень эффективный механизм, традиционно использовавшийся в течение многих лет.
Однако хостинг страниц PHP с использованием модуля mod_php выполняется как часть основного процесса Apache. Собственно, страницы PHP наследуют все мандаты процесса Apache, и поэтому любые выполняемые на файловой системе действия должны выполняться от имени пользователя www-data.
Запуск Apache с использованием различных пользовательских идентификаторов
Очевидное решение описанной выше проблемы — хостинг всех запросов для пользовательских доменов от копии Apache, которая имеет только этот пользовательский мандат.
Вы можете сконфигурировать Apache так, чтобы при запуске принимать любые пользовательские мандаты.
Это может решить проблему для несложных конфигураций, где каждому пользователю назначается индивидуальная комбинация IP адрес/порт, доступная через Интернет.
Для более сложных конфигураций, где IP-адреса пользуются большим спросом, этот метод не работает.
Вы можете использовать только виртуальный хостинг — метод, широко распространенный в установках Apache, где единственная копия Apache контролирует особую комбинацию IP адрес/порт.
Это предотвращает возможность хостинга множества доменов, принадлежащих множеству пользователей с одной и той же комбинации IP адрес/порт.
В Apache 2.0 вводится понятие мультипроцессорных модулей (MPM). Среди модулей, предоставляемых с пакетом Apache 2.
0, присутствует экспериментальный модуль perchild, позволяющий осуществлять виртуальный хостинг при множестве пользовательских идентификаторов путем назначения distributor-потока для комбинации IP адрес/порт и передачи запросов на satellite-потоки, выполняющиеся под индивидуальными пользовательскими мандатами.
К сожалению, perchild оставался экспериментальным и функционировал только в случае удачи и в конце концов был удален из официального Apache, начиная с версии 2.2.
Перед этим, понимая, что необходимость в наличии стабильного функционирующего perchild-подобного модуля сохраняется, сообщество Apache начало работу по созданию модулей MPM, способных заполнить образовавшийся пробел. Разработка MetuxMPM и его подпроцесса, созданного через fork, peruser, явилась продолжением работ по достижению этой цели. (Ссылки на статьи с описанием модулей MetuxMPM и peruser см. в разделе Ресурсы).
Решение: mod_proxy
Несмотря на то, что нет официального Apache MPM, пригодного для непосредственного предоставления виртуального хостинга с использованием различных пользовательских идентификаторов, вы все же можете создать систему Apache, работающую таким образом, путем разумного конфигурирования и администрирования. Основное понятие метода — использование модуля mod_proxy, который в числе других функций позволяет Apache перенаправлять запросы страниц на другие серверы и передавать ответ обратно клиенту, от которого поступил запрос.
Листинг 1. Пример конфигурации обратного прокси для переадресации основного запроса
ProxyRequests Off ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.
com/bar
Код в Листинге 1 — простой пример, в котором показано перенаправление запроса любой страницы хоста /foo на соответствующую страницу, размещаемую на http://foo.example.com/bar. Например, страница /foo/index.
htm будет перенаправлена на http://foo.example.com/bar/index.htm. Вы можете использовать этот принцип для решения проблемы.
Пример сценария
Рассмотрим сценарий, в котором администратор Apache должен предоставить хостинг для двух доменов, принадлежащих двум разным клиентам. Один клиент — недавно созданная онлайн компания, которая беспокоится об онлайн безопасности.
Другой является частным лицом. Он не заботится о безопасности сайта и известно, что он загружает на свой сайт небезопасный код. Учитывая эти моменты, администратор Apache должен предпринять действия для изоляции этих сайтов друг от друга.
Таким образом, у администратора имеется два домена: www.startup.tld, принадлежащий недавно созданной онлайн компании (идентификатор пользователя startup), и www.reckless.tld, принадлежащий частному лицу (идентификатор пользователя nimrod). Для решения проблемы администратор принял решение использовать mod_proxy.
Администратор выдал каждому пользователю его собственную копию Apache, запущенную под его собственным ID на приватной комбинации IP-адрес/порт, и использовал решение mod_proxy для предоставления доступа к обоим доменам через наружный сервер, запущенный под ID www-data на публичной комбинации IP-адрес/порт.
Законченный сценарий показан на Рисунке 1.
Рисунок 1. Образец сценария
Кликните, чтобы увидеть увеличенное изображение
Рекомендуемые версии Apache
Для каждого элемента конфигурации в нашем образце приложения администратор Apache должен использовать версии Apache, перечисленные в Таблице 1.
Таблица 1. Версии Apache, использованные в примере приложения
| Внешний сервер | Apache 2, выполняющий MPM worker или MPM event | Apache 2 добавляет важное расширение для модуля mod_proxy. MPM worker и MPM event выполняются в виде thread'ов и помогают уменьшить непроизводительный расход памяти на внешнем сервере. |
| Внутренние серверы | Apache 1.3, или Apache 2, выполняющие prefork MPM | Администратор Apache должен осознавать, что модуль PHP не должен запускаться под thread-окружением. Эти два варианта предлагают основанные на порождении процессов окружения для модуля PHP. |
Конфигурирование внутренних Apache instance
Фрагменты Листингов 2 и 3 иллюстрируют важные моменты конфигурирования, отличающиеся от стандартной конфигурации Apache. Их необходимо добавлять в случае необходимости. Так, в пример конфигурации не включена функциональность PHP.
Листинг 2. Конфигурация Apache для недавно созданной онлайн компании
# Stuff every Apache configuration needs
ServerType standalone
LockFile /var/lock/apache/accept.startup.lock
PidFile /var/run/apache.startup.pid ServerName necessaryevil.startup.tld
DocumentRoot “/home/startup/web” # Essential modules
LoadModule access_module /usr/lib/apache/1.3/mod_access.
so # Which user to run this Apache configuration as
User startup
Group startup # This must be off else the host isn't passed correctly
UseCanonicalName Off # The IP/port combination to listen on
Listen 127.0.0.2:10000 # Using name-based virtual hosting allows you to host multiple sites per IP/port combo
NameVirtualHost 127.0.0.2:10000 ServerName www.startup.
tld # You can add aliases so long as the facade server is aware of them! ServerAlias startup.tld DocumentRoot “/home/startup/web/www.startup.tld” Options Indexes FollowSymLinks MultiViews ExecCGI Includes AllowOverride All Order allow,deny Allow from all # Stuff every Apache configuration needs
ServerType standalone
LockFile /var/lock/apache/accept.nimrod.
lock
PidFile /var/run/apache.nimrod.pid ServerName necessaryevil.nimrod.tld
DocumentRoot “/home/nimrod/web” # Essential modules
LoadModule access_module /usr/lib/apache/1.3/mod_access.
so # Which user to run this Apache configuration as
User nimrod
Group nimrod # This must be off else the host isn't passed correctly
UseCanonicalName Off # The IP/port combination to listen on
Listen 127.0.0.2:10001 # Using name-based virtual hosting allows you to host multiple sites per IP/port combo
NameVirtualHost 127.0.0.2:10001 ServerName www.reckless.
tld # You can add aliases so long as the facade server is aware of them! ServerAlias reckless.tld DocumentRoot “/home/nimrod/web/www.reckless.tld” Options Indexes FollowSymLinks MultiViews ExecCGI Includes AllowOverride All Order allow,deny Allow from all
В Листинге 4 показана конфигурация для внешнего instance Apache.
Листинг 4. Конфигурация Apache для внешнего instance Apache
# Stuff every Apache configuration needs
LockFile /var/lock/apache/accept.www-data.lock
PidFile /var/run/apache.www-data.pid ServerName necessaryevil.facade.server
DocumentRoot “/home/www-data” # Essential modules
LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.
so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.
so # Which user to run this Apache configuration as
User www-data
Group www-data # These must be set else the host isn't passed correctly
UseCanonicalName Off
ProxyVia On
ProxyRequests Off
# This must also be set, though it's only an option in Apache2
ProxyPreserveHost On # The IP/port combination to listen on
Listen 9.
20.1.1:80 # Using name-based virtual hosting allows you to host multiple sites per IP/port combo
NameVirtualHost 9.20.1.1:80 # Configuration to forward requests for startup.tld
ServerName www.startup.tld ServerAlias startup.tld ProxyPass / http://127.0.0.2:10000/ ProxyPassReverse / http://127.0.0.
2:10000/ ProxyPassReverse / http://www.startup.tld:10000/ ProxyPassReverse / http://startup.tld:10000/
# Configuration to forward requests for reckless.tld
ServerName www.reckless.tld ServerAlias reckless.tld ProxyPass / http://127.0.0.2:10001/ ProxyPassReverse / http://127.0.0.2:10001/ ProxyPassReverse / http://www.reckless.
tld:10001/ ProxyPassReverse / http://reckless.tld:10001/
Здесь важно отметить директиву ProxyPreserveHost. Эта директива появилась, начиная с версии Apache 2. Она решает некоторые проблемы перенаправления на внутренние серверы корректных заголовков HTTP. Настоятельно рекомендуется использовать Apache 2 instance в качестве внешнего сервера.
Запуск примера конфигурации
Все конфигурации выполняет пользователь root. Apache берет привилегии, требуемые конфигурационным файлом для всех связанных с хостингом процессов. В Листинге 5 показано, как это запустить.
Листинг 5. Запуск серверов примера
/usr/sbin/apache -f /etc/apache/startup.tld.conf
/usr/sbin/apache -f /etc/apache/nimrod.tld.conf
/usr/sbin/apache2 -f /etc/apache2/facade.tld.conf
Крайне важно заметить, что метод, описанный в этой статье, не будет работать с доменами, требующими SSL-соединений. Это происходит потому, что протокол SSL не позволяет виртуальный хостинг доменов.
Вследствие этого ограничения любой SSL-хостинг должен осуществляться способом, когда каждый домен SSL имеет хостинг на своей собственной комбинации IP/порт. Это ограничение касается всех конфигураций Apache, не только тех, которые используют это решение. Тем не менее вы можете запускать домены SSL под идентификатором пользователя их владельца.
Заключение
Из этой статьи вы узнали об использовании возможностей модуля Apache mod_proxy для построения окружения, состоящего из внешнего сервера, пересылающего запросы на два внутренних сервера. Такой подход позволяет системным администраторам исключить возможные риски, связанные с безопасностью, и в то же время сохранять гибкость, предоставляемую такими инструментами, как PHP.
Ресурсы для скачивания
Источник: https://www.ibm.com/developerworks/ru/library/wa-lampsec/
Обратное проксирование Apache 2.4 в Nginx и настоящий IP-адрес клиента в логах Apache
Сегодня у нас задача настроить обратное проксирование службы Apache с помощью Nginx. Итак приступим.
Создаем файл конфигурации Nginx для нашего сайта, который нужно проксировать
vim /etc/nginx/sites-available/conf24.net.conf
вот с таким содержимым:
server { listen 80; server_name conf24.net www.conf24.net; access_log off; location / { proxy_pass http://127.0.0.1:81; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Server-Address $server_addr; # proxy_set_header X-Forwarded-For $remote_addr; client_max_body_size 10m; client_body_buffer_size 128k; client_body_temp_path /tmp; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_send_lowat 12000; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_temp_path /tmp; } }
Активируем виртуальный хост conf24.net в Nginx:
sudo ln -s /etc/nginx/sites-available/conf24.net /etc/nginx/sites-enabled
Создаем файл конфигурации виртуального хоста conf24.net в Apache:
[email protected]:~# vim /etc/apache2/sites-available/conf24.net.conf
Создаем файл виртуального хоста conf24.net в Apache cледующего содержимого:
ServerAdmin [email protected] DocumentRoot /home/hosting/sites/conf24.net/public_html ServerName conf24.net ServerAlias www.conf24.net Options Indexes FollowSymLinks MultiViews AllowOverride all Require all granted Include /etc/phpmyadmin/apache.conf ErrorLog “/home/hosting/sites/conf24.net/log/conf24.net-error.log” CustomLog “/home/hosting/sites/conf24.net/log/conf24.net-access.log” common
Активируем виртуальный хост conf24.net в Apache:
sudo a2ensite conf24.net.conf
Необходимо активировать и настроить модуль Apache remoteip для того, чтобы он понимал проброс IP-адреса клиента через прокси-сервер Nginx, иначе в логах будет виден адрес клиента 127.0.0.1. Для этого воспользуемся модулем remoteip:
a2enmod remoteip
Создадим конфигурацию для модуля remoteip
vim /etc/apache2/conf-available/remoteip.conf
вот с таким содержимым:
RemoteIPHeader X-Forwarded-For RemoteIPTrustedProxy 127.0.0.1 213.111.122.3 RemoteIPInternalProxy 127.0.0.1 213.111.122.3
Подправим формат логов в файле /etc/apache2/apache2.conf, заменив %h на %a, к следующему виду:
LogFormat “%v:%p %a %l %u %t “%r” %>s %O “%{Referer}i” “%{User-Agent}i”” vhost_combined LogFormat “%a %l %u %t “%r” %>s %O “%{Referer}i” “%{User-Agent}i”” combined LogFormat “%a %l %u %t “%r” %>s %O” common LogFormat “%{Referer}i -> %U” referer LogFormat “%{User-agent}i” agent
Подправим настройки интерфейсов и портов Apache в файле /etc/apache2/ports.conf, чтобы он работал только на localhost, к такому виду:
Listen 127.0.0.1:81 Listen 127.0.0.1:8443 Listen 127.0.0.1:8443
Для того, чтобы изменения вступили в силу необходимо перезапустить службы:
service nginx restart service apache2 restart
Проверяем:
[email protected]:~# netstat -ntlp | grep apache2 tcp 0 0 127.0.0.1:81 0.0.0.0:* LISTEN 32413/apache2 tcp 0 0 127.0.0.1:8443 0.0.0.0:* LISTEN 32413/apache2 [email protected]:~# netstat -ntlp | grep nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 32441/nginx -g daem tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 32441/nginx -g daem tcp6 0 0 :::80 :::* LISTEN 32441/nginx -g daem
На этом с поставленой задачей мы справились.
Спасибо за уделенное время на прочтение статьи!
Если возникли вопросы, задавайте их в комментариях.
Источник: http://blog.sedicomm.com/2017/02/26/nginx-as-reverse-proxy-for-apache-remoteip/
Настраиваем nginx как reverse proxy для Apache
Эта статья является продолжением предыдущей статьи (в которой я рассказывал о настройке небольшого LAMP-хостинга на VPS под управлением Debian).
Зачем нужен еще и nginx — можно почитать здесь и в других источниках.
Программа на сегодня такая:
- Сначала делаем, чтобы все запросы шли через nginx (делаем тупой прокси)
- Изучаем как отдавать статичный контент в обход Апача
- Настраиваем ограничение нагрузки
В заключение я немного порассуждаю о возможных проблемах и подводных камнях.
Вставляем nginx перед Apache
apt-get install libapache2-mod-rpaf nginx
Теперь надо перевесить Апач на порт 81 и спрятать от внешнего мира. В /etc/apache2/ports.conf меняем:
NameVirtualHost *:81 Listen 127.0.0.1:81
Во всех конфигах внутри /etc/apache2/sites-available тоже меняем порт:
Теперь переходим в /etc/nginx.
Удаляем «заводской» сайт:
- sites-available/default
- sites-enabled/default
Вместо него добавляем наш собственный:
touch /etc/nginx/sites-available/apache_proxy
Внутрь помещаем:
server { listen 80 default; server_name localhost; location / { proxy_pass ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } }
Сохраняем и делаем его «enabled»:
ln -s /etc/nginx/sites-available/apache_proxy /etc/nginx/sites-enabled/apache_proxy
Линк приходится создавать руками — утилит вроде a2ensite тут к сожалению нет.
Перезапускаем сервера:
/etc/init.d/apache2 restart /etc/init.d/nginx restart
После всех этих манипуляций сайты должны продолжить работать без изменений.
Статика в обход Апача
Пора получить от nginx какую-нибудь пользу. Вносим вот такие изменения в недавно созданный файл apache_proxy:
server { listen 80 default; server_name localhost; location /**static**/domain1.com/ { internal; alias /home/user1/domain1.com/www; expires 24h; } location / { if ($http_host = domain1.com) { set $my_static_location domain1.com; } if ($my_static_location) { rewrite ^(.*.(css|js|png|jpg|gif))$ /**static**/$my_static_location/$1; } proxy_pass ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } }
Применяем:
/etc/init.d/nginx reload
Теперь статичные файлы должны отдаваться напрямую. Убедиться в этом можно через dev tools браузера: в заголовках ответа появилось max-age=86400 и исчез ETag, который генерировал Апач.
Список расширений (в директиве rewrite) можно дополнить по собственному желанию: doc, xls, mp3, flv, ico, txt, html, xml, pdf, zip и многое другое.
Важным нюансом является то, что процесс nginx должен иметь доступ к отдаваемым файлам (на чтение конечно). Если вы в целях безопасности делаетеchmod 0750 домашним директориям пользователей, то это создаст препятствия.
Теперь пара слов о конфиге. «Легко видеть», что для каждого домена, для которого мы хотим отдавать статику, заводится internal location, указывающий на web-root. Далее идет выбор этого location-а и перекидывание на него запросов за статикой.
Такой подход позволяет сохранять конфиг компактным — не надо создавать параллельные конфигурации серверов в Apache и nginx. В то же время не теряется гибкость: вы сами решаете, для каких доменов вам это надо, и у вас есть свобода в настройке путей, кеширования и других фишек для каждого домена отдельно.
Ограничение нагрузки
limit_req — еще одна плюшка, которую может нам дать nginx:
limit_req_zone $pid zone=proxy_global:64k rate=10r/s; server { listen 80 default; server_name localhost; location /**static**/domain1.com/ { internal; alias /home/user1/domain1.com/www; expires 24h; } location / { if ($http_host = domain1.com) { set $my_static_location domain1.com; } if ($my_static_location) { rewrite ^(.*.(css|js|png|jpg|gif))$ /**static**/$my_static_location/$1; } proxy_pass ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; limit_req zone=proxy_global burst=100; } }
Внесенные изменения ограничивают нагрузку на Апач до 10 запросов в секунду.burst=100 означает, что «неуспевшие» выстраиваются в очередь, но когда длина очереди перевалит за 100, их начнут отстреливать (HTTP 503 Service Unavailable).
Числа, разумеется, надо подбирать в зависимости от нагрузки и мощности сервера.
Обратите внимание, что при описании зоны я использовал $pid вместо «классического» $binary_remote_addr. Таким образом, нагрузка ограничивается глобально, а не для каждого пользователя отдельно.
Не знаю, защитит ли такая мера ваш любимый VPS от DDoS-атак, но завалить путем зажатия F5 его станет сложнее.
Возможные проблемы
Теперь порассуждаем о возможных обратных сторонах медали.
Файлы, которые nginx будет отдавать напрямую, отбираются достаточно примитивно и прямолинейно — по расширению файла. И здесь кроются грабли:
- Если файл находится в папке, доступ к которой ограничен средствами .htaccess, то очевидно эти ограничения перестанут работать, т.к. nginx про этот .htaccess ничего не знает.
- При использовании mod_rewrite за статичным с виду урлом может скрываться динамика: например, /something.json, /something.xml и something.html, отдающие одинаковый контент в разных форматах, или перехват запросов за картинками с целью встраивания их в html-рамочку. Вариантов полно.
Именно поэтому отдача статики не включена по умолчанию, а прописывается по условию. В более сложных сценариях придется отказаться и от центрального$my_static_location, тщательно подбирая регулярные выражения для rewrite-правил под конкретный случай.
Теперь вы предупреджены, а как известно предупрежден значит вооружен. Так что используйте nginx во благо, а не во вред!
Источник: http://csslike.me/nastraivaem-nginx-kak-reverse-proxy-dlya-apache/
Virtualmin, Apache и обратный прокси-сервер Nginx
Я хотел иметь возможность настроить обратный прокси с nginx и apache, но продолжать использовать Virtualmin GPL для управления моими доменами. Единственная причина, по которой я хотел получить обратный прокси, – это то, что в нескольких доменах, которые я размещаю, используется очень большое количество изображений.
Мне нужен эффективный способ обработки этих изображений, так как apache использует тот же процесс для обработки всего для пользователя домена, и, следовательно, его объем памяти продолжает расти, пока процесс не был убит. Таким образом, у меня были процессы с использованием 150 + MB памяти только для обслуживания изображения.
Во всяком случае, Virtualmin не поддерживает эту конфигурацию из коробки, поэтому мне пришлось немного подделать ???? Я полагаю, что поделился бы тем, как я это делал.
Немного фона. Обычно с этой настройкой у вас будет доступ к nginx по всему миру, а apache доступен только локальному хосту.
Но если вы планируете продолжать разрешать Virtualmin управлять своими доменами, вы не сможете этого сделать.
Если вы не хотите вручную редактировать свои файлы конфигурации каждый раз, когда Virtualmin создает домен. Поэтому вместо этого мне пришлось оставить оба открытыми для мира.
Установка / настройка nginx
Итак, предположим, что у вас есть полностью функционирующие серверы Virtualmin и Apache2, давайте установим nginx. Я использую Ubuntu 10.04 LTS под Linode, а сервер nginx, доступный в его ppa, немного стар. Итак, начнем получить последнюю версию из ppa nginx:
sudo add-apt-repository ppa: nginx / stable sudo apt-get update sudo apt-get install nginx
Теперь создайте файл /etc/nginx/proxy.conf и добавьте к нему следующее:
proxy_redirect off; proxy_set_header Host $ host; proxy_set_header X-Real-IP $ remote_addr; proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffers 32 4k;
Это стандартные настройки. Возможно, вам придется корректировать номера, чтобы они соответствовали потребностям вашего сайта.
Откройте /etc/nginx/nginx.conf и отредактируйте его, чтобы он соответствовал следующему (настройте на потребности вашего сервера)
пользовательские www-data www-data; worker_processes 2;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
Мероприятия { worker_connections 1024; # multi_accept on;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0; keepalive_timeout 65;
tcp_nodelay on;
gzip on;
gzip_disable “MSIE [1-6]. (?!. * SV1)”;
include /etc/nginx/conf.d/*.conf; включить / etc / nginx / sites-enabled / *;
}
Я создал / отредактировал файл хоста по умолчанию для обработки любых доменов, у которых нет определенного файла конфигурации:
/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию
Источник: https://websetnet.net/ru/virtualmin-apache-and-nginx-reverse-proxy/
Как использовать Apache в качестве обратного прокси с mod_proxy на Debian 8
Обратный прокси – сервер представляет собой тип прокси – сервера, который принимает HTTP (S) запросы и прозрачно распределяет их на один или несколько внутренних серверов.
Обратные прокси – серверы являются полезными, поскольку многие современные веб – приложения обработки входящих запросов HTTP с использованием серверов приложений бэкэнда, не должны быть доступны пользователям напрямую и часто поддерживают только элементарные функции HTTP.
Вы можете использовать обратный прокси-сервер для предотвращения от непосредственного доступа этих основных серверов приложений.
Он также может быть использован для распределения нагрузки от входящих запросов на нескольких различных серверах приложений, увеличивая производительность в масштабе и обеспечение отказоустойчивости. Он может заполнить пробелы с функциями сервера приложений, которые не предлагают, такое как кэширование, сжатие или шифрование SSL.
В этом учебном пособии вы настроите Apache в качестве основного обратного прокси – сервера с помощью расширения mod_proxy для перенаправления входящих подключений к одному или нескольким внутренним серверам, работающих в той же сети. Этот учебник использует простой бэкенд написанный с Flask web framework, но вы можете использовать любой сервер данных, который вы предпочитаете.
Следуя этому руководству, вам потребуется:Apache имеет множество модулей в комплекте с ним, которые доступны, но не включены в новой установки. Во-первых, нам нужно включить те, которые мы будем использовать на этом уроке.
Модуль, который нам нужен, это mod_proxy и некоторые из его дополнительных модулей, которые расширяют его функциональные возможности для поддержки различных сетевых протоколов. В частности, мы будем использовать:
- mod_proxy, главный прокси-модуль Apache модуль для перенаправления соединений; он позволяет Apache выступать в качестве шлюза для основных серверов приложений.
- mod_proxy_http, который добавляет поддержку проксирования HTTP соединений.
- mod_proxy_balancer и mod_lbmethod_byrequests, добавляет новые функции балансировки нагрузки для нескольких внутренних серверов.
Чтобы включить эти четыре модуля, необходимо выполнить следующие команды в последовательности.sudo a2enmod proxysudo a2enmod proxy_httpsudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests
Чтобы эти изменения вступили в силу, перезапустите Apache.sudo systemctl restart apache2 Apache теперь готов действовать в качестве обратного прокси-сервера для HTTP-запросов. В следующем (по желанию) шаге, мы создадим два самых основных внутренних сервера. Это поможет нам проверить, что конфигурация работает правильно, но если у вас уже есть собственное приложение(я) бэкэнд, вы можете перейти к шагу 3.
Запуск некоторых простых внутренних серверов является простой способ проверить, что ваша конфигурация Apache работает должным образом. Здесь мы сделаем два тестовых сервера, которые отвечают HTTP – запросам с печатью строки текста. Один сервер скажет 'Привет , мир! а другой скажет 'AndreyEx мир! ,
[gn_box title=”Примечание” box_color=”#a1e1ff”]В не-испытательных установках, Backend серверы, как правило, возвращают один и тот же тип содержимого. Тем не менее, для этого теста, в частности, два сервера возвращают различные сообщения, что позволяет легко проверить, что механизм балансировки нагрузки использует оба.[/gn_box]
Flask является microframework Python для создания веб – приложений. Мы используем Flask для создания тестовых серверов, так как основное приложение требует всего несколько строк кода. Вам не нужно знать Python, чтобы настроить их.Обновление списка пакетов в первую очередь.sudo apt-get update Затем установите pip, рекомендуемый менеджер пакетов Python.sudo apt-get -y install python3-pip Используйте pip чтобы установить Flask.sudo pip3 install flask Теперь, когда все необходимые компоненты установлены, начните с создания нового файла, который будет содержать код для первого сервера бэкэнда в домашнем каталоге текущего пользователя.nano ~/backend1.py Скопируйте следующий код в файл, а затем сохраните и закройте его.
~ / Backend1.py
from flask import Flaskapp = Flask(__name__)@app.route('/')def home(): return 'Hello world!'
Первые две строки инициализации фреймворка Flask. Существует одна функция, home(), которая возвращает строку текста ( Hello world!). @app.route('/') над home() функции говорит Flask использовать home()'s возвращаемое значение в качестве ответа на HTTP – запросы, направленных на /корневой URL приложения.Второй сервер Бэкэнд точно так же, как и первый, кроме возвращения другой строчки текста, поэтому начните путем дублирования первого файла.cp ~/backend1.py ~/backend2.py Откройте вновь скопированный файл.nano ~/backend2.py
Измените сообщение , которое будет возвращено из Привет , мир! в AndreyEx мир! А затем сохраните и закройте файл.
~ / Backend2.py
from flask import Flaskapp = Flask(__name__)
@app.route('/')
def home():
return 'AndreyEx world!'
Используйте следующую команду, чтобы запустить первый фоновый сервер на порту 8080. Это также перенаправляет вывод Flask к /dev/null.
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/
Это выведет AndreyEx мир!
[gn_box title=”Примечание” box_color=”#a1e1ff”]Для того, чтобы закрыть оба тестовых сервера после того, как вы больше не нуждаетесь в них, и когда вы закончите этот урок, вы можете просто выполнить killall flask.[/gn_box]
На следующем шаге мы будем изменять конфигурационный файл Apache, чтобы включить его использование в качестве обратного прокси-сервера на Debian 8.
В этом разделе мы настроим Apache виртуальный хост по умолчанию, чтобы служить в качестве обратного прокси-сервера для одного сервера бэкэнд или массив с балансировкой нагрузки внутренних серверов.[gn_box title=”Примечание” box_color=”#a1e1ff”]В этом руководстве мы применяем настройки на уровне виртуального хоста. При установке по умолчанию Apache, есть только один включен, виртуальный хост по умолчанию. Тем не менее, вы можете использовать все эти фрагменты конфигурации в других виртуальных хостах.Если ваш сервер работает на Apache как HTTP и HTTPS – сервер, ваша обратная конфигурация прокси – сервера должна быть размещена как в HTTP и HTTPS виртуальных хостах.[/gn_box]
Откройте файл по умолчанию Apache конфигурации, используя nano или ваш любимый текстовый редактор.
sudo nano /etc/apache2/sites-available/000-default.conf
Внутри этого файла вы найдете блок, начиная с первой строки. В первом примере ниже показано, как настроить этот блок для обратного прокси – сервера для одного сервера бэкэнда, а второй устанавливает балансировкой нагрузки обратного прокси для нескольких внутренних серверов.
Заменить все содержимое внутри блока VirtualHost со следующим, ваш файл конфигурации должен выглядит следующим образом:
/etc/apache2/sites-available/000-default.conf
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
Если вы следовали вместе с серверами например, на шаге 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 apache2
Теперь, если вы получаете доступ к http://your_server_ip через веб – браузер, вы увидите ответ сервера бэкэнда вместо стандартной страницы приветствия Apache. Если вы следовали инструкциям Шаг 2, то вы будете видеть Привет мир!
Если у вас есть несколько внутренних серверов, хороший способ распределить трафик между ними, когда проксирование заключается в использовании балансировки нагрузки функции mod_proxy.
Замените все содержимое внутри блока VirtualHost следующим, так что ваш файл конфигурации выглядит следующим образом:
/etc/apache2/sites-available/000-default.conf
BalancerMember http://127.0.0.1:8080
BalancerMember http://127.0.0.1:8081
ProxyPreserveHost On
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
Конфигурация аналогична предыдущей, но вместо указания одного сервера бэкэнд напрямую, мы использовали дополнительный блок Proxy для определения нескольких серверов. Блок с именем balancer://mycluster (имя может быть свободно изменено) и состоит из одного или нескольких BalancerMember, которые определяют, лежащие в основе адреса бэкенда сервера. ProxyPass и директива ProxyPassReverse используют пул балансировки нагрузки с именем mycluster вместо конкретного сервера.
Если вы следовали примеру на шаге 2, используя 127.0.0.1:8080 и 127.0.0.1:8081 для директивы BalancerMember, как написано в блоке выше. Если у вас есть свои собственные серверы приложений, используйте их адреса вместо этих.
Чтобы изменения вступили в силу, перезапустите Apache.sudo systemctl restart apache2
Зайдите в веб – браузере по адресу 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.
Взято на сайте: Как использовать Apache в качестве обратного прокси с mod_proxy на Debian 8
Источник: http://andreyexru.blogspot.com/2017/02/apache-modproxy-debian-8.html
Загрузка...
