Ein bemerkenswerter Traefik-Reverse-Proxy und Load Balancer auch ohne Container

 (j6b72.de)
3 Punkte von GN⁺ 2024-05-06 | 1 Kommentare | Auf WhatsApp teilen
  • Traefik ist in Container-Umgebungen bekannt, kann aber als einzelne Go-Executable bereitgestellt werden und damit auch ohne Container-Engine als Reverse Proxy betrieben werden
  • Im Vergleich zu nginx/caddy/apache2, die direkt Dateien ausliefern, ist es eher ein Proxy näher an HAProxy und fokussiert sich auf Request-Weiterleitung, Response-Rückgabe und Header-Anpassung
  • Auch ohne Docker-Labels lässt es sich über den Configuration File Provider konfigurieren; statische und dynamische Konfiguration werden getrennt, um Router, Services und Middleware zu verwalten
  • TLS Passthrough sowie Ein- und Ausgabe des PROXY Protocol von HAProxy werden unterstützt, allerdings muss auch der Zieldienst das PROXY Protocol unterstützen; apache2 und nginx tun das
  • Für Authentifizierungsintegration sowie das Blockieren von User-Agents und IPs reichen die Bordmittel unter Umständen nicht aus; man sollte deshalb auch den Verwaltungsaufwand von ForwardAuth, oauth2-proxy und Drittanbieter-Plugins mit einbeziehen

Traefik auch außerhalb von Containern

  • Traefik hat in den letzten Jahren im home-lab-YouTube-Umfeld an Popularität gewonnen und wird meist zusammen mit Container-Infrastruktur wie Docker oder Kubernetes vorgestellt
  • Vom Funktionscharakter her ist es HAProxy näher als nginx/caddy/apache2
    • Es leitet Requests an Services weiter und liefert Responses zurück
    • Es kann Header und Teile von Requests und Responses verändern
    • File Serving wird nicht unterstützt
  • In Container-Umgebungen kann Traefik ebenfalls als Container laufen und per gemountetem Docker-Socket andere Container automatisch erkennen
    • Das Proxy-Verhalten lässt sich über Docker-Labels der Container konfigurieren
    • Erkennt es neue Container, kann es automatisch Let’s-Encrypt-TLS-Zertifikate anfordern und den Service veröffentlichen

Einzelne Binärdatei und Bereitstellung mit systemd

  • Traefik ist in Go geschrieben und wird zu einer einzelnen Executable kompiliert
  • Die Binärdistribution ist in der Traefik-Installationsdokumentation verfügbar
  • Sowohl Traefik selbst als auch die Zieldienste lassen sich ohne Container-Engine ausführen
  • Ein Beispiel für eine systemd-Service-Unit findet sich im Traefik-Repository
  • Im praktischen Betrieb müssen zusätzlich zur Konfigurationsdatei ein eigener Benutzer angelegt und passende Dateiberechtigungen gesetzt werden

Konfiguration auf Basis von Konfigurationsdateien

  • Ohne Container lassen sich keine Docker-Labels verwenden, aber Traefik kann über den File Provider konfiguriert werden
  • Die Konfiguration ist grob in zwei Teile gegliedert
    • Statische Konfiguration: enthält Zertifikatsanbieter wie Let’s Encrypt sowie die EntryPoints, also die Ports, auf denen Traefik lauscht
    • Dynamische Konfiguration: enthält Router, Services und Middleware
  • Traefik kann Dateisystemereignisse erkennen und die dynamische Konfiguration per Hot Reload neu laden
  • Die Dokumentation bietet die zentralen Konzepte und Konfigurationsbeispiele passend zu jeder Methode
  • Begriffe wie certificate provider, entrypoint, router, service und middleware lassen sich schnell in der Traefik-Dokumentation nachschlagen

Verhalten nach der Konfiguration und Debugging

  • Wenn die Konfiguration nicht passt, zeigt Traefik Warnungen an
  • Die Standard-Logs sind nicht übermäßig umfangreich, aber gut geeignet, um nachzuvollziehen, welchen Pfad ein Request nimmt
  • Laut Praxiserfahrung war die Erstkonfiguration schnell abgeschlossen, und es traten keine zufälligen Probleme auf

