Internetzugriff auf Proxmox VMs / Docker Container hinter OPNsense mit Reverse Proxy

TErxleben said:
Du betrachtest doch eher Outsourcing vs. Inhouse. Wenn du mir jemanden nennen kannst, der dir die externe Dienstleistung kubernetes spürbar günstiger als externes Proxmoxclustering anbietet, wäre das sogar eine Überlegungen wert.
Ich bleibe dabei, dass Docker primär die Verantwortlichkeit Richtung Hersteller verschiebt, der sich einen Scheißdreck um die BS-Basis kümmern *will*, der dich aber trotzdem im Fehlerfall für irgendwas in deiner Infrastruktur zur Verantwortung ziehen will!
Click to expand...

Die Frage ist aber, ob das nun was Schlechtes ist. Wenn der Hersteller mir ein docker-image samt allen Abhängigkeiten zur Verfügung stellt, dann bin ich als Kunde/Endanwender nicht Schuld, wenn es nicht läuft (weil ich irgendeine Abhängigkeit übersehen habe beim Einrichten), sondern ich kann halt darauf verweisen, dass es eigentlich funktionieren sollte und die übliche Ausrede von Entwicklern "Bei mir geht es" oder "Betriebssystem x wird nicht unterstützt" nicht greift. Plus dass es eben das Deployment extrem vereinfacht.


TErxleben said:
Klagst du dann? Ich stelle im Fehlerfall einfach die Vorversions-VM her und informiere den Hersteller über einen Misserfolg, statt an meinem Virtualisierungshost rumzuschrauben.
Click to expand...

Da ist aber unabhängig davon, ob auf der VM nun docker läuft oder nicht.
 
Ja, Docker gehört in eine eigene VM, nicht auf den PVE-Host. Der Host sollte schlank bleiben und nur Proxmox laufen. So hast du eine saubere Trennung und wenn im Container was schiefgeht, ist der Hypervisor nicht betroffen.

Mit OPNsense davor und VLANs bist du da schon auf nem guten Weg. Für den Reverse Proxy auf der OPNsense schau dir das Caddy- oder nginx-Plugin an, damit kannst du dann per VLAN gezielt nur die nötigen Ports zu den VMs durchreichen.
 
  • Like
Reactions: Johannes S
Geschichten, die das Leben mit LXCs schreibt und es hierhin passt.
  • Ich setze seit gefühlten Äonen Apache Guacamole als Fernsteuerungsproxy ein.
  • irgendwann kam ich auf die naheliegende/dusselige Idee, selbiges zu virtualisieren
  • Da ich damals noch dümmer als Heute war, habe ich das damals mittels LXC realisiert.
  • Lief auch jahrelang ohne Probleme.
  • selbst Updates waren Dank der Leistung von MysticRyuujin gut und schnell abgefiedelt
  • Nun kam ich auf die Idee, das zu grundeliegende Ubuntu 20.04 zu aktualisieren.
  • Upgrade auf 24.04 klappte mit Fummelei auch.
  • Selbst ein Update von Guacamole von 1.5.5 auf 1.6.0 lief wie erwartet reibungslos.
  • regelmäßige Updates der PVE-hosts sind eh obligatorisch und fanden immer statt.
  • Innerhalb des Guacamole-Containers läuft auch jetzt augenscheinlich alles ohne Fehler.
  • Dummerweise reconnecten die Clients in der neuen Umgebung nun dauernd.
  • Vatti dachte, er braucht nur eine Sicherung der alten Version einspielen.
  • Aber weit gefehlt. Auch diese reconnecten plötzlich aus heiterem Himmel.
Moral von der Geschicht:
  • Kapsel immer in einer VM
  • Damit sparst du dir Zeit bei der Fehlersuche bzw. ermöglichst sie erst.
  • Warum stecken essentielle Dinge wie Apache-Gucacamole nicht in den offiziellen Debian-Repos?
  • Obwohl die Apache-Foundation ja nun nicht gerade zu den Leichtgewichten gehört.
  • Ich muss jetzt viel Zeit in Fehlersuche investieren, weil ich damals nicht ordentlich Isoliert habe.
 
Last edited:
  • Like
Reactions: micneu, Johannes S and UdoB
You must log in or register to reply here.
Top Bottom
Back