[Traefik - Proxy/Loadbalancer] Ervaringen & Discussie

[lolgast]

Inleiding

Traefik over zichzelf:
An open-source reverse proxy and load balancer for HTTP and TCP-based applications that is easy, dynamic, automatic, fast, full-featured, production proven, provides metrics, and integrates with every major cluster technology... No wonder it's so popular!

Waar is het voor

Traefik kan gebruikt worden om http- en tcp-services via een proxy beschikbaar te stellen en daarbij meteen als load balancer (round robin) te fungeren. Hiervoor kan gebruik worden gemaakt van standaard providers (Docker, Kubernetes, Rancher en Marathon) voor automatische detectie of door gebruik te maken van handmatig geconfigureerde bestanden. Tijdens het aanmaken kan Traefik meteen een certificaat via Let's Encrypt voor je service (router) aanvragen en koppelen om gebruik te maken van een beveiligde verbinding.

Welke manier je ook kiest, beide worden actief gemonitord en bij het verwijderen van de router verwijderd Traefik ook de reverse proxy. Hierdoor hoef je je geen zorgen te maken over oude configuratiebestanden die opgeschoond moeten worden.

Bij versie 1.x moest praktisch alle configuratie geschreven worden in TOML-bestanden, sinds de livegang van 2.0.0 wordt ook YAML ondersteund.

Screenshots

Links

https://traefik.io/
https://hub.docker.com/_/traefik

[Kaspers]

Ik loop tegen 't volgende probleem aan.
Ik heb traefik2 geconfigureerd voor een aantal (sub)domeinen, en voor alle domeinen, behalve 1, werkt het prima.

De routing die ik niet voor elkaar krijg, betreft een wordpress site.

providers.yml ziet er als volgt uit:

code:

---
http:
  routers:
    to-homeassistant-tls:
      rule: "Host(`hass.kooskaspers.nl`)"
      tls:
        certResolver: default
      entryPoints:
        - web-secure
      service: homeassistant
    to-homeassistant-non-tls:
      rule: "Host(`hass.kooskaspers.nl`)"
      entryPoints:
        - web
      middlewares:
        - redirect
      service: homeassistant
    to-api:
      rule: Host(`traefik.lan`)
      entrypoints:
        - web
      service: api@internal
    to-kaspersschingenga-tls:
      rule: "Host(`www.kaspers-schingenga.nl`, `kaspers-schingenga.nl`)"
      tls:
        certResolver: default
      entryPoints:
        - web-secure
      service: kaspersschingenga
    to-kaspersschingenga-non-tls:
      rule: "Host(`www.kaspers-schingenga.nl`, `kaspers-schingenga.nl`)"
      entryPoints:
        - web
      middlewares:
        - redirect
      service: kaspersschingenga
[.. +nog een aantal routers]

  services:
    kaspersschingenga:
      loadBalancer:
        servers:
          - url: "http://wordpress.lan:80"
    homeassistant:
      loadBalancer:
        servers:
          - url: "http://docker.lan:8123"
    plex:
      loadBalancer:
        servers:
          - url: "http://plex.lan:32400"
    dsmr:
      loadBalancer:
        servers:
          - url: "http://docker.lan:7777"

  middlewares:
   redirect:
     redirectScheme:
       scheme: https

Het probleem zit 'm in de routers voor to-kaspersschingenga-tls en to-kaspersschingenga-non-tls

Ik heb voor het gemak even een kale wordpress installatie genomen, om uit te sluiten dat het aan de wordpress installatie ligt.

Het probleem:

Wanneer ik surf naar "www.kaspers-schingenga.nl" krijg ik netjes de site te zien:



Wanneer ik echter op 1 van de subpaginas klik, wordt vervolgens als volgt geredirect:



En dat valt uiteraard niet te resolven.

Als ik over de link in de pagina hover, zie ik de juiste url staan:

.

Dus de configuratie van de site-url binnen wordpress lijkt me goed te staan.

Configuratie voor de andere hosts binnen traefik is identiek. Voor deze services worden subpagina's netjes geserveerd (plex, hass, dsmr) door traefik.

Ik heb tevens getest met een configuratie waarbij ik voor de non-tls router, de http->https middleware redirect eruit heb gehaald. Dit lost het probleem helaas niet op.

Ik heb uitgesloten dat het aan de wordpress installatie ligt, door een schone image te gebruiken.
Iemand nog een idee waar ik 't in moet zoeken?

[Kaspers]

martinvdm schreef op dinsdag 1 oktober 2019 @ 19:05:
Wat heb je in je Wordpress config staan?
Heb niet het idee dat het issued in traefik zit, aangezien traefik niet snel je een andere url zal voorspiegelen maar puur proxied

docker-compose van de wordpress docker container:

code:

version: '3.3'
services:
   wordpress:
     container_name: wordpress
     depends_on:
       - db
     image: wordpress:latest
     volumes:
       - ./wp_data:/var/www/html
     ports:
       - "80:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: asdfasdfasdf
       WORDPRESS_DB_NAME: wordpress-db

