Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Antworten
SlitEye
Beiträge: 3
Registriert: 16.12.2022 18:17:28

Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Beitrag von SlitEye » 16.12.2022 21:27:05

Hallo Zusammen,

unabhängig vom Sinn und Einsatzzweck beschäftige ich mich derzeit mit der Kombination von Reverse Proxys. Hauptsächlich mit dem Ziel eine Basis zu haben, um eine WebApp (CMS, Webseite, Angular-WebApp, etc.) skalierend, hochverfügbar und optional mit der Möglichkeit des Load Balancing bereitzustellen und die Beantwortung von HTTP- und HTTPS-Anfragen optimierenderweiser (erstmal ohne Caching-Gedöns) zu realisieren. Alle Dienste betreibe ich in Containern (derzeit auf Docker/Docker-Compose/Swarm-Basis).

Hierbei haben sich nach Sichtung der Vor- und Nachteile sowie Vergleiche folgende Server herausgestellt:
(a) haProxy: Reverse Proxy, SSL/TLS, Hochverfügbarkeit, Skalierung, Load Balancer, Performance
(b) nginx: Reverse Proxy, SSL/TLS, Performance, primär für statische Webinhalte
(c) Apache2: primär für dynamische Webinhalte
(d) Traefik: Edge-Router, Reverse Proxy und Load Balancer für Container-Dienste, wobei ich mich frage, wozu man diesen braucht (siehe unten bei 4.))

Hierbei tun sich mir beim Recherchieren diverse Fragen zu folgenden Use Cases auf:

1.) Proxy-Stack 1:
Frontende:nginx —> Backend:Apache2 <— WebApp

Egal welche Seiten, Blogs, Tutorials, Dev-Channels ich sichte, alle zeigen eine funktionierende Konfiguration, wo sie per Konfiguration nginx anweisen, jede http- und https-Anfrage 1:1 an den Apache2 durchzureichen und dann behaupten, dass man so die Vorteile beider Welten (nginx für statisches Inhalte unf Apache2 für dynamische Inhalte) kombiniert werden.

1.1)
Wenn die Konfiguration von nginx aber einfach nur den Traffic an Apache2 durchreichen lässt und der Apache2 dann die Anfragen wieder bearbeitet und beantwortet, inwiefern profitiert man dann vom davorgeschalteten nginx??? Der Apache2 hat doch dann dieselbe Last wie als wenn man den nginx weg lässt.

1.2)
Und wozu nginx:443 an Apache2:443 durchreichen? Da hat man doch doppeltes SSL/TLS-Handshaking, nämlich einmal von Client an nginx und dann nochmal von nginx an Apache2.

Ansonsten so hintereinandergeschalten finde ich den Stack schon interessant, in Abhängigkeit der angefragten Inhalte, dass entweder der nginx oder Apache2 die Anfrage beantwortet. Aber irgendwie gibt das keine der Beispielkonfigurationen im Netz her oder aber ich übersehe in der Ausführung etwas.

2.) Proxy-Stack 2:
Frontend:haproxy =>
—> Backend1:nginx <— WebApp1
—> Backend2:Apache2 <— WebApp2


Logischer finde ich daher diese Konstellation, entnommen von hier:

https://www.linuxbabe.com/linux-server/ ... ntu-centos

Hier nutzt man klar die Vorzüge des haProxy an der Eingangstür.
Aber letztendlich geht es hierbei nur darum, welche Domain bzw. WebApp man letztendlich mit welchen Webserver bespaßen lässt. In Abhängigkeit der angefragten Domain-spezifischen Anfrage, wird die Anfrage entweder an den nginx oder aber an den Apache2 durchgereicht und von denen beantworten lässt, aber niemals beide gleichzeitig wie noch beim Use Case von 1.).

