Etykiety Traefika po kolei, wraz z pułapką dolara

Etykiety Dockera opisują kilka połączonych obiektów Traefika. Router HTTP wybiera żądania według reguły, usługa określa cel, a middleware przetwarza żądania lub odpowiedzi. Obiekty łączą odwołania; identyczne nazwy nie tworzą automatycznie powiązania.

Diagnostyka wymaga trzech osobnych widoków: pliku Compose przed podstawianiem, etykiet rzeczywiście zapisanych w kontenerze i wynikowej konfiguracji Traefika. Błędy mogą powstać już przy dekodowaniu; literówka nie musi pozostać bez komunikatu.

Jawne połączenie routera, usługi i middleware

Fragment należy umieścić pod usługą aplikacji w Compose. Zakłada skonfigurowany provider Docker, entrypoint websecure, resolver le oraz wspólną sieć Dockera rzeczywiście nazwaną proxy. Provider Docker odczytuje ustawienia routingu z etykiet kontenerów. Entrypoint określa miejsce przyjmowania połączeń przez Traefika, a resolver certyfikatów pobiera certyfikaty TLS. Aplikacja musi być osiągalna na wewnętrznym porcie 8080. Plik użytkowników musi być zamontowany do odczytu pod wskazaną ścieżką w kontenerze Traefika; sam fragment nie jest pełną instalacją.

labels:
  - "traefik.enable=true"
  - "traefik.docker.network=proxy"
  - "traefik.http.routers.blog.rule=Host(`blog.example.com`)"
  - "traefik.http.routers.blog.entrypoints=websecure"
  - "traefik.http.routers.blog.tls=true"
  - "traefik.http.routers.blog.tls.certresolver=le"
  - "traefik.http.routers.blog.service=blog-service"
  - "traefik.http.routers.blog.middlewares=blog-auth@docker"
  - "traefik.http.middlewares.blog-auth.basicauth.usersfile=/etc/traefik/auth/blog.htpasswd"
  - "traefik.http.services.blog-service.loadbalancer.server.port=8080"

blog, blog-service i blog-auth celowo mają różne nazwy. Pola usługi i middleware routera tworzą odwołania. Literówka w dowolnie wybranej nazwie obiektu może zadeklarować inny obiekt, natomiast błąd w określonym polu, takim jak loadbalancer, może powodować błąd dekodowania.

Bez jawnego wskazania usługi provider Docker może automatycznie przypisać jedyną zadeklarowaną usługę albo utworzyć usługę. Wiele usług sprawia, że automatyczny wybór staje się niejednoznaczny. Inna nazwa usługi może zatem pozostać niezauważona przy jednej usłudze, a późniejsze jawne odwołanie przestaje działać. Nazwy powinny być bezkonfliktowe w całym providerze, także między projektami Compose.

Bez jawnego portu docelowego udokumentowane wykrywanie Dockera korzysta z jedynego lub najniższego eksponowanego portu. Nie jest to automatyczny wybór opublikowanego portu hosta ani dowód, że nasłuchuje tam właściwa aplikacja. Jawny port wewnętrzny pokazuje zamierzony cel.

Nazwy providerów i rzeczywista ochrona

Nazwa middleware bez przyrostka jest rozwiązywana w providerze routera. blog-auth@docker wskazuje przestrzeń nazw wprost; blog-auth@file odwołuje się do middleware z włączonego providera plikowego. Brak wskazanego obiektu uniemożliwia zbudowanie danej trasy. Nie gwarantuje to jednak ochrony całej nazwy hosta: inny pasujący router może nadal przyjąć żądanie.

Samo zadeklarowanie middleware nie chroni automatycznie każdego dojścia do usługi. Łańcuchy routerów i ewentualne domyślne middleware entrypointu określają rzeczywisty przebieg. Pusta lista middleware routera nie musi więc oznaczać braku ochrony; inna nazwa hosta, entrypoint lub bezpośrednio opublikowany port backendu może natomiast ominąć oczekiwaną ochronę. BasicAuth wymaga HTTPS do zabezpieczenia danych logowania podczas transmisji.

Co Compose rzeczywiście robi ze znakami dolara

Podstawianie zmiennych zastępuje nazwę zmiennej jej ustawioną wartością. Ten proces nazywa się interpolacją. Compose podstawia poprawne wyrażenia zmiennych, na przykład $NAME i ${NAME}. Nazwa zmiennej bez klamer zaczyna się literą lub podkreśleniem. Prefiksy bcrypt $2y i $05 nie są więc usuwane jako takie zmienne. Dalszy fragment skrótu, na przykład $e6zX..., może jednak zostać rozpoznany jako początek zmiennej; brak wartości zwykle powoduje ostrzeżenie i pusty tekst zastępczy. Oryginalny skrót nie jest wtedy wiarygodnie zachowany.

Dla skrótu wpisanego bezpośrednio w interpolowanej etykiecie Compose Traefik zaleca zapis każdego $ jako $$. Polecenie Bash pyta interaktywnie o hasło i podwaja znaki dolara w wygenerowanym wierszu użytkownika:

set -o pipefail
htpasswd -nB admin | sed 's/\$/$$/g'

Cały wynik trafia za basicauth.users=, jeśli ta opcja zastępuje usersfile. Wielokropki we fragmentach objaśniających nie zastępują poprawnego pełnego skrótu. Hasło przekazane jako argument htpasswd -b może ujawnić się na liście procesów lub w historii powłoki; wariant interaktywny unika takiego argumentu.

Podwajanie wynika z przetwarzania Compose, a nie z reguł Traefika. Niezmieniony zamontowany plik użytkowników i bezpośrednio czytany plik konfiguracji dynamicznej Traefika zawierają pojedyncze dolary. Wiersz poleceń wymaga dodatkowo uwzględnienia powłoki; pojedyncze cudzysłowy powłoki POSIX chronią dosłowny skrót przed rozwijaniem zmiennych. Pliki .env mają własne zasady cytowania. Zmiana miejsca przechowywania wymaga zatem ponownej kontroli.

Diagnostyka bez gwarantowanych kodów odpowiedzi

docker compose config pokazuje rozwiązaną konfigurację bez uruchamiania kontenerów. docker inspect pokazuje zapisane etykiety i sieci istniejącego kontenera. Porównanie musi obejmować cały skrót, nie tylko długość; oba wyniki mogą zawierać dane wrażliwe. Logi Traefika i rzeczywiste obiekty routerów oraz usług pokazują następnie zaakceptowaną konfigurację. Widok panelu nie zastępuje testów logowania wszystkimi drogami dostępu.