[.. en nog wat phpmysql en mysql containers ..]

Dit is het enige wat ik geconfigureerd binnen deze wordpress site:



Nu komt 't:

Wanneer ik in de traefik config (providers.yml) de service:

code:

  services:
    kaspersschingenga:
      loadBalancer:
        servers:
          - url: "http://wordpress.lan:80"

aan pas naar het exacte ip adres van de host:

code:

  services:
    kaspersschingenga:
      loadBalancer:
        servers:
          - url: "http://192.168.1.56:80"

Wordt er als volgt geredirect:



dus 192.168.1.56 ipv wordpress.lan (zoals in voorgaande screenshot het geval was).

Dit doet me dus vermoeden dat 't wél in traefik moet zitten, want binnen wordpress is nergens de host "wordpress.lan" of "192.168.1.56" geconfigureerd.. Ga je mee in deze redenatie?

[ Voor 6% gewijzigd door Kaspers op 01-10-2019 19:25 ]

[Kaspers]

Fixed:

code:

  services:
    kaspersschingenga:
      loadBalancer:
        passHostHeader: true
        servers:
          - url: "http://192.168.1.56:80"

fix is: passHostHeader: true

Strookt niet helemaal met de docs:

[iGrasmat]

lolgast schreef op zaterdag 22 februari 2020 @ 16:01:
Ik ben inmiddels al even over naar v2, maar als ik heel eerlijk ben, maakt me weinig verschil. Traefik is nog altijd een beetje ‘set and forget’ Wat super is

Begrijpelijk. Maar toch is het verstandig om over te gaan naar v2.0 voor het geval van support e.d. Ik las ergens dat Containous van plan was maar één jaar support te blijven geven voor v1.7 na de release van v2.0 (wat inmiddels ongeveer een half jaar geleden is).

Edit: bij nader inzien is het twee jaar.

Bron: https://containo.us/blog/traefik-2-1-in-the-wild/

[ Voor 12% gewijzigd door iGrasmat op 23-02-2020 00:31 ]

[Matis]

De afgelopen week heb ik veel van mijn (web)services van mijn externe VPS overgeheveld naar mijn lokale Docker-machine waarin ik Traefik 2.2 gebruik als reverse proxy.
Al deze services exposen port 80 en/of 443 en dat werkt allemaal out-of-the-box

Nu zit ik met het probleem dat ik (in een aparte docker-compose) GitLab heb draaien. Deze exposed de volgende 3 poorten: 22, 80 en 443.
Omdat Traefik en GitLab in afgezonderde docker-compose omgevingen draaien, hebben beide services (op netwerk-niveau) geen weet van elkaar.

Standaard stuurt Traefik al het verkeer dat hij matched door op de eerste / laagste exposed port. In het geval van GitLab is dat 22. Echter draait daar de ssh-daemon op die natuurlijk geen HTTP(s) verkeer kan afhandelen. Ik zie dit dan ook in de logs terug:

==> /var/log/gitlab/sshd/current <==
2020-04-22_08:36:47.37298 Bad protocol version identification 'GET / HTTP/1.1' from 172.21.0.1 port 35932
2020-04-22_08:36:47.45269 Bad protocol version identification 'GET /favicon.ico HTTP/1.1' from 172.21.0.1 port 35934

Ik ben al heel de dag aan het stoeien om het voor elkaar te krijgen Traefik te vertellen dat hij op poort 80 van mijn GitLab container moet verbinden en niet op poort 22.

Ik krijg dit met geen mogelijkheid voor elkaar. Via de Docker provider maakt hij automagisch de volgende Service aan voor mijn GitLab container:


Het "enige" dat ik probeer te bereiken is de poort van de Server URL om te dopen naar poort 80. Omdat het IP adres dynamisch wordt gegenereerd door docker-compose, kan ik geen handmatige service / loadbalancer toevoegen aan de dynamische configuratie die ik voor GitLab heb gemaakt.

Deze ziet er momenteel als volgt uit:

code:

## Dynamic configuration
http:
  routers:
    gitlab-router:
      rule: "Host(`gitlab.localhost`, `gitlab.external.nl`, `gitlab.internal.nl`)"
      service: web-gitlab@docker
      tls: {}

Bovenstaande configuratie wordt netjes aan de eerdergenoemde web-gitlab@docker router toegevoegd.

Wanneer ik naar http://gitlab.internal.nl ga, wordt ik allereerst naar https://gitlab.internal.nl doorgestuurd, maar dan komt het HTTP-verkeer op poort 22 terecht en krijg ik de sshd foutmelding in de logging en mijn browser toont alleen:

Internal Server Error

Ik wil zo min mogelijk (eigenlijk niets) aan mijn docker-compose.yml en GitLab configuratie wijzigen. Ik ben dus op zoek naar een mogelijkheid om middels de configuratie van Traefik het verkeer naar poort 80 door te sturen en niet poort 22.

[DEN0W]

Bij het testen van mijn setup kom ik de volgende entrys tegen, klopt dit? Ik maak gebruik van DNS verificatie voor letsencrypt en ik zie bij het aanvragen van de certicaat dat er een txt record wordt aangemaakt maar die verdwijnt vervolgens weer.