Mit anderen Worten, man nutzt dieses Proxy-Stack-Setup, um für unterschiedlichste WebApps, jeweils nur EINEN Web-Server arbeiten zu lassen. Sprich, für eine WebApp kommt auch nur wieder ein Webserver zum Einsatz. Die Vorzüge des anderen Webservers (nginx) können hierbei wohl nicht mit den Vorzügen des einen Webservers (Apache2) kombiniert werden.

Da dies aber auch der nginx kann, braucht es im Prinzip nicht den haProxy (nginx —> Apache2) oder anders herum (haProxy —> Apache2).

3.) Proxy-Stack 3:
In Anlehnung an 1.) und 2.) frage ich mich daher, ob folgendes Proxy-Stack-Setup möglich wäre und Sinn macht:

Frontend:haProxy =>
—> Backend1:nginx —> Backend1.1:Apache2 <— WebApp1
Optional noch je nach spezifischen Anwendungsfällen:
—> Backend2:nginx <— WebApp2
—> Backend3:Apache2 <— WebApp3


Der haProxy sorgt also für einen hochverfügbaren und performanten Frontend-Eingang als Reverse Proxy, mit denen man folgende Use Cases verwenden kann:

Backend1 entspräche also wieder 1.)
Zusätzlich hat man aber noch optional die Domain- bzw. Anwendungsfall-abhängige Möglichkeit mit Backend2 nur nginx-Betrieb zu nutzen oder mit Backend3 nur Apache2-Betrieb.

4.) Traefik: Als Proxy, Load Balancer und Router für Container-basierte Microservices:
4.1)
Den Sinn und Zweck von Traefik sehe ich irgendwie noch nicht, wenn ich die Dienste ohnehin schon mit einer Container-Engine realisiere. Das korrekte Routing kann man bereits im Docker-Compose-Yaml-File definieren und mittels Portainer kann man Container in einer Web-GUI verwalten und monitoren.

Weshalb sollte man dann Traefik nutzen?

4.2)
Noch weniger verstehe ich, was der Traefik als Proxy, Router und Load Balancer für Container-basierte Microservices bringen soll, wenn man diesen selbst als Docker-Container betreibt???

Ich würde da jetzt eher erwarten, dass Traefik eher auf dem Host neben der Container-Engine agiert als selbst Bestandteil (Container) einer Docker-Komposition zu sein. Das wäre doch nichts weiter als Host-WAN an Docker-Engine-WAN an Traefik-Container (der dann als Proxy und Router für die anderen Container dient).

Im Netz hab ich auch schon gesehen, dass welche haProxy —> Traefik kombinieren. Ich verstehe nur den Sinn nicht.

Vlt. fehlt es mir aber auch einfach an Vorstellungskraft, sowas einzusetzen (und nein, Lets Encrypt ist für mich kein Vorteil).

————————————-

Wenn da also jemand mehr Einblicke hat und mir die Use Cases näher erläutern oder mich auf nicht beachtete Aspekte hinweisen könnte, wäre das super.

Habt vielen Dank schonmal im Voraus und

VG

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Beitrag von novalix » 20.12.2022 14:19:38

Hi,

die Begriffe "Proxy" und "Caching" werden oft zusammen verwendet, weil beide Funktionen in verschiedener Software vereint auftreten (z.B. nginx oder apache2)*.
HAProxy dagegen ist ein reiner proxy server, der sich "nur" um das http routing kümmert.**
Man kann damit allerdings das routing so konfigurieren, dass statische Inhalte von einem dezidierten caching server geladen werden (z.B. varnish oder nginx).

Meine Empfehlung: Nimm Dir etwas Zeit und lies das sehr gute Manual von HAProxy. Selbst wenn Du Dich für eine andere Lösung entscheidest, hilft Dir das beim Verständnis der Sache ungemein.

* Das sind "nebenbei" natürlich auch noch httpds.

** Stimmt so nicht. HAProxy kann auch das routing auf TCP-Level übernehmen. Da ist http logischerweise mit drin. Die Konfiguration ist dann allerdings noch mal voraussetzungsvoller.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

SlitEye
Beiträge: 3
Registriert: 16.12.2022 18:17:28

