Warum man Traefik auch ohne Container genauer betrachten sollte
Bekannte Punkte zu Traefik
- Traefik hat das Ziel, im Microservices-Umfeld zu helfen.
- Viele YouTuber berichten, dass sie auf Container-Infrastrukturen wie Docker oder Kubernetes setzen.
- Traefik läuft in Containern, und durch das Mounten des Docker-Sockets in den Traefik-Container kann es automatisch andere Container erkennen, die über Traefik nach außen bereitgestellt werden sollen.
- Über Labels kann das Proxy-Verhalten für bestimmte Container konfiguriert werden.
- Traefik fordert automatisch TLS-Zertifikate bei Let's Encrypt an und macht einen Service sofort nutzbar, sobald ein neuer Container erkannt wird.
Warum Traefik auch ohne Container sinnvoll ist
Häufige Fehlannahme: Es braucht keine Container-Engine
- Traefik muss nicht auf einer Container-Engine laufen, und der Service muss ebenfalls nicht auf einer Container-Engine laufen.
- Traefik ist in Go geschrieben und wird als einzelne ausführbare Datei kompiliert.
- Bei Software, die in Go geschrieben und als einzelne Binärdatei kompiliert wird, fühle ich mich immer sehr gut.
- Deployment ist einfach und ermöglicht vollständige Kontrolle.
Häufige Fehlannahme: Es werden auch Konfigurationsdateien unterstützt
- Ohne Container kann man keine Container-Labels nutzen, und Labels sind ohnehin oft verwirrend und schwer lesbar.
- Traefik kann auch über Konfigurationsdateien betrieben werden.
- Traefik teilt die Konfiguration auf in einen „statischen“ Bereich mit Zertifikat-Providern (z. B. Let's Encrypt) und Entry Points (die Ports, auf denen Traefik lauscht) sowie einen „dynamischen“ Bereich mit Routern, Services und Middleware.
- Traefik reagiert auf Dateisystem-Ereignisse und kann den dynamischen Teil per Hot Reload neu laden.
Gut dokumentiert
- Traefik erklärt die zugrunde liegenden Konzepte klar.
- Am Anfang der jeweiligen Seite findest du ein Konfigurationsbeispiel für die gewählte Instanzkonfiguration.
- Die Dokumentation deckt die meisten Anforderungen ab.
- Die Sidebar ist hilfreich.
Traefik wirkt robust und gut gestaltet
- Traefik warnt, wenn die Konfiguration nicht sinnvoll ist, und hat bisher keine Zufallsfehler gezeigt.
- Traefik scheint standardmäßig nicht zu viele Logs zu schreiben; dennoch ist es leicht nachzuvollziehen, wie Requests verarbeitet werden, sodass man schnell loslegen kann, ohne zu frustrieren.
Features, die wirklich überzeugen
TLS Passthrough und PROXY Protocol
- Traefik unterstützt TLS Passthrough sowie das PROXY Protocol von HAProxy (Inbound und Outbound).
- TLS Passthrough bedeutet, dass Traffic an einen Webservice weitergeleitet werden kann, der eigene TLS-Zertifikate bereitstellt.
- Der Service kann TLS-Zertifikate direkt bei Let's Encrypt anfragen, ohne dass TLS am Proxy terminiert wird.
- Das PROXY Protocol ist eine sichere Methode, um Informationen weiterzugeben, die beim ersten Kontakt am Proxy verloren gehen könnten.
- Das PROXY Protocol muss auch vom Zielservice unterstützt werden; Apache2 und Nginx (also PHP) tun das, und die Liste der unterstützenden Services wächst.
Nachteile bei der Nutzung von Traefik
Authentifizierung
- In NGINX schützt man bestimmte Dienste mit Vouch Proxy und Azure AD.
- Traefik unterstützt ein dem NGINX-Ansatz ähnliches ForwardAuth, aber Vouch Proxy funktioniert in Traefik noch nicht.
- Man kann eine Keycloak-Instanz ausrollen, sie mit AAD integrieren und dann für ForwardAuth einsetzen, muss aber diese Keycloak-Instanz zuerst sicher und aktuell einrichten.
- traefik-forward-auth wird häufig empfohlen, wurde aber zuletzt im Juni 2020 aktualisiert; der Entwickler ist auf GitHub nicht mehr aktiv und die Dependencies müssten aktualisiert werden.
- Frühere Erfahrungen mit oauth2-proxy waren negativ.
- HTTP/2/3, Timeouts, Request-Body-Größe und WebSocket erfordern bei jedem Proxy zwischen Nutzer und Service eine Konfiguration, weshalb Proxying vor einem weiteren Proxy schnell fehleranfällig wird.
- Traefik ForwardAuth wirkt simpel, daher müsste man entweder ein eigenes kleines Tool für die AAD-Integration schreiben oder traefik-forward-auth forken, auditieren und danach die Dependencies aktualisieren.
User-Agent- und IP-Blockierung
- Wir möchten nicht, dass archive.org interne Services archiviert.
- robots.txt und ähnliche Header wirken nicht gegen Archive.org, daher bleibt als Blockiermöglichkeit nur, den User-Agent
archive.org_bot zu blockieren oder IP-Ranges zu sperren.
- In Traefik kann User-Agent oder IP-Adresse nur über Drittanbieter-Plugins blockiert werden.
- Drittanbieter-Plugins sind im Hinblick auf Updates zu berücksichtigen und können Sicherheitslücken verursachen, daher sind sie nicht bevorzugt.
- Mit der IPAllowList-Middleware kann man IPs blockieren und alles außer den IPs, die blockiert werden sollen, erlauben.
- IP-Ranges lassen sich berechnen und sind nicht schlechter als direktes Blockieren, aber man sieht nur den Restbereich und erkennt nicht klar, welche Subnetze genau gesperrt sind, daher wirkt es nicht sehr elegant.
Meinung von GN+
- Traefik wirkt wie eine attraktive Reverse-Proxy-Lösung, unabhängig davon, ob man Container einsetzt. Besonders vorteilhaft ist, dass es in Go geschrieben und als einzelne Binärdatei kompiliert wird, was Deployment und Verwaltung erleichtert.
- Die Dokumentation ist ebenfalls gut und dürfte helfen, die Konzepte von Traefik zu verstehen und passende Konfigurationsbeispiele zu finden.
- Auch erweiterte Funktionen wie TLS Passthrough oder PROXY Protocol scheinen sehr gut unterstützt.
- Bei der Authentifizierung scheint es jedoch noch keine wirklich zufriedenstellende Lösung zu geben; eher wäre es sinnvoll, einen eigenen Auth-Server zu entwickeln oder bestehende Projekte zu verbessern.
- Eine native Bereitstellung von User-Agent- oder IP-Blocking wäre wünschenswert, aber jenseits externer Plugins scheint es dafür keinen eleganten Weg zu geben.
- Als Alternative zu NGINX lohnt sich ein Blick auf Traefik definitiv. Besonders für Nutzer, denen NGINX-Konfigurationen zu komplex erscheinen, dürfte die Schlichtheit von Traefik attraktiv sein.
1 Kommentare
Hacker News-Kommentare