Edit: Ik heb dus helemaal geen txt records staan alleen een A record en een cname

[ Voor 6% gewijzigd door DEN0W op 14-05-2020 20:09 ]

[lolgast]

@Jazco2nd Dat lijkt me een Nameserver issue, niet zozeer Traefik. Heb je het domein recent aangemaakt? Klopt je CNAME/Wildcard?

Als ik dit zo zie zijn sowieso nog niet alle nameservers op de hoogte van je ip

[Wtrdk]

Hi, ik ben een Traefik-n00b, en ben aan het stoeien. ik krijg een aantal dingen wel aan de praat, maar niet alles.

Mijn Traefki docker-compose.yml:

code:

version: '3'

services:
  traefik:
    image: traefik:latest
    container_name: traefik
    restart: always
    security_opt:
      - no-new-privileges:true
    networks:
      - proxy
    ports:
      - 80:80
      - 443:443
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/traefik.yml:/traefik.yml:ro
      - ./data/acme.json:/acme.json
    labels:
      - traefik.enable=true
      - traefik.http.middlewares.traefik-auth.basicauth.users=admin:$$apr1$$aMf12NAg$$B9H7lyu3MNG7Y/LDe5iTV/
      - traefik.http.routers.traefik-secure.service=api@internal
      - traefik.http.routers.traefik-secure.entrypoints=https
      - traefik.http.routers.traefik-secure.rule=Host(`monitor.mydomain.com`)
      - traefik.http.routers.traefik-secure.middlewares=traefik-auth
      - traefik.http.routers.traefik-secure.tls=true
      - traefik.http.routers.traefik-secure.tls.certResolver=default
      - traefik.http.routers.http-catchall.rule=hostregexp(`{host:.+}`)
      - traefik.http.routers.http-catchall.entrypoints=http
      - traefik.http.routers.http-catchall.middlewares=redirect-to-https
      - traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https

networks:
  proxy:
    external: true

bijbehorende traefik.yml

code:

api:
  dashboard: true

entryPoints:
  http:
    address: ":80"
  https:
    address: ":443"

tls:
  options:
    default:
      sniStrict: true
      minVersion: VersionTLS12

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

certificatesResolvers:
  default:
    acme:
      email: [e-mail]
      storage: acme.json
      tlsChallenge: {}
      httpChallenge:
        entryPoint: http

Traefik werk prima1

Ik heb ook Portainer draaien emt de volgende docker-compose.yml:

code:

version: '3'

services:
  portainer:
    image: portainer/portainer:latest
    container_name: portainer
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    networks:
      - proxy
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./portainer-data:/data
      - /opt/traefik/data/acme.json:/acme.json
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.portainer.entrypoints=http"
      - "traefik.http.routers.portainer.rule=Host(`portainer.mydomain.com`)"
      - "traefik.http.middlewares.portainer-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.portainer.middlewares=portainer-https-redirect"
      - "traefik.http.routers.portainer-secure.entrypoints=https"
      - "traefik.http.routers.portainer-secure.rule=Host(`portainer.mydomain.com`)"
      - "traefik.http.routers.portainer-secure.tls=true"
      - "traefik.http.routers.portainer-secure.tls.certresolver=default"
      - "traefik.http.routers.portainer-secure.service=portainer"
      - "traefik.http.services.portainer.loadbalancer.server.port=9000"
      - "traefik.docker.network=-proxy"

networks:
  proxy:
    external: true

Portainer werkt ook prima!

Nu wil ik graag Matomo draaien. Ik heb de volgende docker-compose.yml gemaakt. Alle variabelen staan in db.env.

code:

version: '3'

services:
  db:
    image: mariadb
    command: --max-allowed-packet=64MB
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
    env_file:
      - ./db.env

  app:
    image: matomo:fpm-alpine
    restart: always
    links:
      - db
    volumes:
      - ./config:/var/www/html/config:rw
      - ./logs:/var/www/html/logs
      - matomo:/var/www/html
    environment:
      - MATOMO_DATABASE_HOST=db
    env_file:
      - ./db.env

  web:
    image: nginx:alpine
    restart: always
    volumes:
      - matomo:/var/www/html:ro
      - ./matomo.conf:/etc/nginx/conf.d/default.conf:ro
      - /opt/traefik/data/acme.json:/acme.json
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.matomo.entrypoints=http"
      - "traefik.http.routers.matomo.rule=Host(`matomo.mydomain.com`)"
      - "traefik.http.middlewares.matomo-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.matomo.middlewares=matomo-https-redirect"
      - "traefik.http.routers.matomo-secure.entrypoints=https"
      - "traefik.http.routers.matomo-secure.rule=Host(`matomo.mydomain.com`)"
      - "traefik.http.routers.matomo-secure.tls=true"
      - "traefik.http.routers.matomo-secure.tls.certresolver=default"
      - "traefik.http.routers.matomo-secure.service=matomo"
      - "traefik.http.services.matomo.loadbalancer.server.port=80"
      - "traefik.docker.network=-proxy"
      - "traefik.frontend.headers.STSSeconds=15768000"
    ports:
      - 8585:80

