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

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/"
- Das balancer:// Schema teilt httpd mit, dass wir einen Balancer-Satz mit dem Namen "myset" erstellen
- Es umfasst zwei Backend-Server, die httpd "BalancerMembers" nennt
- In diesem Fall werden alle Anfragen für "/images" an einen der beiden Backends weitergeleitet
- 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
- 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.)
- https://hstandby.example.com:8080 wird nur dann Datenverkehr gesendet, wenn alle anderen Mitarbeiter in Balancer-Set 0 nicht verfügbar sind
- 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
|
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
|
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