Slovník pojmů

Traefik

Traefik stojí na vstupu do infrastruktury a směruje HTTP, TCP nebo UDP provoz ke správným službám. Jeho silnou stránkou je průběžná aktualizace routingu podle stavu prostředí, nikoli automatická bezpečnost aplikace.

Stručná definice

Dynamická proxy mezi klientem a běžícími službami.

Traefik je konkrétní implementace reverse proxy. Klient komunikuje s veřejnou adresou Traefiku a nemusí znát interní adresu ani port aplikace. Traefik vybere odpovídající router, aplikuje nakonfigurované middleware a předá požadavek službě. Není webovým aplikačním frameworkem a nezpracovává business logiku backendu.

Označení dynamická znamená, že routing configuration může přicházet z provideru a měnit se bez restartu proxy. V Docker prostředí Traefik například sleduje Docker API a čte labels kontejnerů; Docker však není podmínkou. Stejný princip lze použít se souborovou konfigurací, Kubernetes nebo jiným podporovaným providerem.

Jaký problém řeší

Jedna vstupní vrstva pro služby, které se mohou průběžně měnit.

Když za jednou veřejnou IP adresou běží více webů, API nebo instancí aplikace, je potřeba bezpečně rozhodnout, kam každý požadavek patří. Ruční přepisování konfigurace po každém vzniku či zániku kontejneru je v dynamickém prostředí pomalé a náchylné k chybám.

příjem HTTP a HTTPS provozu na společných portech 80 a 443
směrování domén a cest k různým aplikacím, administracím a API
průběžné načítání routing configuration z providerů
ukončení TLS a volitelné získávání certifikátů přes ACME
rozložení provozu mezi více instancí jedné služby
aplikace redirectů, hlaviček, rate limitu nebo autentizačního middleware před backendem

Praktický příklad

E-shop objevený přes Docker provider

Traefik poslouchá na entrypointech web a websecure. Docker provider zjistí kontejner aplikace a z jeho labels sestaví router pro shop.example.cz. Router přijímá HTTPS provoz, použije určený certificate resolver a předá požadavek službě na interním portu 8080.

V install configuration je vhodné nastavit providers.docker.exposedByDefault=false, aby se publikovaly jen výslovně povolené kontejnery. Labels nejsou vhodné pro hesla, certifikáty ani jiné secrets. Ukázka předpokládá, že entrypointy a certificate resolver už jsou bezpečně nakonfigurované mimo labels aplikace.

Docker Compose / Traefik labels

services:
  shop:
    image: example/shop:1.0
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.shop.rule=Host(`shop.example.cz`)"
      - "traefik.http.routers.shop.entrypoints=websecure"
      - "traefik.http.routers.shop.tls=true"
      - "traefik.http.routers.shop.tls.certresolver=letsencrypt"
      - "traefik.http.services.shop.loadbalancer.server.port=8080"

Jak funguje

Internet → entrypoint → router → middleware → service → App A / App B

Tok odděluje síťový vstup, rozhodnutí o routingu a cílové instance. Jednotlivé části mohou vzniknout z různých providerů, ale při odkazu mezi nimi se používá také namespace provideru.

Entrypoint přijme spojení Traefik poslouchá na určené adrese, portu a protokolu, typicky na 80/TCP a 443/TCP. Entrypoint je síťový vstup, ne cílová aplikace.
Provider dodá routing configuration Docker provider, Kubernetes provider nebo soubor popíše dostupné routery, middleware a služby. Provider může změny sledovat a průběžně předávat Traefiku.
Router vybere službu Pravidlo jako Host nebo PathPrefix rozhodne, zda požadavek patří danému routeru. Nejde o router uvnitř PHP či frontendové aplikace.
Middleware zpracuje požadavek Může provést redirect, upravit hlavičky, omezit tempo provozu nebo zajistit infrastrukturní autentizaci. Middleware se provádějí v nakonfigurovaném pořadí.
Service předá provoz backendu Service obsahuje load balancer a jednu či více instancí aplikace. Traefik mezi ně rozdělí provoz, ale samotné instance nevytváří ani nesynchronizuje jejich data.
Odpověď se vrátí klientovi Traefik ji předá zpět a podle konfigurace zapíše access log, metriky nebo trace. Aplikační chybu přitom musí být možné odlišit od chyby proxy či nedostupného backendu.

Hlavní části a koncepty

Install configuration určuje běh proxy, routing configuration cestu požadavku.

Současná dokumentace rozlišuje dvě kategorie konfigurace. Dřívější názvy static a dynamic configuration se mohou stále objevovat ve starších návodech.

Install configuration

Nastavení vyžadující restart, zejména entrypointy, providery, API a dashboard nebo logování. Lze je zadat souborem, argumenty či proměnnými prostředí podle zvoleného způsobu instalace.

Routing configuration

Routery, middleware, služby a TLS certifikáty, které lze aktualizovat za běhu. Zdroj konfigurace určuje provider a některé možnosti se mezi providery liší.

Entrypoint a router

Entrypoint otevře síťový vstup. Router vyhodnotí doménu, cestu, hlavičku nebo jiné pravidlo a spojí požadavek se službou. Aplikační router teprve potom vybírá controller či stránku v backendu.

Middleware