volumes:
  db:
  matomo:

networks:
  proxy:
    external: true

De Matomo instance start zonder foutmeldingen. Traefik detecteert hem keurig;


Als ik nu naar https://matomo.mydomain.com ga krijg ik de volgende foutmelding: 'Gateway Timeout' : Failed to load resource: the server responded with a status of 504 ()
Het lukt me niet de fout te vinden. kan iemand me op weg helpen?

Thanks!

[Wtrdk]

mithras schreef op vrijdag 6 november 2020 @ 15:37:
[...]


Je bent deels goed op weg maar nog niet helemaal. Hieronder:

code:

web:
    image: nginx:alpine
    restart: always
    depends_on:
      - app
    networks:
      - matomo
      - proxy
    volumes:
      - matomo:/var/www/html:ro
      - ./matomo.conf:/etc/nginx/conf.d/default.conf:ro
      - /opt/traefik/data/acme.json:/acme.json
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.matomo.entrypoints=web"
      - "traefik.http.routers.matomo.rule=Host(`matomo.mydomain.com`)"
      - "traefik.http.middlewares.matomo-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.matomo.middlewares=matomo-https-redirect"
      - "traefik.http.routers.matomo-secure.entrypoints=websecure"
      - "traefik.http.routers.matomo-secure.rule=Host(`matomo.mydomain.com`)"
      - "traefik.http.routers.matomo-secure.tls=true"
      - "traefik.http.routers.matomo-secure.tls.certresolver=default"
      - "traefik.http.routers.matomo-secure.service=matomo"
      - "traefik.http.services.matomo.loadbalancer.server.port=80"
      - "traefik.docker.network=-proxy"
      - "traefik.frontend.headers.STSSeconds=15768000"
    ports:
      - 8585:80

Dus je zegt tegen Traefik in het label dat de server op poort 80 draait. Maar de docker container map je de interne poort (80, want standaard nginx) map je naar 8585 Die docker container heeft standaard (want, nogmaals nginx container) alleen poort 80 aan de buitenkant van de container. Die zal Traefik detecteren en via de labels aan de hostmachine koppelen. In jouw geval, aan matomo.mydomain.com.

Die port mapping die je nu hebt, hernummert eigenlijk de interne docker poort 80 aan de buitenkant van de container naar 8585. Maar toch zeg je tegen Traefik dat deze container bereikt kan worden op zijn poort 80. Dat gaat hem dan niet worden

Volgens mij moet het goed gaan als je de poortmapping eruit haalt en dan kan ook de loadbalancer regel eruit. Als dat niet werkt, moet je even stap voor stap debuggen:

1. Heb je Traefik wel goed draaien? (Bijv check je dashboard)
2. Herkent Traefik de container wel (bijv zie je dat in het dashboard maar ook in de logs)
3. Zitten er foutmeldingen binnen Traefik over het aanmaken van een router of service?
4. Kom je wel in de web container terecht? Bijv probeer een URL naar een statisch bestand van Matomo, een css file ofzo want dat blijft binnen de web container en wordt niet naar de app container gestuurd
5. Check je web container voor foutmeldingen dat bijv nginx niet goed werkt, of check of nginx zeurt over de ontbrekende fpm proxy
6. Check in de app container voor fouten, want onderhand na stap 1-5 lijkt Traefik en je webserver wel te werken

1: volgens mij werkt alles naar behoren. Geen errors, zie afbeelding;

2. Ik heb geen logging in Traefik. Als ik het aanzet door het toe te voegen in traefik.yml worden er geen logs weggeschreven.
3. Ik zie in de webinterface van Traefik geen meldingen, maar zoals hierboven gezegd heb ik geen logbestanden...
4. Ik kom niet bij Matomo zelf, ik blijf een 500 error krijgen, wat mijn gevoel sterkt dat het aan docker ligt (en een onjuist config, maar wat weet ik niet...)
5. In de webcontainer de volgende meldingen:

code:

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: error: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Configuration complete; ready for start up

6. Geen fouten:

code:

[06-Nov-2020 19:55:05] NOTICE: fpm is running, pid 1
[06-Nov-2020 19:55:05] NOTICE: ready to handle connections

[joost308]

@lolgast . Heb ff gezocht in alle bestanden die in mijn rules directory staan maar helaas geen hits op 'passTLSCert'

Files in mijn rules map zijn: tls.yml

code:

tls:
  options:
    TLSv13:
      minVersion: VersionTLS13
      cipherSuites:
        - TLS_AES_128_GCM_SHA256
        - TLS_AES_256_GCM_SHA384
        - TLS_CHACHA20_POLY1305_SHA256
      sniStrict: true
    default:
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      sniStrict: true

