Moin!
On 16.04.21 15:19, Ralph Lindner wrote:
> Ich möchte auf einem root-server (VM von Netcup) mehrere lxc mit z. B.
> Webservern oder Nextcloud einrichten. Damit die URL beim richtigen lxc
> landen, benötige ich natürlich einen reverse proxy. Soweit so klar.
Bingo.
> Es sollte aber auch möglich sein nachträglich sowohl das lxc-Ziel (einer
> Domain) zu ändern, als auch die Webadresse des lxc.
Das sind ja die Einstellungen des Reverse-Proxy. Also so ungefähr.
(www.)domain1.de → 192.168.1.101
(www.)domain2.de → 192.168.1.102
Die genauen Domains und Ziele müssen ja in der Config des RevProxy
hinterlegt werden.
> - Ersteres z. B. um auf einen Mirror umzustellen oder nach einem
> Relaunch auf ein neues System.
Würde in den Beispielen bedeuten, die (Ziel-)IP-Adresse des LXContainer
anzupassen.
> - Zweites um aus einer Entwicklungsumgebung ein Produktivsystem zu
> machen. [z. B. wenn ein lxc zuerst als Entwicklungsumgebung (erreichbar
> z. B. unter https://kunde1.dev.example.com) genutzt wird und
> anschließend als Produktivsystem (unter https://kunde1.com)]
Umstellung/Ergänzung der Domain(s) im RevProxy. Und evtl. noch
Anpassung(en) im Backend, damit Links&Co. mit den richtigen URLs/Domains
generiert werden.
> Wegen dieser beiden Anforderungen erscheint es mir ratsam die
> letsencrypt-Zertifikate vom reverse proxy verwalten zu lassen und nicht
> vom lxc. Ist das plausibel und sehe ich das richtig?
Das ist ein bisschen Konzept-Frage. *ICH* halte es für ausreichend, wenn
SSL auf dem RevProxy terminiert (und dort auch verwaltet wird, z.B.
Lets-Encrypt oder sowas) und nach hinten einfach HTTP gesprochen wird -
wenn jemand den Traffic dort abgreifen kann, kann er's auch im
Container. Außerdem kann man dann mit dem RevProxy ggf. auch noch die
Header/Inhalte fixen/hinzufügen/... Ja, BTDT, weil immer wieder WebApps
davon ausgehen, dass sie den ganzen Server für sich haben 🙄
Auf der anderen Seite gibt es aber auch die Möglichkeit, anhand von SNI
"Server Name Indication", dem "Host:"-Header von SSL/TLS den
Backend-Server auszuwählen. Dann wäre HAProxy, sniproxy oder nginx
(nicht Apache) Dein RevProxy. Irgendwas davon konnte dann keine
Wildcard-Zertifikate, irgendwas nur einen (Teil-)Domainnamen je
Backend-Server, auch deswegen hab ich das Thema aufgegeben. Mag aber
sein, dass sich da auch schon wieder was getan hat.
Bonus-Frage: Soll der ReverseProxy auf dem Host oder ebenfalls in einem
Container laufen? Und schon wieder: Religionsfrage 😁
> Wenn ja, welche Software sollte man als reverse proxy einsetzen?
> nginx oder apache oder gleich große Geschütze wie HAProxy?
Den, mit dem Du Dich am meisten auskennst. Nein, kein Witz früher oder
später wirst Du an Stellen kommen, wo Du nacharbeiten musst. Und das
"Nacharbeiten" ist dann halt vom jeweiligen Server abhängig. Teilweise
ist es sogar so, dass Du Fehler mit einem der Server hast, mit einem
anderen gar nicht, weil er irgendwas von vorne herein anders macht.
BTW, HAProxy ist kein großes Geschoss. Ist halt ein
Reverse-Proxy/Loadbalancer und das beherrschen sowohl Apache als auch
nginx ebenfalls.
Und falls jetzt gleich wieder ein nginx-Jünger um die Ecke kommt: Nein,
damit ist nicht alles einfach einfach und funktioniert out-of-the-box 😜
> Für HAProxy habe ich eine Anleitung zur zentralen Verwaltung der
> Zertifikate mit certbot gefunden
> (https://kevinbentlage.nl/blog/lets-encrypt-with-haproxy/).
Dass ich kein Freund von certbot bin, sollte hier ja hinlänglich bekannt
sein. In meinen Setups läuft entweder dehydrated.io (nach wie vor mein
Favorit) oder acme.sh (in Kombination mit haproxy). Aber grundsätzlich
gilt auch hier: Der LE-Client, mit dem Du Dich auskennst.
Das Setup aus dem Link funktioniert grundsätzlich. BTDT, mit certbot und
acme.sh - dehydrated.io bräuchte dann halt 'nen zusätzlichen Web-Server,
deswegen nehm ich das an dieser Stelle nicht.
> Allerdings bevorzuge ich in diesem Fall unbedingt die EINFACHSTE Lösung,
> denn ich habe bisher noch nie reverse proxy konfiguriert und bin auch
> mit lxc noch Anfänger.
> Welches Vorgehen würdet ihr mir empfehlen?
Ganz klar: Apache auf dem Host, mit Deinem favorisierten LE-Client.
Warum? Weil Du schon mit Apache gemacht hast, die grundsätzliche
Konfiguration kennst, es viele Möglichkeiten gibt Einfluss zu nehmen und
- WICHTIG - Du findest zu fast allen Problemen Lösungen im Netz. Und ob
Dein VHost nun Reverse-Proxy ist oder Dateien direkt ausliefert ist für
SSL/TLS-Dinge egal, hier findest Du also auch bestimmt bei Problemen
Hilfe im Netz.
Und wenn ich dran denke 😝 , dann erweitere ich nochmal die Lösung im
LUSC-Wiki zum RevProxy!
Bye
Sven
--
--
Leukämie → http://de.wikipedia.org/wiki/Leuk%C3%A4mie
Heilung → http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende
Typisierung → https://akb.de/registrierung/ https://zkrd.de/de/adressen/
Fragen? → sven@???
--
Mailing-Liste der Linux User Schwabach (LUSC) e.V.
Vor und beim Posten bitte
=> http://lusc.de/List-Netiquette <= und
=> http://lusc.de/List-Howto <= beachten. Danke!
(text/plain)