TLS Passthrough und PROXY Protocol

  • Traefik unterstützt TLS Passthrough
    • Der Proxy terminiert TLS nicht, sondern leitet den Traffic an einen Webservice weiter, der eigene TLS-Zertifikate bereitstellt
    • Auch eine Konfiguration ist möglich, bei der ein Service durch Traefik hindurch selbst Let’s-Encrypt-Zertifikate anfordert
    • Der Proxy kann den weitergeleiteten Inhalt nicht einsehen
  • Die übliche Auswahl eines Virtual Hosts erfolgt über den HTTP-Host-Header, aber bei TLS Passthrough liegt dieser Header im verschlüsselten Inhalt und kann daher nicht verwendet werden
  • Stattdessen wird der Zielhost über das SNI (Server Name Indication) von TLS ausgewählt; Traefik sowie viele Webserver und Proxys nutzen dieses Verfahren
  • Auch das PROXY Protocol von HAProxy wird für Ein- und Ausgabe unterstützt
    • Damit lassen sich Informationen, die verloren gehen, weil der Benutzer zuerst den Proxy erreicht, an den Zieldienst weitergeben
    • Es gilt als sicherheitstechnisch leichter handhabbar als klassische X-Forwarded-...-Header
    • Der Zieldienst muss das PROXY Protocol ebenfalls unterstützen
    • apache2 und nginx unterstützen es, und die Liste unterstützender Dienste wächst weiter

Offene Schwächen bei der Authentifizierungsintegration

  • Unter nginx lässt sich mit Vouch Proxy eine Konfiguration umsetzen, die einige Dienste mit Azure AD, heute Microsoft Entra Authentication, schützt
  • Traefik unterstützt mit ForwardAuth ein Verfahren ähnlich zur Authentifizierungsmethode von nginx
  • Vouch Proxy funktioniert derzeit noch nicht mit Traefik; dazu gibt es ein offenes Issue
  • Man könnte eine eigene Keycloak-Instanz betreiben und mit AAD integrieren, um sie für ForwardAuth zu nutzen, aber der Aufwand für Initialkonfiguration, Absicherung und Updates ist hoch
  • traefik-forward-auth wird oft empfohlen, wurde aber zuletzt im Juni 2020 aktualisiert und benötigt Dependency-Updates, weshalb es als schwer nutzbar eingeschätzt wird
  • Mit oauth2-proxy wurden in der Vergangenheit keine guten Erfahrungen gemacht; wenn hinter einem Proxy noch ein weiterer Proxy steht, müssen HTTP/2, HTTP/3, Timeouts, Body-Größen und WebSocket-Einstellungen in jedem Zwischenproxy abgestimmt werden, was die Fehleranfälligkeit erhöht
  • Laut Update vom 2024-05-06 lässt sich oauth2-proxy auch über eine HTTP API integrieren
    • Es unterstützt nginx auth_request
    • Es unterstützt Traefik ForwardAuth
    • Dieser Ansatz wirkt wie eine Option, die der gewünschten Konfiguration näherkommt

User-Agent- und IP-Blockierung

  • Es kann Situationen geben, in denen interne Services nicht von archive.org archiviert werden sollen
  • robots.txt und ähnliche Header sind zum Blockieren von Archive.org nicht wirksam; möglich sind das Sperren des User-Agents archive.org_bot oder das Sperren von IP-Bereichen
  • Um in Traefik User-Agents oder IP-Adressen zu blockieren, sind nicht Bordmittel, sondern Drittanbieter-Plugins erforderlich
    • Plugin zum Blockieren von User-Agents
    • deny-IP-Plugin
  • Drittanbieter-Plugins müssen bei Updates berücksichtigt werden und können Sicherheitslücken schaffen, weshalb sie nicht bevorzugt werden
  • Mit der Middleware IPAllowList ist es möglich, alle IPs außer den zu blockierenden zu erlauben
    • Auch die Berechnung von IP-Bereichen ist möglich
    • Das ist nicht unbedingt schlechter als direkte Blockierung, aber wenig elegant, weil sich anhand der verbleibenden Subnetze schwer erkennen lässt, welche Bereiche gesperrt wurden