Dan de middlewares.yml (daar lijkt hij de melding op te geven maar ik heb alle opties gecontroleerd en zie geen deprecated zaken (in 2.2 ook geen problemen)

code:

http:
  middlewares:
    redirect:
      redirectScheme:
        scheme: https
    hsts:
      headers:
        sslRedirect: true
        stsPreload: true
        stsSeconds: 315360000
        stsIncludeSubdomains: true

en dan heb ik nog wat file based sites. Die zijn allemaal in deze format opgemaakt:

code:

http:
  routers:
    websiteX-secure:
      rule: Host("x.y.z")
      entryPoints:
        - websecure
      service: service-websiteX@file
      middlewares:
        - hsts
      tls:
        certResolver: le

    websiteX:
      rule: Host("x.y.z")
      entrypoints:
        - web
      service: service-websiteX@file
      middlewares:
        - redirect

  services:
    service-websiteX:
      loadBalancer:
        servers:
          - url: https://IP

Ik hoop dat jullie nog wat slims weten wat ik over het hoofd zie

[lolgast]

Ik gebruik AdGuard om reclame te blokkeren en al mijn devices hebben die dus als DNS servers. AdGuard kan ook zogenaamde DNS-rewrites uitvoeren dus daar staan mijn domeinen gewoon naar het interne IP van Traefik. Met uitzondering van 1 URL, die draait op mijn Home Assistant omgeving.


Kan niet zeggen dat ik hierdoor ooit issues heb gehad

[mca2]

Traefik draait inmiddels prima met een wildcard certificaat voor mijn domein. Ook heb ik inmiddels een paar services draaien, die het prima doen. Echter lukt het mij niet Unifi aan de praat te krijgen. De container en logon op het portal werkt allemaal prima maar er wordt geen enkel device gedetecteerd. Het lijkt of Unifi op het interne Traefik netwerk zit (172.x) ipv het daadwerkelijke netwerk (192.168.x).

Ik heb alles in 1 docker-compose file staan en gebruik het default netwerk met daarin deze service voor Unifi. Wat gaat er hier mis?

code:

unifi:
                image: "ghcr.io/linuxserver/unifi-controller"
                container_name: unifi
                environment:
                        - PUID=1000
                        - PGID=1000
                        - MEM_LIMIT=1024M #optional
                volumes:
                        - ./unifi/config:/config
                        - ./unifi/autobackup:/usr/lib/unifi/data/backup/autobackup
                ports:
                        - 3478:3478/udp
                        - 10001:10001/udp
                        - 8080:8080
                        - 8443:8443
                        - 1900:1900/udp #optional
                        - 8843:8843 #optional
                        - 8880:8880 #optional
                        - 6789:6789 #optional
                        - 5514:5514 #optional
                restart: unless-stopped
                labels:
                        - "traefik.enable=true"
                        - "traefik.http.routers.unifi.rule=Host(`unifi.mydomain.com`)"
                        - "traefik.http.routers.unifi.entrypoints=websecure"
                        - "traefik.http.routers.unifi.tls=true"
                        - "traefik.http.routers.unifi.tls.certresolver=myresolver"
                        - "traefik.http.services.unifi.loadbalancer.server.scheme=https"
                        - "traefik.http.services.unifi.loadbalancer.server.port=8443"

Edit: toch niet, volgens onderstaande kijkt de controller op het juiste netwerk. Maar waarom ziet de controller mijn Flex Mini switch en AP-AC-Lite dan niet?

[ Voor 5% gewijzigd door mca2 op 02-02-2021 23:04 ]

[JBS]

RobertMe schreef op zaterdag 20 februari 2021 @ 20:52:
[...]

Je past de add-pv middleware nu nergens toe? Lijkt mij toch dat je die moet toepassen op de pv route.

Dank voor de hint, met die toevoeging kom ik inderdaad bij Grafana uit, maar wel met een error melding:



Heb het voor nu maar even anders opgelost: In Grafana het PV dashboard het standaard dashboard gemaakt.

[JorisV]

Voor bepaalde functies van lokale websites heb ik https nodig en overzichtelijke naamgeving lijkt me ook handig. Dus als noob ben ik traefik aan het proberen, maar het wil niet opschieten. Ik heb geen domein (en wil er ook geen) maar heb op mijn router home.arpa ingesteld. Lokaal kan ik mijn server nu bereiken met http://rpi4. Voor traefik heb ik een docker-compose container met:

YAML:

version: '3'
services:
  traefik:
    image: traefik:2.5
    container_name: traefik
    labels:
     - traefik.enable=true
     - traefik.http.routers.traefik=true
     - traefik.http.routers.traefik.tls=true
     - traefik.http.services.traefik.loadbalancer.server.port=8080
    ports:
      - 80:80
      - 443:443
      - 8080:8080
    volumes:
     - ${USERDIR}/traefik/traefik.yml:/etc/traefik/traefik.yml:ro
     - ${USERDIR}/traefik/config.yml:/etc/traefik/config.yml:ro
     - ${USERDIR}/traefik/certs:/etc/certs:ro
     - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    ports:
      - 80
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.tls=true
      #- traefik.http.routers.whoami.rule=Host("myapi.rpi4.home.arpa")
      #- traefik.http.routers.whoami.rule=Host("whoami.localhost")
      #- traefik.http.routers.whoami.rule=PathPrefix(`/whoami{regex:$$|/.*}`)
      - traefik.http.routers.whoami.rule=Path(`/whoami`)

en voor de config.yml:

YAML:

http:
  routers:
    traefik:
      rule: Host(`traefik.localhost`)
      #rule: Host(`traefik.docker.localhost`)
      #rule: Path(`/traefik`)
      service: api@internal
      tls:
        domains:
          - main: docker.localhost
            sans:
              - "*.docker.localhost"
          - main: domain.local
            sans:
              - "*.domain.local"

tls:
  certificates:
    - certFile: /etc/certs/local-cert.pem
      keyFile: /etc/certs/local-key.pem

De certificaten heb ik gemaakt met mkcert voor localhost rpi4 192.168.1.207 127.0.0.1 ::1 home.arpa "*.home.arpa" domain.local "*.domain.local"

De regels die ik uitgecomment heb werken niet, vandaar.
Wat werkt is https://rpi4/whoami maar met een niet geldig certificaat:


Kan iemand me helpen met het volgende:
-Hoe kom ik bij de traefik configuratie site?
-Hoe krijg ik subdomains werkend (dus https://whoami.rpi4)
-Hoe maak ik het certificaat geldig?

[badkuip]

jvwou123 schreef op woensdag 9 april 2025 @ 21:17:
[...]


Ow, dan heb ik je vraag verkeerd begrepen. In de yaml kun je volgens mij idd geen variablen kwijt. Je kunt wel variable gebruiken ipv yaml regels: https://doc.traefik.io/tr...static-configuration/env/

Sorry voor de late reactie. Ik laat het dan maar zo. De inspanning om het om te bouwen weegt niet af tegen de moeite die ik erin moet steken.

Een andere vraag over treafik, en dan de logs. De logs zijn er wel maar er wordt geen output gestuurd naar docker logs.

Inhoud /home/user/docker/logs/traefik/treafik.log

code:

2025-04-17T10:08:53+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:08:53+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.5:8080
2025-04-17T10:08:53+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:08:53+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.5:8080
2025-04-17T10:08:54+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:08:54+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.5:8080
2025-04-17T10:09:01+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:03+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/recovery/recovery.go:45 > Request has been aborted [141.101.76.104:48402 - /api/hosts/c4a28df9-9cf5-41e5-a663-ca7b10fc1e38/containers/421e0f707a0d/logs/stream?stdout=1&stderr=1&levels=info&levels=debug&levels=warn&levels=error&levels=fatal&levels=trace&levels=unknown]: net/http: abort Handler middlewareName=traefik-internal-recovery middlewareType=Recovery
2025-04-17T10:09:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:32+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:41+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:42+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:09:50+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:09:50+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:10:01+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:10:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:10:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:10:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:10:50+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:10:50+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:11:01+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:11:04+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/compress/compress.go:143 > Unable to parse MIME type error="mime: no media type" middlewareName=middlewares-compress@file middlewareType=Compress
2025-04-17T10:11:04+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.5:8080
2025-04-17T10:11:14+02:00 DBG github.com/traefik/traefik/v3/pkg/middlewares/recovery/recovery.go:45 > Request has been aborted [141.101.76.104:48396 - /api/hosts/c4a28df9-9cf5-41e5-a663-ca7b10fc1e38/containers/8457a480dbf4/logs/stream?stdout=1&stderr=1&levels=info&levels=debug&levels=warn&levels=error&levels=fatal&levels=trace&levels=unknown]: net/http: abort Handler middlewareName=traefik-internal-recovery middlewareType=Recovery
2025-04-17T10:11:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:11:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80
2025-04-17T10:11:31+02:00 DBG github.com/traefik/traefik/v3/pkg/server/service/loadbalancer/wrr/wrr.go:213 > Service selected by WRR: http://192.168.34.6:80

Docker logs (middels Dozzle, maart ook portainer is leeg).


Het zou me fijn lijken om de logoutput in docker logs te laten lopen. Maakt het raadplegen van de logs makkelijker (dus niet meer een 'cat' of 'tail' te hoeven op de prompt of te hoeven raadplegen in vs code.

Al mijn andere containers loggen nu al netjes naar docker logs zonder enige extra config van mijn hand.
Als ik het goed begrijp moet ik voor de traefik container een log driver configureren en dan zou het werken.

Hoe langer ik erover nadenk, hoe meer ik mezelf afvraag of het eigenlijk wel verstandig is.
Misschien hebben de makers van traefik een hele goede reden om niet default de logs te outputten naar docker logs.

Iemand een idee, mening, of ervaring hierover/hiermee?

[Mars Warrior]

Grappig dat als Traefik en CrowdSec samen hun werk doen, en je geen enkele alert meer hebt, dat de console van CrowdSec dan gaat twijfelen of CrowdSec nog wel werkt. Blijkbaar zit daar geen communicatie tussen om dat aan te geven...



Je wordt hierdoor ook "gestraft" doordat je in dit soort gevallen de "Lite" blocklist krijgt (max 3k IP's), en niet de volledige omdat je nu niks meer bijdraagt door het gebrek aan alerts. Dus ze schroeven de beveiliging omlaag zodat er weer alerts kunnen komen

Ze gaan er natuurlijk ook standaard vanuit dat je een ban van 4h doet. Bij mij zijn ze (bijna altijd) permanent, dus daarmee ook geen last van terugkerende alerts en dus decisions. Immers, botjes leren niet van een straf, die gaan gewoon door.

En custom AppSec collections/parsers/scenario's/alerts tellen niet, want die kunnen ze niet verifieren...

Ik heb dus wel een aantal van die custom dingen draaien om bijv. Wordfence blocks in de access log door te zetten naar CrowdSec. Het is nu enkel wachten op een onverlaat die weer een poging doet om in te loggen met "admin" of een andere logische gebruikersnaam

Al met al dus na 4 dagen een mooi resultaat: ik zie bijna geen 4** status codes meer in de logs voorbijkomen. Alles is een stuk rustiger. Voorlopig dus ook geen noodzaak om de hele lijst van ThreatHive (126.000 IPs) toe te passen.

---

EDIT #1
Er was blijkbaar een communicatie probleem met CrowdSec, al heb ik geen idee wat dan, maar sinds een uurtje heb ik plotseling weer stapels alerts en zijn alle alerts sinds zaterdagochtend binnengekomen: gemiddeld zo'n 100 per dag

Ik heb lokaal zitten kijken, en zag met "cscli alerts list" bergen met alerts. Toen ik daarna in de CrowdSec console ging kijken, kwamen ze vervolgens allemaal binnen

Dus dat ik bijna geen 4** status codes meer voorbij zie komen dat klopt, maar CrowdSec alert zich nog helemaal suf elke dag. Mijn custom alerts doen het nog niet, dus daar moet ik nog naar kijken...

---

EDIT #2

Nou. Zolang ik:

• Niet de lijst van Emerging Threats gebruik (https://rules.emergingthr...es/emerging-Block-IPs.txt) om als decision aan CrowdSec toe te voegen
• Een korte ban tijd (4 uur nu ff) gebruik

Dan blijft CrowdSec helemaal blij en zie ik een community blocklist van 15.000 IPs voorbijkomen



Maar ja, dan wel dus rond de 100 alerts per dag. Ik weet ff niet wat nu verstandiger is
Dezelfde IP adressen komen nu meerdere malen per dag langs. Met een bantijd van 24h isdat al flink minder natuurlijk.

Het wordt denk ik beetje laveren tussen een langere bantijd, toepassing van de emerging threats lijst (update 1x per dag, 24h bantijd, lijst van ca 1.500 ip blokken) en het verlies van de 15k community blocklist die dan de "lite" variant van 3k wordt.

Als voorbeeld:
Je ziet een heel IP bereik elke dag terugkomen. Dag in dag uit exact dezelfde probes, alerts en blocks.
In de emerging threats lijst staat dit bereik (78.153.140.0/24) gewoon geblokkeerd...

Bash Session:

│ 415 │ Ip:78.153.140.203                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-14T22:37:25Z │
│ 414 │ Ip:78.153.140.203                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-14T22:37:25Z │
│ 267 │ Ip:78.153.140.203                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T12:32:31Z │
│ 266 │ Ip:78.153.140.203                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T12:32:31Z │
│ 252 │ Ip:78.153.140.151                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T09:17:57Z │
│ 251 │ Ip:78.153.140.151                             │ crowdsecurity/http-admin-interface-probing                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T09:17:58Z │
│ 250 │ Ip:78.153.140.151                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T09:17:57Z │
│ 249 │ Ip:78.153.140.123                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T09:01:45Z │
│ 248 │ Ip:78.153.140.123                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-13T09:01:45Z │
│ 160 │ Ip:78.153.140.203                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T13:56:53Z │
│ 159 │ Ip:78.153.140.203                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T13:56:53Z │
│ 146 │ Ip:78.153.140.123                             │ crowdsecurity/http-admin-interface-probing                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T08:39:51Z │
│ 145 │ Ip:78.153.140.123                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T08:39:50Z │
│ 144 │ Ip:78.153.140.123                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T08:39:50Z │
│ 106 │ Ip:78.153.140.224                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T02:59:35Z │
│ 105 │ Ip:78.153.140.224                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T02:59:35Z │
│ 100 │ Ip:78.153.140.179                             │ crowdsecurity/http-admin-interface-probing                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T02:05:31Z │
│ 99  │ Ip:78.153.140.179                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T02:05:29Z │
│ 98  │ Ip:78.153.140.179                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T02:05:29Z │
│ 93  │ Ip:78.153.140.151                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T01:49:40Z │
│ 92  │ Ip:78.153.140.151                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-12T01:49:40Z │
│ 54  │ Ip:78.153.140.203                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T14:35:09Z │
│ 53  │ Ip:78.153.140.203                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T14:35:09Z │
│ 49  │ Ip:78.153.140.224                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T13:24:26Z │
│ 48  │ Ip:78.153.140.224                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T13:24:26Z │
│ 45  │ Ip:78.153.140.179                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T10:51:04Z │
│ 44  │ Ip:78.153.140.179                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-11T10:51:04Z │
│ 11  │ Ip:78.153.140.203                             │ crowdsecurity/http-probing                                   │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-10T16:39:13Z │
│ 10  │ Ip:78.153.140.203                             │ crowdsecurity/http-sensitive-files                           │ GB      │ 202306 Hostglobal.plus Ltd                       │ ban:1     │ 2025-10-10T16:39:13Z │

---

EDIT #3
Ja hoor, En dan heb ik Alerts, krijg ik dit weer:



Afijn: Geen Alerts is niet goed, maar teveel ook niet. Ik heb die Emerging Threats lijst er nu maar ingezet, en ga de bantijd verlengen. Pfff. Het is 15 oktober en ik zit op 406 van de 500 voor de hele maand

Ik neem aan dat alles lokaal gewoon blijft werken, zelfs als ik over die 500 ga.

[ Voor 114% gewijzigd door Mars Warrior op 15-10-2025 18:37 ]

[Mars Warrior]

Met het dynamisch maken van de bantijd in CrowdSec's profiles.yaml lijkt alles een stuk rustiger te zijn. De bans zijn nu afhankelijk van het aantal decisions in de database (zowel actief als verlopen) * 24h. Dan krijg je dus dat bans bij herhaalde overtredingen steeds langer worden.

De Alerts blijven komen overigens. Ik zit nu vanzelfsprekend ruim over de limiet van 500, maar dat zal me een zorg zijn. De Alerts zorgen ervoor dat er nieuwe - en langere - bans worden uitgedeeld. Zou je de bans in een firewall zetten, dan werkt dat niet omdat die IP adressen worden tegengehouden. En als die ban verloopt, dan komen alle botjes weer van voren af aan je backends verstoren. Nu ik ze nog steeds afvang in Traefik/CrowdSec, worden de bans dus elke keer verlengd.

Het enige dat ik niet kan vinden is hoevaak de database wordt opgeschoond, dus dat verlopen decisions worden verwijderd.

De minimale bantijd van 24u is eigenlijk nog net te kort voor een enkele ban: de meeste botjes komen bijna elke dag rond dezelfde tijd langs. Het bannen van minder dan 24h heeft dus ook geen enkele zin: ze komen toch niet meer langs in die tijd. De standaard 4u van CrowdSec vind ik dan ook vreemd overkomen, immers dat helpt bij mij helemaal niets.

Door de werking van CrowdSec (Alerts --> Nieuwe decision gebaseerd op eerdere decisions) krijgen botjes die regelmatig langs komen feitelijk een "permanente" ban: de bantijd wordt immers elke keer verlengd. Precies wat mijn doel was.

[RobertMe]

Voor diegenen die Traefik met plugins gebruiken en in het algemeen Renovate gebruiken om software / dependencies / ... te updaten.

Met deze "custom manager" (in de Renovate config) herkent en update Renovate deze plugins:

JSON:

  "customManagers": [
    {
      "customType": "jsonata",
      "fileFormat": "yaml",
      "managerFilePatterns": ["/traefik.ya?ml/"],
      "matchStrings": [
        "experimental.plugins.*.{\"depName\": $substringAfter(moduleName, \"/\"), \"currentValue\": version, \"packageName\": \"https://\" & moduleName}"
      ],
      "datasourceTemplate": "git-tags"
    }
  ]

Voorbeeld van een resultaat:



En tegen mijn verwachting in..., en geen idee hoe Renovate het doet, maar het werkt ook goed als je meerdere plugins zou hebben met dezelfde versie.
Als in, als test had ik dit in mijn Traefik.yaml gezet:

YAML:

experimental:
  plugins:
    traefik-oidc-auth:
      moduleName: "github.com/sevensolutions/traefik-oidc-auth"
      version: "v0.16.0"
    foo:
      moduleName: "github.com/foo/bar"
      version: "v0.16.0"

En ook in dat geval deed Renovate prima alleen de version regel bij de oidc plugin updaten (en ik geloofde het zo slecht, dat ik de twee plugins ook nog eens heb omgedraaid, en het is dus ook niet dat Renovate een search & replace doet en stopt na de eerste match. Met de plugins omgedraaid update hij dus de tweede (oidc) en niet nog steeds "alleen de eerste" of zo).

Daarnaast ondersteund de JSONata custom manager niet alleen JSON, maar ook yaml en toml met automatische conversie (anders werkte mijn voorbeeld sowieso al niet ). Voor de TOML gebruikers is het dus ook mogelijk om "fileFormat": "yaml" => toml + "managerFilePatterns": ["/traefik.ya?ml/"]" => /traefik.toml te doen (of je kunt dus beiden er in opnemen). Of het ook werkende te krijgen is als je Traefik commnd line flags gebruikt weet ik niet (want dat zijn dan vast twee regels die op basis van het zelf verzonnen naampje bij elkaar moeten worden gevoegd als 1 match met depName / packageName + currentValue).