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

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

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

Шаг 1 – Введение в необходимые модули Apache

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

• mod_proxy, глав­ный прок­си-модуль моду­ля Apache для пере­на­прав­ле­ния соеди­не­ний; кото­рый поз­во­ля­ет Apache высту­пать в каче­стве шлю­за для основ­ных сер­ве­ров приложений.
• mod_proxy_http, добав­ля­ет под­держ­ку прок­си­ро­ва­ния HTTP соединений.
• mod_proxy_balancer и mod_lbmethod_byrequests, что добав­лять новые функ­ции балан­си­ров­ки нагруз­ки для несколь­ких внут­рен­них серверов.

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

Выво­дом коман­ды будет спи­сок всех вклю­чен­ных моду­лей Apache.

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

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

Для того, что­бы изме­не­ния всту­пи­ли в силу, сохра­ни­те файл и пере­за­пу­стить Apache.

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

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

Запуск неко­то­рых про­стых внут­рен­них сер­ве­ров явля­ет­ся про­стой спо­соб про­ве­рить, что ваша кон­фи­гу­ра­ция Apache рабо­та­ет долж­ным обра­зом . Здесь мы созда­дим два тесто­вых сер­ве­ра, кото­рые отве­ча­ют HTTP – запро­сам с печа­тью стро­ки тек­ста. Один сер­вер будет ска­зать При­вет, мир! а дру­гой ска­жет Мой мир!

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

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

При­ме­ча­ние

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

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

Пример 1 – Обратное проксирование сервера. Один бэкэнд.

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

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

Есть три дирек­ти­вы здесь:

• ProxyPreserveHost пере­да­ют Apache ори­ги­наль­ный Host заго­ло­вок на внут­рен­ний сер­вер. Это полез­но, так как это дела­ет сер­вер бэкенд осо­зна­ный адрес, исполь­зу­е­мый для досту­па к приложению.
• ProxyPass глав­ная дирек­ти­ва кон­фи­гу­ра­ции прок­си. В этом слу­чае, он ука­зы­ва­ет, что все в кор­не­вом URL ( /) дол­жен быть отоб­ра­жен на внут­рен­ний сер­вер по ука­зан­но­му адре­су. Напри­мер, если Apache полу­ча­ет запрос на /example, он будет под­клю­чать­ся и вер­нет ответ на ори­ги­наль­ный кли­ент. http://your_backend_server/example
• ProxyPassReverse дол­жен иметь ту же кон­фи­гу­ра­цию, что и ProxyPass. Это гово­рит Apache, что­бы изме­нить заго­лов­ки отве­та от сер­ве­ра бэк­эн­да. Это гаран­ти­ру­ет, что если внут­рен­ний сер­вер воз­вра­ща­ет заго­ло­вок пере­на­прав­ле­ния место­по­ло­же­ния, бра­у­зер кли­ен­та будет пере­на­прав­лен на адрес прок­си – сер­ве­ра и не адре­са сер­ве­ра, бэкен­да, кото­рый не будет рабо­тать, как предполагалось.

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

Теперь, если вы полу­ча­е­те доступ к http://your_server_ip через веб – бра­у­зер, вы уви­ди­те ответ сер­ве­ра бэк­эн­да вме­сто стан­дарт­ной стра­ни­цы при­вет­ствия Apache. Если вы сле­до­ва­ли инструк­ци­ям Шаг 2, то вы буде­те видеть При­вет мир!

Пример 2 – балансировки нагрузки между несколькими серверами Backend

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

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

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

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

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

Зай­ди­те в веб – бра­у­зе­ре по адре­су http://your_server_ip, вы уви­ди­те бэк­энд сер­ве­ра вме­сто стан­дарт­ной стра­ни­цы Apache. Если вы сле­до­ва­ли инструк­ци­ям на Шаге 2, обно­ви­те стра­ни­цу несколь­ко раз дол­жен пока­зать При­вет, мир! и Мой мир!, То есть обрат­ный прок­си – сер­вер рабо­тал и балан­си­ров­ка нагруз­ки меж­ду обо­и­ми серверами.

Вывод

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.