Re: Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Beitrag von SlitEye » 20.12.2022 15:01:54

Danke erstmal für Deine Antwort, aber sie driftet nur etwas von meiner Anfrage ab. Du beziehst Dich per * und ** auf Aussagen, die ich selbst nie getroffene habe.

Mir sind die Funktionalitäten von HAProxy, Nginx und Co. soweit klar und ich habe mich dahingehend auch eingehend bereits eingelesen und auch praktisch ausprobiert.

Dabei sind mir jedoch diese Fragen aufgekommen, die mir irgendwie keine gesichtete Quelle, noch praktische Anwendung / Testing bisher beantworten konnte.

Daher habe ich mich mit diesen noch offenen Fragen an die Community gewendet. Mir ist natürlich klar, dass dies hier primär ein Debian-Forum ist, aber es gibt halt auch entsprechende thematische Subforen hier, zumal die Basis meiner Hosts sowie meiner Container Debian stellt. Ich wüsste jetzt nicht wirklich, welche anderen Foren hinsichtlich meiner Fragen besser geeignet seien. 🤔

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Beitrag von novalix » 22.12.2022 15:14:01

Ja sorry,

meine Absicht war es etwas Aufhellendes zu den verwendeten Begriffen beizutragen. Das klappt nicht immer auf Anhieb.

Etwas verwirrend für mich war, dass Du von einer WebApp sprichst, in den Szenarien dann aber das routing zu mehreren (unterschiedlichen?) Apps beschreibst.
Im Falle von HAProxy ist es so, dass das routing im (internen) frontend und das load balancing im (internen) backend stattfindet. Letzteres wird in dem von Dir verlinkten Tutorial aber gar nicht angesprochen. Eine Lasten verteilende Definition müsste in etwa so aussehen:

Code: Alles auswählen

backend DeineApp
    option $Options
    balance leastconn 
    server httpd1 $IP_Container1:$Port $Options check
    server httpd2 $IP_Container2:$Port $Options check

Die Namen vom backend und der server sind arbiträr. Die Anweisung "balance" hat auch noch andere Optionen ("leastconn" ist aber geläufig).

Ich würde davon ausgehen, dass es Sinn ergibt, wenn "Container2" ein Klon von "Container1" ist. In den meisten Szenarien wären zwei unterschiedliche Implementationen unnötiger Overhead.

Ich hoffe das hilft ein wenig.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

SlitEye
Beiträge: 3
Registriert: 16.12.2022 18:17:28

Re: Verständnis zu Proxy-Stacks (HAProxy, nginx, apache2, traefik, etc.)

Beitrag von SlitEye » 22.12.2022 15:22:35

Natürlich vielen Dank, aber an den Begrifflichkeiten und ihrer Einordnung mangelt es nicht.

Mir geht es auch nicht ausschließlich um haProxy.

Ich hatte gehofft mit Beschreibung verschiedener Use Cases und entsprechender Nummerierungen etwas Klarheit und Struktur meiner Anfrage zu verleihen.

Load Balancing an sich verstehe ich weniger als das Aufteilen von Anfragen an verschiedene unabhängige Server-Apps (also nach Domäne), sondern vielmehr das Verteilen von Anfragen in Abhängigkeit der angefragten Inhalte (statisch, dynamisch, spezifisch) an mehrere Instanzen desselben Containers/Servers und in Abhängigkeit entsprechender Metriken.

Das eine verlinkte Tutorial war nur ein Beispiel und nur auf den einen Use Case bezogen. Dieses gilt nicht für die anderen Use Cases.

Primär geht es mir auch erstmal noch nicht um das Load Balancing, sondern um Verständnisfragen zu den genannten Use Cases und Proxy-Stacks. Load Balancing, Caching und Co. sind dann einfach Features, von denen ich dann jederzeit Gebrauch machen kann, aber nicht muss. Zunächst aber muss erstmal ein Proxy-Stack als Grundlage her.

Antworten