Zum Inhalt springen

Apache/HTTP/Reverse proxy: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
K Textersetzung - „line>“ durch „line copy>“
 
(70 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Apache-Reverse-Proxy'''
'''Apache/HTTP/Reverse proxy''' - Apache-[[Reverse-Proxy]]
[[Datei:Reverse-Proxy.png|mini|Typische Implementierung]]


== Hintergrund ==
== Beschreibung ==
* Apache kann als Reverse-Proxy verwendet werden, um
; HTTP(S)-Anforderungen an andere Computer weiterleiten
* HTTP / HTTPS-Anforderungen an andere Computer weiterzuleiten
Apache kann als [[Reverse-Proxy]] verwendet werden


; Vorteile
=== Vorteile ===
{| class="wikitable options bing"
{| class="wikitable options big"
|-
| [[Sicherheit]] || Apache-Instanz kann in eine DMZ gestellt und der Welt ausgesetzt werden, während die Webserver ohne Zugriff auf die Außenwelt dahinter sitzen können
|-
| [[Last reduzieren]] || Sie können die Last auf den Webservern mit verschiedenen Methoden reduzieren, z. B. Web-Caching am Proxy, Lastausgleich und Ablenkung des Datenverkehrs für ungültige Anforderungen
|-
|-
| Sicherheit || Apache-Instanz kann in eine DMZ gestellt und der Welt ausgesetzt werden, während die Webserver ohne Zugriff auf die Außenwelt dahinter sitzen können
| [[Failover]] ||
|}
 
Apache httpd (wie auch die meisten anderen Webserver) ist nicht nur ein "einfacher" Webserver, der Endbenutzern statische und dynamische Inhalte bereitstellt, sondern kann auch als Reverse-Proxy-Server fungieren, der auch als "Gateway"-Server bezeichnet wird
 
In solchen Szenarien generiert oder hostet httpd selbst keine Daten, sondern der Inhalt wird von einem oder mehreren Backend-Servern bezogen, die normalerweise keine direkte Verbindung zum externen Netzwerk haben
* Wenn httpd eine Anfrage von einem Client erhält, wird die Anfrage selbst an einen dieser Backend-Server ''weitergeleitet'', der dann die Anfrage bearbeitet, den Inhalt generiert und diesen Inhalt dann an httpd zurücksendet, das dann die eigentliche HTTP-Antwort an den Client generiert
 
 
Es gibt zahlreiche Gründe für eine solche Implementierung, aber im Allgemeinen sind die typischen Gründe Sicherheit, Hochverfügbarkeit, Lastverteilung und zentralisierte Authentifizierung/Autorisierung
{| class="wikitable float"
! Verwandte Module !! Verwandte Anweisungen
|-
|-
| Last reduzieren || Sie können die Last auf den Webservern mit verschiedenen Methoden reduzieren, z. B. Web-Caching am Proxy, Lastausgleich und Ablenkung des Datenverkehrs für ungültige Anforderungen
|
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html mod_proxy]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html mod_proxy_balancer]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy_hcheck.html mod_proxy_hcheck]
|
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]
* [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancermember BalancerMember]
|}
|}
* Bei diesen Implementierungen ist es von entscheidender Bedeutung, dass das Layout, das Design und die Architektur der Backend-Infrastruktur (die Server, die die Anfragen tatsächlich bearbeiten) isoliert und von außen geschützt sind
* Für den Client ist der Reverse-Proxy-Server ''die'' einzige Quelle für alle Inhalte
== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>
=== Einfaches Reverse-Proxying ===
Die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]-Direktive legt die Zuordnung eingehender Anfragen zum Backend-Server (oder einem Server-Cluster, der als <tt>Balancer</tt>-Gruppe bezeichnet wird) fest
Im einfachsten Beispiel werden alle Anfragen (<tt>"/"</tt>) an ein einzelnes Backend weitergeleitet:
<syntaxhighlight lang="apache" highlight="0" line copy>
ProxyPass "/" "https://www.example.com/"
</syntaxhighlight>
Um sicherzustellen, dass die vom Backend generierten <tt>Location:</tt>-Header so geändert werden, dass sie auf den Reverse-Proxy verweisen, anstatt auf sich selbst, ist die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse ProxyPassReverse]-Direktive am häufigsten erforderlich:
<syntaxhighlight lang="apache" highlight="0" line copy>
ProxyPass "/" "https://www.example.com/"
ProxyPassReverse "/" "https://www.example.com/"
</syntaxhighlight>
Nur bestimmte URIs können über einen Proxy weitergeleitet werden, wie in diesem Beispiel gezeigt
<syntaxhighlight lang="apache" highlight="0" line copy>
ProxyPass "/images" "https://www.example.com/"
ProxyPassReverse "/images" "https://www.example.com/"
</syntaxhighlight>
Im obigen Beispiel werden alle Anfragen, die mit dem Pfad <tt>/images</tt> beginnen, an das angegebene Backend weitergeleitet, andernfalls werden sie lokal verarbeitet


== ProxyPass ==
=== Cluster und Balancer ===
Um Apache als Reverse-Proxy-Server einzurichten, müssen Sie mod_proxy aktivieren
So nützlich das Obige auch ist, es hat immer noch den Nachteil, dass das Proxying dieser Anfragen keinen wirklichen Vorteil bietet, wenn der (einzelne) Backend-Knoten ausfällt oder stark belastet wird
* Es muss die Möglichkeit bestehen, eine Gruppe von Backend-Servern zu definieren, die solche Anfragen verarbeiten können, und der Reverse-Proxy muss für den Lastenausgleich und das Failover zwischen diesen Servern sorgen
* Diese Gruppe wird manchmal als ''Cluster'' bezeichnet, bei Apache httpd wird sie jedoch als ''Balancer'' bezeichnet


Einige andere gängige Mods, die du möglicherweise benötigst, sind unten aufgeführt
; Balancer
mod_proxy
Ein Balancer wird durch die Nutzung der [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy <Proxy>] und [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancermember BalancerMember]-Direktiven definiert
mod_http
mod_headers
mod_html


Um Module unter Debian zu aktivieren, müssen Sie sicherstellen, dass sie installiert und dann aktiviert sind.  
; Beispiel
<syntaxhighlight lang="apache" highlight="0" line copy>
<Proxy balancer://myset>
BalancerMember https://www2.example.com:8080
BalancerMember https://www3.example.com:8080
ProxySet lbmethod=bytraffic
</Proxy>


Das Installieren und Aktivieren von mod_proxy sieht beispielsweise folgendermaßen aus
ProxyPass "/images/" "balancer://myset/"
apt-get install libapache2-mod-proxy-html a2enmod mod_proxy
ProxyPassReverse "/images/" "balancer://myset/"
</syntaxhighlight>


Sobald diese Mods aktiviert sind, können wir mit der Bearbeitung der Apache-Konfiguration beginnen
# Das <tt>balancer://</tt> Schema teilt httpd mit, dass wir einen Balancer-Satz mit dem Namen "''myset"'' erstellen
* Die Speicherorte variieren je nach Linux-Distribution
# Es umfasst zwei Backend-Server, die httpd "''BalancerMembers"'' nennt
# In diesem Fall werden alle Anfragen für <tt>"/images"</tt> an ''einen der'' beiden Backends weitergeleitet
# Die [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyset "ProxySet]"-Anweisung gibt an, dass der Balancer "''myset"'' einen Lastausgleichsalgorithmus verwendet, der auf der Grundlage von E/A-Bytes ausgleicht
 
; Hinweis
<blockquote>
''BalancerMembers'' werden auch als ''Worker'' bezeichnet
</blockquote>
 
=== Konfiguration ===
; Balancer- und BalancerMember-Konfiguration
Sie können zahlreiche Konfigurationsdetails der ''Balancer'' und ''Worker'' über die verschiedenen in [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass]definierten Parameter anpassen
 
; Beispiel
Angenommen, wir möchten, dass ''<nowiki>https://www3.example.com:8080</nowiki>'' den dreifachen Datenverkehr mit einem Timeout von 1 Sekunde verarbeitet, würden wir die Konfiguration wie folgt anpassen:
 
<syntaxhighlight lang="apache" highlight="0" line copy>
<Proxy balancer://myset>
BalancerMember https://www2.example.com:8080
BalancerMember https://www3.example.com:8080 loadfactor=3 timeout=1
ProxySet lbmethod=bytraffic
</Proxy>
 
ProxyPass "/images" "balancer://myset/"
ProxyPassReverse "/images" "balancer://myset/"
</syntaxhighlight>
 
=== Failover ===
Sie können auch verschiedene Failover-Szenarien genau abstimmen und festlegen, auf welche Mitarbeiter und sogar auf welche Balancer in solchen Fällen zugegriffen werden soll
 
; Failover-Fälle
Das folgende Setup implementiert beispielsweise drei Failover-Fälle
# <tt>https://spare1.example.com:8080</tt> und <tt>https://spare2.example.com:8080</tt> werden nur dann Datenverkehr gesendet, wenn einer oder beide von <tt>https://www2.example.com:8080</tt> oder <tt>https://www3.example.com:8080</tt> nicht verfügbar sind. (Ein Ersatz wird verwendet, um ein unbrauchbares Mitglied desselben Balancer-Sets zu ersetzen.)
# <tt>https://hstandby.example.com:8080</tt> wird nur dann Datenverkehr gesendet, wenn alle anderen Mitarbeiter in Balancer-Set <tt>0</tt> nicht verfügbar sind
# Wenn alle Mitarbeiter, Ersatzmitarbeiter und der Standby-Mitarbeiter des Lastausgleichssatzes <tt>0</tt> nicht verfügbar sind, werden nur dann die <tt>https://bkup1.example.com:8080</tt> und <tt>https://bkup2.example.com:8080</tt> Mitarbeiter des Lastausgleichssatzes <tt>1</tt> in die Rotation einbezogen
 
<syntaxhighlight lang="apache" highlight="0" line copy>
<Proxy balancer://myset>
BalancerMember https://www2.example.com:8080
BalancerMember https://www3.example.com:8080 loadfactor=3 timeout=1
BalancerMember https://spare1.example.com:8080 status=+R
BalancerMember https://spare2.example.com:8080 status=+R
BalancerMember https://hstandby.example.com:8080 status=+H
BalancerMember https://bkup1.example.com:8080 lbset=1
BalancerMember https://bkup2.example.com:8080 lbset=1
ProxySet lbmethod=byrequests
</Proxy>
 
ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"
</syntaxhighlight>
 
; Vorteile
* einen oder mehrere aktive Ersatzmitarbeiter
* aktive Standby-Mitarbeiter für jeden Lastausgleichssatz
 
; Ausfallsicherung
Für die Ausfallsicherung werden Hot Spares als Ersatz für unbrauchbare Worker im selben Lastausgleichssatz verwendet
* Ein Worker gilt als unbrauchbar, wenn er ausgelastet, angehalten oder anderweitig in einem Fehler-/Ausfallzustand ist
* Hot Standbys werden verwendet, wenn alle Worker und Spares im Lastausgleichssatz nicht verfügbar sind
* Lastausgleichssätze (mit ihren jeweiligen Hot Spares und Standbys) werden immer in der Reihenfolge vom niedrigsten bis zum höchsten Wert versucht
 
=== Balancer Manager ===
Eine der einzigartigsten und nützlichsten Funktionen des Reverse-Proxys von Apache httpd ist die eingebettete Anwendung ''Balancer-Manager''.
* Ähnlich wie [https://httpd.apache.org/docs/2.4/mod/mod_status.html mod_status]zeigt ''Balancer-Manager'' die aktuelle Arbeitskonfiguration und den Status der aktivierten Balancer und Worker an, die derzeit verwendet werden
* Es werden jedoch nicht nur diese Parameter angezeigt, sondern es ermöglicht auch eine dynamische, laufende und spontane Neukonfiguration fast aller Parameter, einschließlich des Hinzufügens neuer ''BalancerMembers'' (Arbeiter) zu einem vorhandenen Balancer
 
Um diese Funktion zu aktivieren, muss Folgendes zu Ihrer Konfiguration hinzugefügt werden:
<syntaxhighlight lang="apache" highlight="0" line copy>
<Location "/balancer-manager">
SetHandler balancer-manager
Require host localhost
</Location>
</syntaxhighlight>
 
; Warnung
Aktivieren Sie den ''Balancer-Manager'' erst, wenn Sie [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#access Ihren Server] gesichert haben
* Achten Sie insbesondere darauf, dass der Zugriff auf die URL streng eingeschränkt ist
 
Wenn auf den Reverse-Proxy-Server unter dieser URL zugegriffen wird (z.&nbsp;B.: <tt>https://rproxy.example.com/balancer-manager/</tt>, wird eine Seite ähnlich der folgenden angezeigt:
[[Datei:Balancer-manager.png|mini]]
Dieses Formular ermöglicht es dem DevOps-Administrator, verschiedene Parameter anzupassen, Mitarbeiter offline zu schalten, Lastausgleichsmethoden zu ändern und neue Arbeiten hinzuzufügen
 
Wenn Sie beispielsweise auf den Balancer selbst klicken, wird die folgende Seite angezeigt:
[[Datei:BalancerManagerWorker.png|mini]]
Wenn Sie hingegen auf einen Mitarbeiter klicken, wird diese Seite angezeigt:
 
Um diese Änderungen beizubehalten, starten Sie den Reverse-Proxy neu und stellen Sie sicher, dass [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#balancerpersist BalancerPersist] aktiviert ist
 
=== Zustandsprüfungen ===
; Dynamische Zustandsprüfungen
Bevor httpd eine Anfrage an einen Worker weiterleitet, kann er "''testen"'', ob dieser Worker verfügbar ist, indem er den <tt>"ping</tt>"-Parameter für diesen Worker mithilfe von [https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass ProxyPass] einstellt
* Oft ist es sinnvoller, den Zustand der Worker ''außerhalb des Bandes'' auf dynamische Weise zu überprüfen
* Dies wird in Apache httpd durch das [https://httpd.apache.org/docs/2.4/mod/mod_proxy_hcheck.html mod_proxy_hcheck]-Modul erreicht
 
=== Statusflags ===
; BalancerMember-Statusflags
Im ''Balancer-Manager'' wird der aktuelle Zustand oder ''Status'' eines Arbeiters angezeigt und kann festgelegt/zurückgesetzt werden
 
; Bedeutungen
{|class="wikitable options"
! Flag !! String !! Beschreibung
|-
| || ''Ok'' || Arbeiter ist verfügbar
|-
| || ''Init'' || Arbeiter wurde initialisiert
|-
| D || ''Dis'' || Arbeiter ist deaktiviert und akzeptiert keine Anfragen; wird automatisch erneut versucht
|-
| S || ''Stop'' || Arbeiter ist administrativ gestoppt; akzeptiert keine Anfragen und wird nicht automatisch erneut versucht
|-
| I  || ''Ign'' || Der Worker befindet sich im Modus "Fehler ignorieren" und wird immer als verfügbar betrachtet
|-
| R || ''Spar'' || Der Worker ist ein Hot Spare
* Für jeden Worker in einem bestimmten lbset, der nicht verwendbar ist (leer, gestoppt, fehlerhaft und weitere), wird ein verwendbarer Hot Spare mit demselben lbset an seiner Stelle verwendet
* Hot Spares können dazu beitragen, dass eine bestimmte Anzahl von Workers immer für die Verwendung durch einen Balancer verfügbar ist
|-
| H || ''Stby'' || Der Worker befindet sich im Hot-Standby-Modus und wird nur verwendet, wenn keine anderen geeigneten Worker oder Ersatzteile im Balancer-Set verfügbar sind
|-
| E || ''Err'' || Der Worker befindet sich in einem Fehlerzustand, in der Regel aufgrund einer fehlgeschlagenen Vorab-Anforderungsprüfung
* Anforderungen werden nicht an diesen Worker weitergeleitet, aber je nach Einstellung für die erneute Ausführung des Workers wird ein erneuter Versuch unternommen
|-
| N || ''Drn'' || Der Worker befindet sich im Drain-Modus und akzeptiert nur bestehende Sticky-Sitzungen, die für ihn selbst bestimmt sind, und ignoriert alle anderen Anforderungen
|-
| C || ''HcFl'' || Der Worker hat die dynamische Zustandsprüfung nicht bestanden und wird erst verwendet, wenn er nachfolgende Zustandsprüfungen besteht
|}
 
== Konfiguration ==
Sobald diese Module aktiviert sind, können wir mit der Bearbeitung der Apache-Konfiguration beginnen
* Die Speicherorte variieren je nach Distribution
* Bei RHEL-basierten Distributionen ist dies Ihre httpd.conf
* Bei RHEL-basierten Distributionen ist dies Ihre httpd.conf
* Für Debian-basierte Sites verfügbar / Standard  
* Für Debian-basierte Sites verfügbar / Standard  


Erstellen Sie in Ihrem VirtualHost-Tag ein Location- Tag
=== VirtualHost ===
* das dem externen Pfad entspricht, den Sie verwenden möchten.
Erstellen Sie in Ihrem VirtualHost-Tag ein Location-Tag das dem externen Pfad entspricht, den Sie verwenden möchten


Für dieses Beispiel verwenden wir /  
; Beispiel /
<syntaxhighlight lang="apache" line copy>
  <Location />
  <Location />
   # commands go here
   # commands go here
  </Location>
  </Location>
</syntaxhighlight>


innerhalb des Location- Tags die Proxy-Optionen Fügen ProxyPass und Sie ProxyPassReverse hinzu, gefolgt von der Site-Adresse, die das Ziel des Proxys sein wird.
; Location
Hinzufügen
* ProxyPass
* ProxyPassReverse
gefolgt von der Site-Adresse, die das Ziel des Proxys sein wird


Sie benötigen außerdem einige Zeilen, um den Zugriff zu ermöglichen
; Zugriff ermöglichen
  ProxyPass http://mywebsite.jamescoyle.net/
<syntaxhighlight lang="apache" line copy>
  ProxyPassReverse http://mywebsite.jamescoyle.net/
  ProxyPass https://mywebsite.foxtom.net/
  ProxyPassReverse https://mywebsite.foxtom.net/
  Order allow,deny
  Order allow,deny
  Allow from all
  Allow from all
</syntaxhighlight>


Fügen Sie außerhalb der Standort-Tags oben auf dem virtuellen Host einige Extras hinzu
; Extras
Fügen Sie außerhalb der location-Standort-Tags oben auf dem virtuellen Host einige Extras hinzu
<syntaxhighlight lang="apache" line copy>
  ProxyHTMLStripComments on
  ProxyHTMLStripComments on
  ProxyRequests off
  ProxyRequests off
  SetOutputFilter proxy-html
  SetOutputFilter proxy-html
  ProxyHTMLDoctype XHTML
  ProxyHTMLDoctype XHTML
</syntaxhighlight>


Wenn Sie SSL-Datenverkehr als Proxy verwenden, müssen Sie außerdem Folgendes hinzufügen
; SSL-Datenverkehr
SSL-Datenverkehr als Proxy verwenden
<syntaxhighlight lang="apache" line copy>
  SSLProxyEngine on
  SSLProxyEngine on
</syntaxhighlight>


; Starten Sie Apache neu
Starten Sie Apache neu oder laden Sie die Einstellungen neu, damit die Änderungen wirksam werden
Starten Sie Apache neu oder laden Sie die Einstellungen neu, damit die Änderungen wirksam werden
service apache2 reload
<syntaxhighlight lang="bash" highlight="1" line copy>
 
sudo systemctl restart apache2 reload
Sie haben jetzt einen funktionierenden Proxy - alle an gesendeten Anfragen / werden von abgerufen http://mywebsite.jamescoyle.net
</syntaxhighlight>
 


== Beispiel ==
=== Beispiel ===
; Apache Reverse Proxy VirtualHost
; Apache Reverse Proxy VirtualHost
Das folgende Beispiel zeigt einen Apache VirtualHost, der Port 80 überwacht
VirtualHost, der Port 80 überwacht
 
* Akzeptiert Anforderungen, die mit '''www.foxtom.net''' übereinstimmen
Die Konfiguration akzeptiert Anforderungen, die mit dem www.jamescoyle.net Hostnamen übereinstimmen, und leitet die Anforderungen an den Server Back-End- mywebsite.jamescoyle.net weiter
* leitet Anforderungen an '''website.foxtom.net''' weiter


<syntaxhighlight lang="apache" line copy>
  <VirtualHost *:80>
  <VirtualHost *:80>
   ServerAdmin administrator@jamescoyle.net
   ServerAdmin administrator@foxtom.net
   ProxyRequests off
   ProxyRequests off
   DocumentRoot /var/www
   DocumentRoot /var/www
   SSLProxyEngine on
   SSLProxyEngine on
   ProxyPreserveHost On
   ProxyPreserveHost On
 
   ServerName www.jamescoyle.net
   ServerName www.foxtom.net
 
   ErrorLog ${APACHE_LOG_DIR}/error.log
   ErrorLog ${APACHE_LOG_DIR}/error.log
   CustomLog ${APACHE_LOG_DIR}/access.log combined
   CustomLog ${APACHE_LOG_DIR}/access.log combined
 
   # Possible values include: debug, info, notice, warn, error, crit,
   # Possible values include: debug, info, notice, warn, error, crit,
   # alert, emerg
   # alert, emerg
   LogLevel error
   LogLevel error
 
   <Location />
   <Location />
   ProxyPass http://mywebsite.jamescoyle.net/
   ProxyPass https://mywebsite.foxtom.net/
   ProxyPassReverse http://mywebsite.jamescoyle.net/
   ProxyPassReverse https://mywebsite.foxtom.net/
   Order allow,deny
   Order allow,deny
   Allow from all
   Allow from all
   </Location>
   </Location>
</VirtualHost>
</syntaxhighlight>


</VirtualHost>
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
* [[Reverse proxy]]
* [[mod_proxy]]
 
=== Dokumentation ===
=== Links ===
==== Weblinks ====
# https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html
 
[[Kategorie:Apache/HTTP/Proxy/Reverse]]


Tags: Apache 2 httpd mod_proxy ProxyPass ProxyPassReverse Reverse Proxy
</noinclude>

Aktuelle Version vom 11. Mai 2025, 13:44 Uhr

Apache/HTTP/Reverse proxy - Apache-Reverse-Proxy

Typische Implementierung

Beschreibung

HTTP(S)-Anforderungen an andere Computer weiterleiten

Apache kann als Reverse-Proxy verwendet werden

Vorteile

Sicherheit Apache-Instanz kann in eine DMZ gestellt und der Welt ausgesetzt werden, während die Webserver ohne Zugriff auf die Außenwelt dahinter sitzen können
Last reduzieren Sie können die Last auf den Webservern mit verschiedenen Methoden reduzieren, z. B. Web-Caching am Proxy, Lastausgleich und Ablenkung des Datenverkehrs für ungültige Anforderungen
Failover

Apache httpd (wie auch die meisten anderen Webserver) ist nicht nur ein "einfacher" Webserver, der Endbenutzern statische und dynamische Inhalte bereitstellt, sondern kann auch als Reverse-Proxy-Server fungieren, der auch als "Gateway"-Server bezeichnet wird

In solchen Szenarien generiert oder hostet httpd selbst keine Daten, sondern der Inhalt wird von einem oder mehreren Backend-Servern bezogen, die normalerweise keine direkte Verbindung zum externen Netzwerk haben

  • Wenn httpd eine Anfrage von einem Client erhält, wird die Anfrage selbst an einen dieser Backend-Server weitergeleitet, der dann die Anfrage bearbeitet, den Inhalt generiert und diesen Inhalt dann an httpd zurücksendet, das dann die eigentliche HTTP-Antwort an den Client generiert


Es gibt zahlreiche Gründe für eine solche Implementierung, aber im Allgemeinen sind die typischen Gründe Sicherheit, Hochverfügbarkeit, Lastverteilung und zentralisierte Authentifizierung/Autorisierung

Verwandte Module Verwandte Anweisungen
  • Bei diesen Implementierungen ist es von entscheidender Bedeutung, dass das Layout, das Design und die Architektur der Backend-Infrastruktur (die Server, die die Anfragen tatsächlich bearbeiten) isoliert und von außen geschützt sind
  • Für den Client ist der Reverse-Proxy-Server die einzige Quelle für alle Inhalte

Anwendung

Einfaches Reverse-Proxying

Die ProxyPass-Direktive legt die Zuordnung eingehender Anfragen zum Backend-Server (oder einem Server-Cluster, der als Balancer-Gruppe bezeichnet wird) fest

Im einfachsten Beispiel werden alle Anfragen ("/") an ein einzelnes Backend weitergeleitet:

ProxyPass "/" "https://www.example.com/"

Um sicherzustellen, dass die vom Backend generierten Location:-Header so geändert werden, dass sie auf den Reverse-Proxy verweisen, anstatt auf sich selbst, ist die ProxyPassReverse-Direktive am häufigsten erforderlich:

ProxyPass "/" "https://www.example.com/"
ProxyPassReverse "/" "https://www.example.com/"

Nur bestimmte URIs können über einen Proxy weitergeleitet werden, wie in diesem Beispiel gezeigt

ProxyPass "/images" "https://www.example.com/"
ProxyPassReverse "/images" "https://www.example.com/"

Im obigen Beispiel werden alle Anfragen, die mit dem Pfad /images beginnen, an das angegebene Backend weitergeleitet, andernfalls werden sie lokal verarbeitet

Cluster und Balancer

So nützlich das Obige auch ist, es hat immer noch den Nachteil, dass das Proxying dieser Anfragen keinen wirklichen Vorteil bietet, wenn der (einzelne) Backend-Knoten ausfällt oder stark belastet wird

  • Es muss die Möglichkeit bestehen, eine Gruppe von Backend-Servern zu definieren, die solche Anfragen verarbeiten können, und der Reverse-Proxy muss für den Lastenausgleich und das Failover zwischen diesen Servern sorgen
  • Diese Gruppe wird manchmal als Cluster bezeichnet, bei Apache httpd wird sie jedoch als Balancer bezeichnet
Balancer

Ein Balancer wird durch die Nutzung der <Proxy> und BalancerMember-Direktiven definiert

Beispiel
<Proxy balancer://myset>
 BalancerMember https://www2.example.com:8080
 BalancerMember https://www3.example.com:8080
 ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"
  1. Das balancer:// Schema teilt httpd mit, dass wir einen Balancer-Satz mit dem Namen "myset" erstellen
  2. Es umfasst zwei Backend-Server, die httpd "BalancerMembers" nennt
  3. In diesem Fall werden alle Anfragen für "/images" an einen der beiden Backends weitergeleitet
  4. Die "ProxySet"-Anweisung gibt an, dass der Balancer "myset" einen Lastausgleichsalgorithmus verwendet, der auf der Grundlage von E/A-Bytes ausgleicht
Hinweis

BalancerMembers werden auch als Worker bezeichnet

Konfiguration

Balancer- und BalancerMember-Konfiguration

Sie können zahlreiche Konfigurationsdetails der Balancer und Worker über die verschiedenen in ProxyPassdefinierten Parameter anpassen

Beispiel

Angenommen, wir möchten, dass https://www3.example.com:8080 den dreifachen Datenverkehr mit einem Timeout von 1 Sekunde verarbeitet, würden wir die Konfiguration wie folgt anpassen:

<Proxy balancer://myset>
 BalancerMember https://www2.example.com:8080
 BalancerMember https://www3.example.com:8080 loadfactor=3 timeout=1
 ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images" "balancer://myset/"
ProxyPassReverse "/images" "balancer://myset/"

Failover

Sie können auch verschiedene Failover-Szenarien genau abstimmen und festlegen, auf welche Mitarbeiter und sogar auf welche Balancer in solchen Fällen zugegriffen werden soll

Failover-Fälle

Das folgende Setup implementiert beispielsweise drei Failover-Fälle

  1. https://spare1.example.com:8080 und https://spare2.example.com:8080 werden nur dann Datenverkehr gesendet, wenn einer oder beide von https://www2.example.com:8080 oder https://www3.example.com:8080 nicht verfügbar sind. (Ein Ersatz wird verwendet, um ein unbrauchbares Mitglied desselben Balancer-Sets zu ersetzen.)
  2. https://hstandby.example.com:8080 wird nur dann Datenverkehr gesendet, wenn alle anderen Mitarbeiter in Balancer-Set 0 nicht verfügbar sind
  3. Wenn alle Mitarbeiter, Ersatzmitarbeiter und der Standby-Mitarbeiter des Lastausgleichssatzes 0 nicht verfügbar sind, werden nur dann die https://bkup1.example.com:8080 und https://bkup2.example.com:8080 Mitarbeiter des Lastausgleichssatzes 1 in die Rotation einbezogen
<Proxy balancer://myset>
 BalancerMember https://www2.example.com:8080
 BalancerMember https://www3.example.com:8080 loadfactor=3 timeout=1
 BalancerMember https://spare1.example.com:8080 status=+R
 BalancerMember https://spare2.example.com:8080 status=+R
 BalancerMember https://hstandby.example.com:8080 status=+H
 BalancerMember https://bkup1.example.com:8080 lbset=1
 BalancerMember https://bkup2.example.com:8080 lbset=1
 ProxySet lbmethod=byrequests
</Proxy>

ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"
Vorteile
  • einen oder mehrere aktive Ersatzmitarbeiter
  • aktive Standby-Mitarbeiter für jeden Lastausgleichssatz
Ausfallsicherung

Für die Ausfallsicherung werden Hot Spares als Ersatz für unbrauchbare Worker im selben Lastausgleichssatz verwendet

  • Ein Worker gilt als unbrauchbar, wenn er ausgelastet, angehalten oder anderweitig in einem Fehler-/Ausfallzustand ist
  • Hot Standbys werden verwendet, wenn alle Worker und Spares im Lastausgleichssatz nicht verfügbar sind
  • Lastausgleichssätze (mit ihren jeweiligen Hot Spares und Standbys) werden immer in der Reihenfolge vom niedrigsten bis zum höchsten Wert versucht

Balancer Manager

Eine der einzigartigsten und nützlichsten Funktionen des Reverse-Proxys von Apache httpd ist die eingebettete Anwendung Balancer-Manager.

  • Ähnlich wie mod_statuszeigt Balancer-Manager die aktuelle Arbeitskonfiguration und den Status der aktivierten Balancer und Worker an, die derzeit verwendet werden
  • Es werden jedoch nicht nur diese Parameter angezeigt, sondern es ermöglicht auch eine dynamische, laufende und spontane Neukonfiguration fast aller Parameter, einschließlich des Hinzufügens neuer BalancerMembers (Arbeiter) zu einem vorhandenen Balancer

Um diese Funktion zu aktivieren, muss Folgendes zu Ihrer Konfiguration hinzugefügt werden:

<Location "/balancer-manager">
 SetHandler balancer-manager
 Require host localhost
</Location>
Warnung

Aktivieren Sie den Balancer-Manager erst, wenn Sie Ihren Server gesichert haben

  • Achten Sie insbesondere darauf, dass der Zugriff auf die URL streng eingeschränkt ist

Wenn auf den Reverse-Proxy-Server unter dieser URL zugegriffen wird (z. B.: https://rproxy.example.com/balancer-manager/, wird eine Seite ähnlich der folgenden angezeigt:

Dieses Formular ermöglicht es dem DevOps-Administrator, verschiedene Parameter anzupassen, Mitarbeiter offline zu schalten, Lastausgleichsmethoden zu ändern und neue Arbeiten hinzuzufügen

Wenn Sie beispielsweise auf den Balancer selbst klicken, wird die folgende Seite angezeigt:

Wenn Sie hingegen auf einen Mitarbeiter klicken, wird diese Seite angezeigt:

Um diese Änderungen beizubehalten, starten Sie den Reverse-Proxy neu und stellen Sie sicher, dass BalancerPersist aktiviert ist

Zustandsprüfungen

Dynamische Zustandsprüfungen

Bevor httpd eine Anfrage an einen Worker weiterleitet, kann er "testen", ob dieser Worker verfügbar ist, indem er den "ping"-Parameter für diesen Worker mithilfe von ProxyPass einstellt

  • Oft ist es sinnvoller, den Zustand der Worker außerhalb des Bandes auf dynamische Weise zu überprüfen
  • Dies wird in Apache httpd durch das mod_proxy_hcheck-Modul erreicht

Statusflags

BalancerMember-Statusflags

Im Balancer-Manager wird der aktuelle Zustand oder Status eines Arbeiters angezeigt und kann festgelegt/zurückgesetzt werden

Bedeutungen
Flag String Beschreibung
Ok Arbeiter ist verfügbar
Init Arbeiter wurde initialisiert
D Dis Arbeiter ist deaktiviert und akzeptiert keine Anfragen; wird automatisch erneut versucht
S Stop Arbeiter ist administrativ gestoppt; akzeptiert keine Anfragen und wird nicht automatisch erneut versucht
I Ign Der Worker befindet sich im Modus "Fehler ignorieren" und wird immer als verfügbar betrachtet
R Spar Der Worker ist ein Hot Spare
  • Für jeden Worker in einem bestimmten lbset, der nicht verwendbar ist (leer, gestoppt, fehlerhaft und weitere), wird ein verwendbarer Hot Spare mit demselben lbset an seiner Stelle verwendet
  • Hot Spares können dazu beitragen, dass eine bestimmte Anzahl von Workers immer für die Verwendung durch einen Balancer verfügbar ist
H Stby Der Worker befindet sich im Hot-Standby-Modus und wird nur verwendet, wenn keine anderen geeigneten Worker oder Ersatzteile im Balancer-Set verfügbar sind
E Err Der Worker befindet sich in einem Fehlerzustand, in der Regel aufgrund einer fehlgeschlagenen Vorab-Anforderungsprüfung
  • Anforderungen werden nicht an diesen Worker weitergeleitet, aber je nach Einstellung für die erneute Ausführung des Workers wird ein erneuter Versuch unternommen
N Drn Der Worker befindet sich im Drain-Modus und akzeptiert nur bestehende Sticky-Sitzungen, die für ihn selbst bestimmt sind, und ignoriert alle anderen Anforderungen
C HcFl Der Worker hat die dynamische Zustandsprüfung nicht bestanden und wird erst verwendet, wenn er nachfolgende Zustandsprüfungen besteht

Konfiguration

Sobald diese Module aktiviert sind, können wir mit der Bearbeitung der Apache-Konfiguration beginnen

  • Die Speicherorte variieren je nach Distribution
  • Bei RHEL-basierten Distributionen ist dies Ihre httpd.conf
  • Für Debian-basierte Sites verfügbar / Standard

VirtualHost

Erstellen Sie in Ihrem VirtualHost-Tag ein Location-Tag das dem externen Pfad entspricht, den Sie verwenden möchten

Beispiel /
 <Location />
  # commands go here
 </Location>
Location

Hinzufügen

  • ProxyPass
  • ProxyPassReverse

gefolgt von der Site-Adresse, die das Ziel des Proxys sein wird

Zugriff ermöglichen
 ProxyPass https://mywebsite.foxtom.net/
 ProxyPassReverse https://mywebsite.foxtom.net/
 Order allow,deny
 Allow from all
Extras

Fügen Sie außerhalb der location-Standort-Tags oben auf dem virtuellen Host einige Extras hinzu

 ProxyHTMLStripComments on
 ProxyRequests off
 SetOutputFilter proxy-html
 ProxyHTMLDoctype XHTML
SSL-Datenverkehr

SSL-Datenverkehr als Proxy verwenden

 SSLProxyEngine on
Starten Sie Apache neu

Starten Sie Apache neu oder laden Sie die Einstellungen neu, damit die Änderungen wirksam werden

sudo systemctl restart apache2 reload

Beispiel

Apache Reverse Proxy VirtualHost

VirtualHost, der Port 80 überwacht

  • Akzeptiert Anforderungen, die mit www.foxtom.net übereinstimmen
  • leitet Anforderungen an website.foxtom.net weiter
 <VirtualHost *:80>
  ServerAdmin administrator@foxtom.net
  ProxyRequests off
  DocumentRoot /var/www
  SSLProxyEngine on
  ProxyPreserveHost On
 
  ServerName www.foxtom.net
 
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg
  LogLevel error
 
  <Location />
   ProxyPass https://mywebsite.foxtom.net/
   ProxyPassReverse https://mywebsite.foxtom.net/
   Order allow,deny
   Allow from all
  </Location>
 
 </VirtualHost>



Anhang

Siehe auch

Dokumentation

Links

Weblinks

  1. https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html