Beispielhafter Aufbau der Konfiguration

  • Das Beispiel ist in /etc/traefik/traefik.yml und /etc/traefik/dynamic.yml aufgeteilt
  • Die statische Konfiguration richtet Folgendes ein
    • EntryPoints :80 und :443
    • Umleitung aller HTTP-Endpunkte ohne Ausnahme auf HTTPS
    • Let’s-Encrypt-Zertifikatsausstellung per TLS Challenge
    • Überwachung der dynamischen Konfigurationsdatei /etc/traefik/dynamic.yml
  • Die dynamische Konfiguration enthält Folgendes
    • TCP-Routing mit TLS Passthrough für cloud.xx.xyz
    • Weiterleitung an den Service 10.33.1.2:4433 auf einem anderen Host
    • Aktiviertes PROXY Protocol Version 2
    • Für git.xx.xyz TLS-Terminierung und anschließendes Proxying auf das lokale http://127.0.0.1:3000
    • Eine Middleware, die https://xx.xyz/redirmepls auf https://google.com umleitet
    • Eine Middleware, die den Header X-Robots-Tag: noindex, nofollow, nosnippet, noarchive hinzufügt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-06
Meinungen auf Hacker News

  • Traefik ist ziemlich gut, leidet aber unter demselben schrecklichen Problem wie Ansible: Es gibt viele Dokumente und Artikel, aber man findet nicht, was man wirklich braucht.
    Ich nutze es seit v1 und verliere mich trotzdem oft in der Dokumentation, was enorm frustrierend ist. Für kleine Projekte nehme ich eher Caddy, weil dessen Dokumentation nicht so schlecht ist wie die von Traefik.
    An technische Dokumentationsautoren gerichtet: beispielzentrierte Dokumentation ist nur für Anfänger gut, die sie überfliegen. Wer mit dem Produkt vertraut ist, braucht Referenzdokumentation und vollständige Listen, keine Feldbeschreibungen, die über zehn Tutorial-Seiten verstreut sind. Konzentriert euch nicht nur auf den Onboarding-Prozess, sondern richtet euch auch an Menschen, die das Produkt täglich nutzen.
    Das ist der Punkt, der mich am meisten stört, und der Grund, warum ich Ansible so sehr hassen gelernt habe; bei Traefik ist es ähnlich, wenn auch weniger ausgeprägt.

    • Zustimmung. Ich denke, es würde allen helfen, wenn Dokumentations-Frameworks wie https://diataxis.fr bekannter wären.
    • Was mich in dieser Kategorie zuletzt genervt hat, war OpenTelemetry. Es gibt Tausende Seiten, aber fast nichts dazu, wie man grundlegende und häufige Arbeitsabläufe tatsächlich umsetzt.
    • Eines der Probleme bei Dingen, die man als Familie von YAML-Interpreter-Sprachen bezeichnen könnte, ist, dass YAML selbst eine Sprache ist, dieser Teil in der Interpreter-Dokumentation aber meist nicht dokumentiert wird.
      Es wird angenommen, dass man sehr einfache Aufgaben nur mit sehr flachen Datenstrukturen erledigt, aber die Realität sieht meist anders aus. Um solche Sprachen richtig zu nutzen, muss man das ganze Set impliziter Regeln verstehen, wie YAML zu verwenden ist; die Dokumentation geht darauf aber kaum ein.
      Es gibt zwar spezielle Konfigurationsdokumentation für jedes Modul, aber wie man Standardkonfigurationen verwendet, wie man zurückgegebene Daten behandelt oder sie mit etwas nur leicht Komplexerem kombiniert, ist selten klar. Es fühlt sich an, als würde man einem ein Dutzend Ein-Absatz-Beispiele pro Eintrag wie einen Haufen Zutaten hinwerfen und sagen: Back einen Kuchen.
      Bei mehreren YAML-Interpreter-Systemen, die ich verwendet habe, war die Erfahrung fast immer dieselbe. Erst nach Hunderttausenden Zeilen YAML konnte ich die Arbeit erledigen, aber die Dokumentation war kaum mehr wert als eine Liste von Einstellungen.
    • Ansible sorgt definitiv dafür, dass man ständig in der Dokumentation nachschlägt.
      Trotzdem habe ich mit ansible-doc einen ziemlich brauchbaren Workflow gefunden; meine häufig genutzten Aliasse sind alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'.
      Zuerst suche ich mit adls schnell nach dem passenden Befehl, schaue mir dann mit ad die Dokumentation an und springe fast immer direkt ans Ende (G), um die Beispiele anzusehen. Meist steht die gesuchte Antwort genau dort.
      Das Schreiben von Ansible-Skripten hängt sehr stark von der Dokumentation ab; deshalb sollte dieser Nachschlageprozess schon im Standardzustand besser unterstützt werden, mit einer Oberfläche, über die man schnell findet, was man braucht, ohne haufenweise Aliasse anzulegen.
    • Pydantic fällt für mich ebenfalls in diese Kategorie. Die Maintainer sind der Meinung, es solle nur eine Informationsquelle geben, und weigern sich, API-Referenzdokumentation zu erstellen.
      Klar, es ist ihr Projekt, aber jedes Mal, wenn ich eine Methode eines Objekts nachschlagen will, muss ich mich durch lange Prosaseiten wühlen. Manchmal ist es einfacher, einfach den Source Code zu lesen.

  • Wir haben Traefik zwei Jahre lang in Produktion eingesetzt. Früher nutzten wir NGINX, sind aber wegen der automatischen Let's-Encrypt-Integration zu Traefik gewechselt – und ich bereue diese Entscheidung.
    Die Traefik-Dokumentation spricht weder mich noch mein Team wirklich an. Sie ist umständlich, und Traefik verhält sich ohne brauchbare Logs merkwürdig.
    Wenn man zum Beispiel versucht, Zertifikate neu zu erstellen, schlägt das sporadisch fehl und die Produktion ist dann unten, ohne dass klar ist, wann sie wiederhergestellt wird. Wir wechseln gerade zurück zu NGINX.

    • In dieser Hinsicht war NixOS wirklich hilfreich. Man kann es mit ein paar Zeilen in configuration.nix einrichten; intern werden lego(1) und Let's Encrypt verwendet.
      security.acme = { acceptTerms = true; defaults.email = "admin-email@provider.net"; certs."mydomain.example.com" = { domain = "*.mydomain.example.com"; dnsProvider = "cloudflare"; environmentFile = "/path/to/cloudflare/password"; }; };
      services.caddy.enable = true;
      services.caddy.virtualHosts."subdomain1.mydomain.example.com" = { extraConfig = '' reverse_proxy 127.0.0.1:1234 ''; useACMEHost = "mydomain.example.com"; };
      Mit nginx dürfte die Konfiguration ziemlich ähnlich sein. https://github.com/go-acme/lego
    • Ich bin ebenfalls wegen der eingebauten Unterstützung für DNS-Challenges und Wildcard-Zertifikate von NGINX zu Traefik gewechselt. Ich habe Stunden damit verbracht, es für eine Domain der Firma einzurichten, und obwohl ich exakt dieselbe Konfiguration verwendet habe, die zu Hause perfekt funktioniert, passierte in der Praxis gar nichts.
      Es war derselbe Domain-Registrar, dieselbe API, dieselbe Docker-Konfiguration, und alle Logs waren aktiviert, aber es gab keinerlei Hinweis darauf, warum das Zertifikat nicht erstellt wurde. Es fiel einfach auf das generierte Standardzertifikat zurück, als hätte es es gar nicht erst versucht.
      Nach zwei Troubleshooting-Sitzungen und stundenlanger Suche gab ich auf und musste eine selbstsignierte Zertifikatsdatei verwenden. Es ist wirklich frustrierend, wenn es keinerlei Informationen dazu gibt, warum etwas nicht funktioniert, und es nach einem stillen Fehlschlag einfach auf ein Fallback-Verhalten umschaltet.
      Insgesamt war das für mich das größte Problem mit Traefik. Wenn es funktioniert, ist es großartig, aber wenn nicht, war es immer schwierig, das Problem zu beheben oder die nötigen Informationen in der Dokumentation zu finden. In der Firma wollen wir gegen Jahresende anfangen, Traefik in Produktion einzusetzen, daher hoffe ich, bis dahin mit Traefik vertrauter zu werden.
    • Wenn ich ein API-Gateway brauche, habe ich einfach den in Go eingebauten Reverse Proxy verwendet. Man kann ihn leicht in die gewünschte Form bringen, und Bibliotheken für übliche Aufgaben wie CORS, Rate Limiting und Retries findet man ebenfalls leicht.
      Das Beste daran ist, dass es keine Konfigurationssprache gibt. Man schreibt einfach Go.
    • Vielleicht kennst du sie schon oder sie passten nicht, aber es gibt ziemlich viele Docker-Hilfscontainer, die Let's-Encrypt-Zertifikate für nginx-Docker-Container automatisieren.
    • Beim ersten Einsatz von Traefik hatte ich viele ähnliche Probleme. Wenn man zum Beispiel TLS-01-Validierung nutzt und die DNS-Records nicht vor dem Anwenden der Konfiguration eingerichtet sind, kann das enormen Stress verursachen. Auch die zu geringe Menge an Logs war frustrierend.
      Später habe ich gelernt, dass Let's Encrypt nach N fehlgeschlagenen Validierungsversuchen eine erneute TLS-01-Validierung für eine Weile ablehnt, wenn DNS nicht korrekt eingerichtet ist; dein Problem klingt nach etwas in dieser Richtung.
      Nach dem Wechsel auf DNS-01-Validierung wurde die Erfahrung schlagartig deutlich besser. Man kann auch Zertifikate für Dienste erstellen, die nicht öffentlich exponiert sind, und es ist weit weniger Orchestrierung nötig als beim TLS-01-Ansatz.
      Wenn der DNS-Anbieter ordentlich funktioniert, bekommt man bei Problemen wahrscheinlich schon einen API-Fehler, bevor Let's Encrypt den Record validiert, und der Fehler tritt viel früher auf als der Backoff nach fehlgeschlagenen Let's-Encrypt-Prüfungen. Inzwischen bin ich fast fest entschlossen, Let's Encrypt nur noch mit DNS-01-basierter Validierung zu nutzen, egal ob ich Traefik, Caddy, Nginx oder einen anderen Reverse Proxy verwende. Und wenn ich TLS-01 nutzen muss, werde ich unbedingt mit der Staging-API prüfen, ob von Anfang an alles korrekt eingerichtet ist.
      Nebenbei: Wenn man in Traefik ein Let's-Encrypt-Staging-Zertifikat erstellt, gibt es keine gute Möglichkeit, dieses Zertifikat ungültig zu machen. Man muss das ACME-JSON bearbeiten, das Zertifikat entfernen und Traefik neu starten, damit die Änderung übernommen wird. Vielleicht geht es auch mit SIGHUP, aber ausprobiert habe ich das nicht.
      Insgesamt gibt es viele seltsame stille Fehlschläge und Verhaltensweisen, aber der größte Schmerzpunkt ist, dass Fehler abhängiger Dienste undurchsichtig gemacht werden.

  • Ich nutze Caddy statt Traefik. Für mich ist ein Caddyfile viel einfacher zu verwalten als Traefiks YAML-Konfiguration, und ich pflege jeweils eigene Caddyfiles für lokale, Produktions- und On-Premises-Deployments.
    Es gibt auch viele hervorragende Plugins, und wir nutzen das coraza-WAF-Plugin für Caddy, das gut funktioniert.

    • In meinem Self-Hosting-Setup bin ich von Traefik zu Caddy und caddy-docker-proxy gewechselt.
      Es bietet alle Funktionen, die ich brauche, und ist dabei viel einfacher.
      https://github.com/lucaslorentz/caddy-docker-proxy
    • Ich mag Caddy, aber ich wünschte, die Dokumentation für Produktions-Deployments wäre besser. Besonders bei Best Practices zu Storage und Konfigurationsmanagement bleiben zu viele Fragen offen.
      Zum Beispiel, wie man lokalen Storage behandeln sollte, wenn man externen Storage verwendet. Es heißt zwar, man könne ihn als zustandslos betrachten, aber vielleicht stimmt das nicht.
      Am Ende muss man beten, dass die Person, die das benötigte Modul gebaut hat, wirklich weiß, was sie tut. Denn auch dort gibt es keinen Dokumentationsstandard. Die Maintainer sollten bei zufälligen Modulen, die Kernfunktionen bereitstellen, aber null Dokumentation haben – etwa einem S3-Storage-Backend –, auf die Bremse treten.
    • Wenn man kein komplexes Zeug wie Service Discovery oder Auto-Scaling braucht oder es selbst per Skript abdecken kann, kann man Traefik, Docker Swarm, Kubernetes usw. guten Gewissens überspringen und einfach Caddy verwenden. Caddy kann wirklich das meiste und macht es gut.

  • Bei einem bescheidenen Bedarf von ein paar Docker-Hosts und ein paar Dutzend Containern frage ich mich, warum man Traefik statt nginx verwenden sollte. Ich nutze https://github.com/NginxProxyManager/nginx-proxy-manager – bringt Traefik in so kleinem Maßstab überhaupt Vorteile?

    • Ich würde hier https://github.com/caddyserver für die beste Wahl halten. SSL-Zertifikate werden automatisch erledigt, es ist sehr leichtgewichtig, und die Konfigurationssyntax ist sehr klar
    • Mir gefällt das Hot Reloading von Traefik. Wenn man einen Dienst, also eine proxied App, verstecken, eine neue Route – in Traefik-Terminologie einen router – hinzufügen oder Middleware wie Basic Auth, HTTPS-Redirects oder Header-Manipulation ergänzen will, legt man einfach eine Datei ab, und sie wird automatisch übernommen. Man muss weder Traefik noch den jeweiligen virtuellen Host neu laden
      Ehrlich gesagt mag ich die nginx-Syntax nicht, und Traefik wirkte irgendwie glänzend. Wegen Let’s-Encrypt-Erneuerungen und Containern bin ich eingestiegen, wegen der Art der Konfiguration bin ich geblieben
    • Wenn dein bestehendes Setup gut funktioniert, sehe ich keinen Grund zu wechseln, der dir wirklich etwas bringt
      Ich würde einen Umstieg wohl erst dann in Betracht ziehen, wenn ich eine Funktion brauche, die Traefik bietet und Nginx nicht hat
    • Ich nutze ebenfalls NginxProxyManager und habe 8 Hosts, aber ich habe noch keine Antwort gesehen, die erklärt, welche Vorteile caddyserver oder traefik gegenüber NPM bieten
    • Zustimmung. Nginx-Konfiguration ist einfach, und wenn sie einmal richtig steht, kann man sie vergessen. Meist kopiert man ohnehin aus einer anderen vorhandenen Konfiguration und fügt sie ein
      Dass automatisches Let’s Encrypt als Verkaufsargument dient, wirkt auch etwas seltsam, wo Certbot überall verfügbar ist und mehr Szenarien unterstützt. Die Verkaufsargumente von Traefik und Caddy kommen bei mir nicht richtig an, weil es nicht so ist, dass sie es nur einfacher machen als eine ohnehin breit unterstützte Alternative

  • Vor ein paar Wochen habe ich einen Reverse Proxy ausgewählt und mich am Ende wegen der Einfachheit für Caddy entschieden. Allerdings sind Traefiks automatische Container-Erkennung und die Referenzierung über Labels ziemlich gut, und für Caddy gibt es ein Plugin, das dasselbe macht
    Ich habe den Artikel gelesen, bin aber noch nicht überzeugt, dass Traefik für mich Vorteile gegenüber Caddy hat. Für andere mag es welche geben, daher würde ich gern Meinungen hören

  • Bemerkenswert ist auch, dass Traefik standardmäßig in K3s konfiguriert ist. Dadurch ist K3s für mich zur schnellsten Methode geworden, einen K8s-Testcluster hochzuziehen, und man kann den Cluster wie Vieh behandeln
    Man muss nur Deployments und die zugehörigen Services als NodePort hinzufügen, dann kann man auf die App zugreifen, ohne sich um den Ingress-Controller zu kümmern
    Ich starte K3s-Cluster per Shell-Skript und teste bei Bedarf die App, die ich als Positionsargument angebe. Dabei nutze ich die temporäre Container Registry von ttl.sh. Wenn dasselbe Skript fertig ist, entfernt es auch den Cluster wieder

  • Ich überlege, meinen Reverse Proxy fürs Self-Hosting auf Traefik umzustellen. Anders als der Autor betreibe ich containerisierte Workloads mit Docker Compose und nutze derzeit Caddy zusammen mit dem hervorragenden caddy-docker-proxy-Plugin
    Was ich aktuell bekomme, ist ein Reverse Proxy mit Docker-Label-basierter Konfiguration, automatische Erkennung neuer Workloads, TLS-Zertifikate und automatische DNS-Konfiguration über das caddy-dynamicdns-Plugin. Selbst wenn mein ISP mir eine andere IP gibt, muss ich mir kaum Sorgen machen, den Zugriff zu verlieren
    Allerdings wird Caddy jedes Mal komplett neu gestartet, wenn ein neuer Workload hinzugefügt oder neu gestartet wird, wodurch der Zugriff kurzzeitig unterbrochen ist. Caddy kann bestehende Verbindungen nicht an die neue Instanz übergeben
    Außerdem ist die Nutzung von Wildcard-Zertifikaten nicht einfach genug. Ich möchte nicht, dass alle Workloads über Certificate-Transparency-Logs der ganzen Welt offengelegt werden, also nutze ich Wildcard-Zertifikate; dann kann ich aber nicht die einfache Caddyfile-Syntax verwenden, bei der pro Hostname ein Zertifikat genutzt wird. Ich weiß, dass daran in Caddy gearbeitet wird, aber noch ist es so
    Jedenfalls habe ich Traefik in k8s-Umgebungen genutzt und fand es ziemlich gut, also will ich es auch privat einmal ausprobieren. Ich hoffe, diese Aussage hält niemanden davon ab, Caddy auszuprobieren. Caddy ist tatsächlich wirklich gut

    • Für Einzweck-Hosts und Ähnliches nutze ich Caddy, aber auf das von dir beschriebene Problem würde ich zu 100 % Traefik werfen. Ich nutze es tatsächlich für den Eingang in meinen k8s-Cluster und betreibe es in Entwicklungsumgebungen, um localtest.me zusammen mit Hostnamen zu verwenden
      Einen Test ist es wert. Beide sind in unterschiedlichen Bereichen hervorragend
    • Ich nutze rootless Docker Compose + Traefik. Wildcard-Zertifikate waren damit wirklich schmerzfrei. Allerdings betreibe ich meinen eigenen DNS-Server und verwende für die Let’s-Encrypt-DNS-Challenge RFC2136 DDNS
      Plugins sind eigentlich nicht nötig. Ich habe ein Ansible-Playbook, das all das auf einer VM einrichtet und sogar Templates für Compose-Dateien erzeugt, und ein weiteres Playbook, das auf dem Server alles außer Daten und Mounts entfernt. Für Backups nutze ich restic zusammen mit einem Custom-Skript, das Dateien, mehrere DBs usw. an mehrere Orte sichern kann
      Früher habe ich k3s ausgerollt, aber für Self-Hosting war mir das zu viel und zu komplex. Ich will einfach schnell deployen und mich nicht selbst um Zertifikate kümmern müssen
    • Caddy habe ich nicht ausprobiert; ich nutze Traefik und verwende die Erkennung von Docker-Properties für die Konfiguration und die automatische Erneuerung von TLS-Zertifikaten. Zu dynamischem DNS weiß ich nicht viel und nutze es in Traefik nicht. Soweit ich mich erinnere, war kein Neustart nötig, wenn Container hinzugefügt oder entfernt wurden
    • Ich habe caddy-docker-proxy in Produktion genutzt, und beim Laden einer neuen Konfiguration hat Caddy keine Verbindungen getrennt
      Ich habe es gerade lokal überprüft, und es funktioniert einwandfrei
    • Das ist eine enorme Einschränkung. Ich habe noch nie von einem Reverse Proxy gehört, der Verbindungen abbrechen muss, weil er zur Aktualisierung der Konfiguration neu startet. Das ist normalerweise eines der ersten und grundlegendsten Dinge, um die man sich bei einem solchen Serverdesign kümmert

  • Ich habe Traefik viel genutzt, aber irgendwann hatte ich es satt, nur für einen Reverse Proxy mit docker-compose-Labels, Hierarchien und unzähligen Zeilen zu hantieren. Dann habe ich Caddy entdeckt und nie zurückgeschaut
    Vermutlich war ich einfach nicht die Zielgruppe von Traefik. Was ich brauche, ist ein Reverse Proxy mit aktiviertem HTTPS oder vielleicht eine Basic-Auth-Schicht. In Caddy ist beides jeweils eine Zeile, sehr knapp, und es gibt keine Hierarchie, die ich bis heute nicht verstehe

  • Ich nutze Traefik seit Jahren für alles, was ich selbst hoste.
    Die dynamische Erkennung und die Docker-Label-Funktion habe ich allerdings aufgegeben, weil sie zu heikel und das Debugging nervig war.
    Stattdessen erzeuge ich mit einer Template-Engine statische Konfigurationsdateien. Fast alle Services sind eine Kombination aus Host/Target/Port, daher lassen sich die entsprechenden Abschnitte sehr leicht erstellen, und außer der TLS-Behandlung gibt es auch keine komplizierte Middleware. Es sieht so aus, als hätte der Autor des verlinkten Artikels denselben Weg gewählt.
    Die Konfiguration wird per Ansible-Skript erzeugt, dann auf die Maschine kopiert, auf der Traefik läuft, und Traefik überwacht das Verzeichnis mit dieser Datei und lädt sie bei Änderungen automatisch neu. Das hat bisher sehr gut funktioniert.

  • Wir verwenden Traefik in Produktion zusammen mit Containern, und was mir am besten gefällt, ist, dass die Konfiguration als Container-Labels mitgeliefert wird. Dadurch muss man die Traefik-Konfiguration selbst kaum ändern.
    Der größte Nachteil ist herauszufinden, wie man den Namen aussprechen soll. Offenbar spricht man ihn einfach wie normales „traffic“ aus, aber ich ertappe mich ständig dabei, ihn eher wie „trey-feek“ sagen zu wollen.

    • Dem Label-Ansatz stimme ich sehr zu. Beim ersten Schreiben ist es wegen Escaping und Ausführlichkeit etwas schwieriger, aber der Bereich, den man nachverfolgen muss, schrumpft enorm.
      Die Kombination aus Traefik und Docker Compose ist meiner Ansicht nach ein guter Sweet Spot für kleines Self-Hosting, bevor es groß genug für k8s wird, besonders wenn man weniger Server hat, als eine hochverfügbare k8s-Control-Plane allein schon verbrauchen würde.
    • Wir nutzen es ebenfalls in Produktion. Die Leute mögen darüber lachen, aber ein Name, der auf dem Papier cool und einzigartig aussieht, in der Praxis aber schrecklich ist, ist ein großer Nachteil.
      Die Menge an Stirnrunzeln und Gelächter, die ich von Kollegen bekommen habe, war enorm, und sie hat Einführung und Nutzung des Produkts behindert.
      Wir haben es „tray-feek“ genannt, und das war noch okay, aber als wir mit dem offiziellen Support telefonierten, hieß es, man spreche es genauso aus wie normales „traffic“. Dadurch entstehen jedes Mal, wenn man über diesen Proxy spricht, Sätze wie: „Wir nehmen traffic über den öffentlichen Load Balancer an, und das native Load Balancing von traffic schickt traffic an die Pods von traffic.“ Das klingt dumm, und es ist tatsächlich dumm.
    • Ich spreche es einfach „traffic“ aus. Bei deren verdammten Kopfspielchen mache ich nicht mit.
    • Der größte Nachteil ist meiner Meinung nach, dass Traefik nichts von einem Container oder seinen Labels weiß, wenn der Container nicht existiert oder nicht läuft.
      Andernfalls ließen sich coole Dinge wie Wartungsseiten oder das Hochfahren eines Containers beim ersten Request nach Inaktivität leichter umsetzen.
      Deshalb denke ich darüber nach, ein Plugin zu schreiben, das weiß, wo die Compose-Dateien liegen, und sie direkt von dort lesen kann.
    • ae kommt y oder hi am nächsten. Daher wäre meine Vermutung Tryfik, andernfalls Trayfik. Mit europäischem fik könnte es auch feek sein.