Volitelný krok může měnit požadavek nebo odpověď či rozhodovat o dalším průchodu. Infrastrukturní autentizace a rate limiting nenahrazují business autorizaci a validaci aplikace.

Service a load balancer

Service popisuje cílové servery a distribuci provozu. Load balancer je součástí služby i tehdy, když má jediný server; clustering, replikaci dat ani sdílení session tím Traefik nevytváří.

Provider a service discovery

Provider čte stav externího systému a skládá z něj routing. DNS pouze překládá jména na síťové údaje a service discovery ani pravidla Traefiku nenahrazuje.

Výhody, omezení a časté chyby

Automatizovaný routing pomáhá provozu, ale zvětšuje dopad chybné konfigurace.

Konkrétní přínosy

routing se může přizpůsobovat vzniku a zániku služeb bez ručního restartu proxy
jednotná HTTP a TLS hranice pro více aplikací a API
přirozená integrace s dynamickými platformami i možnost souborové konfigurace
load balancing mezi instancemi, volitelné health checks a společná provozní observabilita

Omezení a chyby

automatická konfigurace neznamená automaticky bezpečné vystavení služby
příliš široké Host nebo PathPrefix pravidlo může zpřístupnit jiný backend
neomezený přístup k Docker socketu představuje závažné riziko pro hostitele
veřejný dashboard nebo API mohou odhalit aktivní routing a citlivý provozní kontext
secrets uložené v Docker labels se mohou dostat k uživatelům s přístupem k Docker API
middleware nenahrazuje validaci, autentizaci a autorizaci uvnitř aplikace

Praktické použití a porovnání

Traefik dává největší smysl tam, kde se routing mění spolu se službami.

Typickým příkladem je několik Docker aplikací za společnými porty 80/443 nebo ingress do Kubernetes. Pro jednu stabilní službu může být přínos dynamické konfigurace menší a jednodušší explicitní proxy konfigurace přehlednější.

nginx i Traefik mohou fungovat jako reverse proxy a load balancer. nginx je obecný webový server s širokými možnostmi explicitní konfigurace a obsluhy statického obsahu; Traefik klade větší důraz na providery a průběžně odvozovaný routing. Volba závisí na prostředí, nikoli na tom, že by jeden nástroj byl obecně lepší.

Reverse proxy popisuje roli před backendem, zatímco Traefik je konkrétní nástroj. Aplikační server zpracovává kód a business logiku; Traefik k němu směruje provoz. Service discovery zjišťuje dostupné služby a jejich metadata, zatímco DNS řeší překlad jmen. Load balancer rozděluje požadavky mezi již existující instance, ale instance nevytváří ani nesynchronizuje.

HTTPS a TLS lze ukončit přímo v Traefiku. Automatické získání certifikátu ale vyžaduje správně nastavený certificate resolver a ACME challenge, DNS záznamy vedoucí na Traefik a dostupnost potřebného vstupu. Samotné zapnutí TLS pole v routeru tyto předpoklady nevytvoří.

Na co myslet v provozu

Publikované služby, oprávnění provideru a pravidla routingu musí být dohledatelné.

Traefik je veřejná infrastrukturní hranice. Jeho konfigurace proto potřebuje stejnou míru review, testování a monitoringu jako ostatní části nasazení.

povolit pouze providery a entrypointy, které prostředí skutečně potřebuje
u Docker provideru preferovat explicitní publikování služeb a omezit přístup k Docker API
chránit dashboard a API autentizací, autorizací i síťovým omezením; insecure režim patří jen do vývoje
testovat kolize pravidel, priority routerů, přesměrování a obnovu TLS certifikátů
sledovat chyby načtení konfigurace, stav backendů, stavové kódy a dobu odpovědi
verzovat install i file-based routing configuration, ale neukládat do ní secrets

Časté otázky

Traefik bez záměny infrastrukturních odpovědností

Vyžaduje Traefik Docker?

Ne. Docker je jeden z providerů. Traefik může získávat konfiguraci také například ze souborů nebo Kubernetes a může pracovat i s ručně popsanými backendy.

Je Traefik totéž co load balancer?

Ne úplně. Load balancing je jedna z jeho funkcí. Traefik navíc přijímá provoz na entrypointech, vyhodnocuje routery, spouští middleware a může ukončovat TLS.

Je router v Traefiku aplikační routa?

Ne. Traefik router vybírá infrastrukturní službu podle vlastností požadavku. Router aplikace pak uvnitř backendu vybírá konkrétní controller, handler nebo stránku.

Zajistí Traefik automaticky HTTPS certifikát?

Pouze po správném nastavení TLS routeru, certificate resolveru a ACME challenge. Doména musí směřovat na Traefik a infrastruktura musí umožnit zvolený způsob ověření.

Je bezpečné připojit Docker socket přímo do kontejneru Traefiku?

Přímý přístup k Docker API je citlivé oprávnění a musí odpovídat modelu rizik. Je potřeba omezit dostupnost socketu či API a počítat s dopadem případné kompromitace proxy.

Jak navrhuji provozní hranice

Proxy, aplikace a interní služby mají mít čitelné odpovědnosti.

U návrhu infrastruktury odděluji veřejný vstup, aplikační logiku a datové služby tak, aby změna routingu nezpřístupnila nechtěnou část systému.

Jak navrhuji hranice aplikací a infrastruktury Nezávazně probrat projekt