[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

[lolgast]

Ik kom Traefik steeds vaker tegen in topics en de vragen willen daar nogal eens de overhand krijgen over het onderwerp van het topic zelf, ik zag nog geen Traefik-topic dus ik heb even snel een opzetje gemaakt.

Ik ben zelf sinds vandaag over van 1.7.14 naar 2.0.0 en dat was echt een grotere klus dan het had moeten zijn. Lang niet alles is geconfigureerd en geoptimaliseerd (verwacht ik) zoals ik het zou willen, maar het werkt in ieder geval. Heb ook meteen gekozen om alle bestanden in YAML te configureren, aangezien de hele Docker omgeving dat toch ook al is.

[daansan]

Ik ben al een tijd een tevreden gebruiker van Traefik draaiend in Docker.

Heb Watchtower aanstaan en had als image de :latest variant in mn docker compose gebruikt. Dat was dus even een verassing toen v2 gereleased was: Traefik deed helemaal niets meer omdat de configuratie dusdanig veranderd is.

Ben een avond met v2 aan het stoeien geweest maar het lukt me nog niet om Let'sEncrypt/Acme met Transip op te zetten met Traefik v2. Op een moment dat ik weet hoe dat moet dan ga ik over.

[lolgast]

@daansan Mijn transip config ziet er zo uit
In traefik.yml

YAML:

providers:
  file:
    directory: /rules
    watch: true

certificatesResolvers:
  letsencrypt:
    acme:
      email: [e-mail]
      storage: acme.json
      dnsChallenge:
        provider: transip
        delayBeforeCheck: 0

In de rules folder een certs.yml gemaakt

YAML:

http:
  routers:
    certs:
      entryPoints:
        - http
        - https
      service: service-blank
      rule: Host("about:blank")
      tls:
        certResolver: letsencrypt
        domains:
          - main: "*.domain1.nl"
            sans:
              - domain1.nl
          - main: "*.domain2.nl"
            sans:
              - domain2.nl
          - main: "*.domain3.nl"
            sans:
              - domain3.nl
          - main: "*.domain4.nl"
            sans:
              - domain4.nl

  services:
    service-blank:
      loadBalancer:
        servers:
          - url: "https://about.blank"

Ik heb nu dus 4 wildcard certificaten

[martinvdm]

Top @lolgast om er een apart topic van te maken. Heb je nu ACME of DNS challenge?
Heb je ergens je config voor naslag werk?

Ik ben me nog aan het verdiepen in V2 maar voorlopig draai ik v1. Ik heb grotendeels nog in docker-compose zitten en alleen home assistant gebruik ik middels een rule bestand ipv docker compose ivm network mode host.

[CyBeR]

Wildcards moeten via DNS.

[devino]

Bij mij had watchtower afgelopen weekend traefik ook geüpdate naar V2 en dus was alles stuk. Mijn huidige workaround is weer een v1 versie te hebben draaien, maar heeft iemand al een duidelijke/goede migratie tutorial gevonden? Zou me een paar avonden schelen is mijn gevoel

[lolgast]

@martinvdm @devino
Ik heb mijn config (nog) niet online staan. Ik denk niet dat me dat vanavond nog gaat lukken, maar morgen einde middag is wel mogelijk verwacht ik. lolgast in "[Traefik] Ervaringen & Discussie" Zoals aangegeven is mijn complete config nu in YAML, dat maakt de vertaling van TOML v1 niet makkelijker.

Ik heb om het mezelf makkelijk te maken een VPS gestart bij Vultr (daar betaal je per minuut namelijk) en ben daar gaan klooien. Pas toen ik daar al mijn configs had getest ben ik bij mijn thuisserver live gegaan.

Zoals @CyBeR al aangaf, voor wildcards heb je dnscallenge nodig. Per se nodig? Nee. Leuk om te hebben? Ik vind van wel

[ Voor 15% gewijzigd door lolgast op 25-09-2019 21:00 ]

[RobertMe]

lolgast schreef op woensdag 25 september 2019 @ 19:59:
Zoals @CyBeR al aangaf, voor wildcards heb je dnscallenge nodig. Per se nodig? Nee. Leuk om te hebben? Ik vind van wel

DNS challenge bied meer voordelen. Zo werkt het ook voor (sub)domeinen die niet aan het internet hangen. Op het werk hebben we <bedrijfsnaam>.dev geregistreerd. Mijn lokale ontwikkelomgeving is vervolgens op het bedrijfsnetwerk beschikbaar via robert.<bedrijfsnaam>.dev, maar dit subdomein staat dus niet bij TransIP ingesteld en wordt door de lokale DNS (/AD) server 'verstrekt'. Maar Traefik kan via de DNS challenge naar TransIP dus wel bewijzen de eigenaar van (robert.)<bedrijfsnaam>.dev te zijn.

[martinvdm]

@lolgast top! Ben heel benieuwd. Migratie naar yaml is wellicht wel lastiger, maar zou ook mijn voorkeur hebben. DNS challenge heb ik ook draaien nu met wildcards in v1.

[lolgast]

@martinvdm @daansan Ik heb de files toch maar even geüploaded
https://github.com/lolgast1987/traefik

Files zijn wat aangepast met wat verwijderde prive info

[martinvdm]

lolgast schreef op woensdag 25 september 2019 @ 20:59:
@martinvdm @daansan Ik heb de files toch maar even geüploaded
https://github.com/lolgast1987/traefik

Files zijn wat aangepast met wat verwijderde prive info

Thanks! Eerlijk gezegd vind ik het maar onnodig complex geworden. Moet ook nog maar zien dat ik weer een A+ score voor elkaar kan krijgen, zaken als hsts, fs, sni en de juiste cypher suites. Als ik tijd heb ga ik er eens in duiken.

[DvD77]

Thnx @lolgast voor de files en uitleg.

Ik ga er binnenkort ook maar eens voor zitten.

Hier nog een config gevonden van iemand die ook gemigreerd is naar v2.0 en gebruik maakt van een file rule ivm host docker config.

https://github.com/cooperaj/home-assistant-config

[DiedX]

Maar: behalve mooie grafieken en integratie van letsencrypt, wat is het grote verschil met haproxy?

[RobertMe]

DiedX schreef op woensdag 25 september 2019 @ 23:31:
Maar: behalve mooie grafieken en integratie van letsencrypt, wat is het grote verschil met haproxy?

Ik ben niet bekend met HAProxy, maar naar mijn idee zit de kracht van Traefik voornamelijk in de dynamische configuratie. Stel in dat je Docker wilt gebruiken en bij het starten van een nieuwe willekeurige Docker container zet je een aantal labels op die container, Traefik ziet dat, en configureert zichzelf meteen om ook als reverse proxy dienst te doen voor die container. En dat dan niet alleen voor Docker, maar ook Kubernetes en andere services/diensten. "Zelf" de configuratie schrijven in een bestand hoeft dus niet meer (kan wel, hoeft niet). En als eens een keer een Docker container herstart en deze zou een ander IP adres krijgen is dat dus ook geen issue, want Traefik leest zelf het IP adres uit.

[lolgast]

@DiedX De performance van HAproxy is volgens mij beter, maar dat is vooral merkbaar wanneer je de proxies zwaar gaat belasten, met af een toe een request voor thuisgebruik ga je dat waarschijnlijk niet opmerken.

Wat voor mij ook een groot pluspunt is, is de integratie van Lets Encrypt. In het meest gunstige geval heb je een DNS leverancier die ondersteuning heeft voor LeGO. Zo niet, dan kan Traefik per hostnaam een certificaat aanvragen en zorgen dat deze vernieuwd wordt wanneer nodig. Geen gedoe met certificate chains configureren zoals ik dat bij NGINX moest doen. Als Traefik werkt, werkt mijn certificaat.

Edit:
@martinvdm Ik heb even de tijd genomen om voor een A+ rating te gaan. HSTS had ik al geregeld, die staat in de middlewares.yml in de rules map. Ik heb een extra bestand, tls.yml aangemaakt. Ook in de rules map. Hierin zijn de default TLS opties te configureren, als ook specifieke die je per router (docker container) kunt koppelen. Ik heb geen idee wat je met FS bedoelt, maar als het Forward Secrecy is, dat werkt ook.

Deze config levert dit op: https://www.ssllabs.com/s....html?d=images.lolgast.nl

[ Voor 28% gewijzigd door lolgast op 27-09-2019 10:49 ]

[daansan]

lolgast schreef op woensdag 25 september 2019 @ 20:59:
@martinvdm @daansan Ik heb de files toch maar even geüploaded
https://github.com/lolgast1987/traefik

Files zijn wat aangepast met wat verwijderde prive info

bedankt @lolgast ik ga hier snel eens naar kijken, als ik nog iets geks vind dan laat ik het hier weten!

[CyBeR]

RobertMe schreef op woensdag 25 september 2019 @ 23:39:
[...]

Ik ben niet bekend met HAProxy, maar naar mijn idee zit de kracht van Traefik voornamelijk in de dynamische configuratie. Stel in dat je Docker wilt gebruiken en bij het starten van een nieuwe willekeurige Docker container zet je een aantal labels op die container, Traefik ziet dat, en configureert zichzelf meteen om ook als reverse proxy dienst te doen voor die container. En dat dan niet alleen voor Docker, maar ook Kubernetes en andere services/diensten. "Zelf" de configuratie schrijven in een bestand hoeft dus niet meer (kan wel, hoeft niet). En als eens een keer een Docker container herstart en deze zou een ander IP adres krijgen is dat dus ook geen issue, want Traefik leest zelf het IP adres uit.

Op zich kan dat met HAProxy ook alleen moet je daar inderdaad iets meer zelf regelen om dat voor elkaar te krijgen waar 't bij Traefik min of meer het hele punt is.

[martinvdm]

@lolgast met een beetje ploeteren ben ik om naar 2.0 en ook in Yaml. Dank voor je voorbeeld config!
Op zich lijkt alles wel goed te werken, alleen krijg ik geen HSTS werkend, terwijl ik wel in middleware de zaken hiervoor bepaald heb:

code:

    hsts:
      headers:
        sslRedirect: true
        stsPreload: true
        stsSeconds: 315360000
        stsIncludeSubdomains: true

jij een idee?
TLS1.3 pakt ie dan weer wel in ssllabs, maar hsts niet

Edit: ik moest dit nog in mijn docker label zetten om de verwijzing te maken.
- "traefik.http.routers.website.middlewares=hsts@file"

[ Voor 15% gewijzigd door martinvdm op 28-09-2019 00:25 ]

[martinvdm]

Gebaseerd op onder ander de config van @lolgast heb ik even een blog post gemaakt van de traefik2.0 setup. Voor de geïnteresseerde, zie hier.

[Fusioxan]

Na een weekendje stoeien is het mij uiteindelijk ook gelukt om de overstap naar V2.0 te maken. Voor de zekerheid toch maar traefik:v2.0.0 gebruiken, anders kom ik daar op een minder leuke manier achter door Watchtower.

Op dit moment maak ik ook al dankbaar gebruik van de TLS entrypoints bij mn Bitwarden en Gitlab container.

Zijn er toevallig al mensen die Unifi nu ook geimplementeerd hebben met v2.0 icm TCP entrypoints? Weet niet of het "verstandig" is om deze daadwerkelijk als entrypoint toe te voegen of gewoon gebruik te maken van exposed ports op mn thuisservertje. Volgens de image van linuxserver moeten er namelijk de volgende naar buiten gebracht worden: 3478, 10001, 8080, 8081, 8443, 8843, 8880 en 6789.

[ Voor 4% gewijzigd door Fusioxan op 29-09-2019 22:43 ]

[lolgast]

Ik krijg het trouwens niet voor elkaar om de websockets van Unifi-NVR werkend te krijgen. De live camera feed loopt over wss://nvr.domain.nl:7446. Websockets zouden ondersteund zijn door Traefik, maar dit loopt dus over een andere poort.

Ik kreeg dit ook al niet werkend bij v1. Iemand die me kan vertellen hoe ik dat moet instellen?

[RobertMe]

lolgast schreef op maandag 30 september 2019 @ 09:34:
Ik krijg het trouwens niet voor elkaar om de websockets van Unifi-NVR werkend te krijgen. De live camera feed loopt over wss://nvr.domain.nl:7446. Websockets zouden ondersteund zijn door Traefik, maar dit loopt dus over een andere poort.

Ik kreeg dit ook al niet werkend bij v1. Iemand die me kan vertellen hoe ik dat moet instellen?

In v1 kon je dit doen voor meerdere front & backends te declareren. Hoe dit in V2 moet durf ik echter niet te zeggen, want die draai ik (nog) niet.

Ik heb wel een voorbeeld van V1, wat ik zelf gebruik met de UniFi controller om de portal en admin interface bereikbaar te hebben (wat ook verschillende poorten zijn):

YAML:

        labels:
                - "traefik.admin.frontend.rule=Host:admin.unifi.<...>"
                - "traefik.admin.backend=unifi-admin"
                - "traefik.admin.port=8443"
                - "traefik.admin.domain=admin.unifi.<...>"
                - "traefik.admin.protocol=https"
                - "traefik.portal.frontend.rule=Host:guests.unifi.<...>"
                - "traefik.portal.backend=unifi-portal"
                - "traefik.portal.port=8843"
                - "traefik.portal.domain=guests.unifi.<...>"
                - "traefik.portal.protocol=https"

Het gaat hierbij dus om de extra admin en portal voor de frontend/backend/port labels.

[lolgast]

@RobertMe Dat is de normale Unifi Controller. Dat werkt prima hier inderdaad. Ik heb het over de video variant die ik maar niet aan de gang krijg

[RobertMe]

lolgast schreef op maandag 30 september 2019 @ 10:06:
@RobertMe Dat is de normale Unifi Controller. Dat werkt prima hier inderdaad. Ik heb het over de video variant die ik maar niet aan de gang krijg

Dat het geen direct antwoord op je vraag was weet ik Maar je gaf ook aan dat die websocket over een andere poort loopt, en dit geeft, voor V1 dan, een voorbeeld hoe daarmee om te gaan (meerdere domeinen aan 1 container koppelen en dan dus ook verschillende poorten). Mogelijk dat je met V2 dus om en nabij op hetzelfde uit komt, dus een extra eigen naampje ertussen om aan te geven voor welk front/backend router het label van toepassing is.

[lolgast]

@RobertMe Ik snap je bedoeling inderdaad. Bij Unifi-NVR is de URL hetzelfde, waardoor je al gauw met dezelfde entrypoint te maken hebt. Ik heb (in mijn ogen) al veel geprobeerd met extra services en routers in v2. En in v1 heb ik het precies zoals met jouw voorbeeld geprobeerd, maar om een of andere reden krijg ik het maar niet aan de gang.

Overigens, inmiddels geupgraded naar 2.0.1 zonder problemen

[ Voor 8% gewijzigd door lolgast op 30-09-2019 10:42 ]

[DvD77]

martinvdm schreef op zondag 29 september 2019 @ 21:39:
Gebaseerd op onder ander de config van @lolgast heb ik even een blog post gemaakt van de traefik2.0 setup. Voor de geïnteresseerde, zie hier.

Hoe regel jij de whitelisting van je IP adres voor de API ? Of heb je een fixed ip thuis ?

Edit: Ik zie dat Whitelisten niet verplicht is toch ?

[ Voor 5% gewijzigd door DvD77 op 30-09-2019 10:59 ]

[lolgast]

@DvD77 Als je de whitelisting toepast zoals @martinvdm dat nu heeft gedaan werkt alleen je interne netwerk. Daardoor is de website van buitenaf niet benaderbaar. Hoe vaak komt het voor dat het IP-subnet van je interne netwerk wijzigt? Misschien alleen bij het wisselen van ISP en zelfs dan alleen als je zelf geen DHCP server draait.

Ik heb het bijvoorbeeld zo staan, waardoor ik er vanuit mijn interne netwerk bij kan én vanuit kantoor.

YAML:

http:
  middlewares:
    ipwhitelist:
      ipWhiteList:
        sourceRange:
          - "192.168.4.0/24"
          - "84.23.165.57/32" //Gewijzigd
        ipStrategy:
          depth: 0

Whitelisting is niet verplicht nee. Ik doe het alleen voor de API en mijn test URL, omdat ik daar nogal eens een service aan verbind die totaal niet beschikbaar hoeft/hoort te zijn via het internet

[DvD77]

lolgast schreef op maandag 30 september 2019 @ 11:06:
@DvD77 Als je de whitelisting toepast zoals @martinvdm dat nu heeft gedaan werkt alleen je interne netwerk. Daardoor is de website van buitenaf niet benaderbaar. Hoe vaak komt het voor dat het IP-subnet van je interne netwerk wijzigt? Misschien alleen bij het wisselen van ISP en zelfs dan alleen als je zelf geen DHCP server draait.

Ik heb het bijvoorbeeld zo staan, waardoor ik er vanuit mijn interne netwerk bij kan én vanuit kantoor.

YAML:

http:
  middlewares:
    ipwhitelist:
      ipWhiteList:
        sourceRange:
          - "192.168.4.0/24"
          - "84.23.165.57/32" //Gewijzigd
        ipStrategy:
          depth: 0

Whitelisting is niet verplicht nee. Ik doe het alleen voor de API en mijn test URL, omdat ik daar nogal eens een service aan verbind die totaal niet beschikbaar hoeft/hoort te zijn via het internet

Thnx maar ik bedoelde Whitelisting van de Transip API. maar heb al gevonden dat het zonder whitelisting ook kan... excuus dat ik niet helemaal duidelijk was

[martinvdm]

lolgast schreef op maandag 30 september 2019 @ 09:34:
Ik krijg het trouwens niet voor elkaar om de websockets van Unifi-NVR werkend te krijgen. De live camera feed loopt over wss://nvr.domain.nl:7446. Websockets zouden ondersteund zijn door Traefik, maar dit loopt dus over een andere poort.

Ik kreeg dit ook al niet werkend bij v1. Iemand die me kan vertellen hoe ik dat moet instellen?

Ik ben niet zo bekend met WebSockets, maar heb gelezen dat bij anderen dit de mogelijke fix was:

code:

traefik.http.middlewares.sslheader.headers.customrequestheaders.X-Forwarded-Proto = https

Anders wil je denk ik ook je log file eens goed bekijken.

[ Voor 4% gewijzigd door martinvdm op 30-09-2019 21:56 ]

[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?

[martinvdm]

Kaspers schreef op dinsdag 1 oktober 2019 @ 18:20:
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:

[Afbeelding]

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

[Afbeelding]

En dat valt uiteraard niet te resolven.

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

[Afbeelding].

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?

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

[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 ]

[lolgast]

@Kaspers Traefik en Wordpress draaien op dezelfde host? Want je hebt voor Traefik entrypoint ‘web’ wat normaliter poort 80 is, en in je Wordpres container map je die port ook.

[Kaspers]

lolgast schreef op dinsdag 1 oktober 2019 @ 19:52:
@Kaspers Traefik en Wordpress draaien op dezelfde host? Want je hebt voor Traefik entrypoint ‘web’ wat normaliter poort 80 is, en in je Wordpres container map je die port ook.

Nope, zitten in twee aparte LXC's, dus zijn in feite twee verschillende 'hosts' (traefik draait in host "docker.lan", wordpress in "wordpress.lan").

[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:

[lolgast]

@Kaspers Misschien een foutje in de documentatie, die zijn er vrij veel voor v2. Zie ook de changelog van 2.0.1 Je zou een issue op github kunnen openen

[Meauses]

Erg leuk topic dit! Ik gebruik nu als reverse proxy caddyserver (https://caddyserver.com), ook een light weight webserver/reverse proxy/loadbalancer, maar wil overstappen op traefik.
Heb er even geleden al mee gespeeld, en wil het draaien in mijn docker swarm clustertje, enige wat ik in het thuis gebruik een uitdaging vind is het echt high available maken.
Dit kan wel eventueel op Kubernetes met MetalLB, maar dat is weer wat complexer voor thuis dan docker swarm. Iemand al wat meer ervaring daarmee?

[DvD77]

Nou ik ben ook over naar Traefikv2.0 maar ik krijg mn Unifi niet aan de gang.
HA via file en Grafana via docker werken prima maar Unifi ( docker ) wil niet.

Ik krijg de foutmelding :
Bad Request
This combination of host and port requires TLS.

Ik kan de controller wel via het interne adres bereiken op poort 8443.
Ik heb de tutorial van martinvdm gevolgt overigens.

mijn docker-compose voor unifi :

[code]
unifi:
container_name: unifi
restart: unless-stopped
image: linuxserver/unifi-controller
volumes:
- /home/daniel/docker/unifi:/config
environment:
- PGID=0
- PUID=0
- ES_JAVA_OPTS='-Xms2g -Xmx2g'
ports:
- "8080:8080"
- "8081:8081"
- "8443:8443"
- "8843:8843"
- "8880:8880"
- "3478:3478/udp"

labels:
- traefik.enable=true
- traefik.http.routers.unifi-secured.entrypoints=https
- traefik.http.routers.unifi-secured.middlewares=hsts@file
- traefik.http.routers.unifi-secured.tls=true
- traefik.http.routers.unifi-secured.rule=Host("unifi.domein.naam")
- traefik.http.services.unifi.loadbalancer.server.port=8443

networks:
- traefik
[/code]

zoals gezegd werkt grafana wel, met een zelfde config.

EDIT:

Het werkt....

door het toevoegen van het volgende label :

code:

- traefik.http.services.unifi.loadbalancer.server.scheme=https

[ Voor 6% gewijzigd door DvD77 op 21-10-2019 22:30 ]

[pasz]

Zijn hier ook tweakers die Traefik gebruiken icm ipv6 ?

Ik heb wel een publiek ipv6 adres, maar nog geen ipv6 backend. Iemand die weet of traefik ipv6 kan tunnelen naar ipv4 ?

[DvD77]

Ik heb mijn config gebaseerd op de config van @martinvdm maar ik loop toch tegen een issue aan...
Als er bijvoorbeeld met Home Assistant een unknown login wordt geconstateerd (bv vanaf mijn iPhone op 4g) dan wordt niet mijn externe ip gelogd in Home Assistant maar de localhost (127.0.0.1) met als gevolg dat na 3x proberen de localhost in block mode gaat in HA...

Hoe zorg ik ervoor dat het ip adres van het device netjes zichtbaar is als het door traefik komt ?

[RobertMe]

DvD77 schreef op vrijdag 24 januari 2020 @ 20:01:
Ik heb mijn config gebaseerd op de config van @martinvdm maar ik loop toch tegen een issue aan...
Als er bijvoorbeeld met Home Assistant een unknown login wordt geconstateerd (bv vanaf mijn iPhone op 4g) dan wordt niet mijn externe ip gelogd in Home Assistant maar de localhost (127.0.0.1) met als gevolg dat na 3x proberen de localhost in block mode gaat in HA...

Hoe zorg ik ervoor dat het ip adres van het device netjes zichtbaar is als het door traefik komt ?

Home assistant moet je daarvoor de X-FORWARDED-FOR header laten uitlezen. Zie hier hoe je dat doet: https://www.home-assistan...-configure-home-assistant

[DvD77]

RobertMe schreef op vrijdag 24 januari 2020 @ 20:04:
[...]

Home assistant moet je daarvoor de X-FORWARDED-FOR header laten uitlezen. Zie hier hoe je dat doet: https://www.home-assistan...-configure-home-assistant

Ik was al een beetje in die richting aan het zoeken.
Dit had ik al in mn config staan , desondanks deed ie het niet:

code:

trusted_proxies:
  -xxx.xxx.xxx.xxx ( local ip traefik)

ik had alleen localhost )127.0.0.1 er nog niet in staan, dit omdat de proxy ook niet op de die docker draait toch ? Doesnt make sense om dan localhost ook toe te voegen.

[RobertMe]

DvD77 schreef op vrijdag 24 januari 2020 @ 20:21:
[...]


Ik was al een beetje in die richting aan het zoeken.
Dit had ik al in mn config staan , desondanks deed ie het niet:

code:

trusted_proxies:
  -xxx.xxx.xxx.xxx ( local ip traefik)

ik had alleen localhost )127.0.0.1 er nog niet in staan, dit omdat de proxy ook niet op de die docker draait toch ? Doesnt make sense om dan localhost ook toe te voegen.

Mogelijk dat beide containers in een ander netwerk/bridge zitten en potentieel worden geNAT door de host of iets dergelijks?

[Hmmbob]

DvD77 schreef op vrijdag 24 januari 2020 @ 20:21:
[...]


Ik was al een beetje in die richting aan het zoeken.
Dit had ik al in mn config staan , desondanks deed ie het niet:

code:

trusted_proxies:
  -xxx.xxx.xxx.xxx ( local ip traefik)

ik had alleen localhost )127.0.0.1 er nog niet in staan, dit omdat de proxy ook niet op de die docker draait toch ? Doesnt make sense om dan localhost ook toe te voegen.

Maar heb je ook deze erin gezet?

use_x_forwarded_for: true

[DvD77]

Hmmbob schreef op vrijdag 24 januari 2020 @ 20:39:
[...]

Maar heb je ook deze erin gezet?

[...]

Si, stond er al in

Ik heb net via hacs even authenticator geinstalleerd, ik zie nu wel externe ip addressen verschijnen van de authenticated devices. Alleen die van mij nog niet
EDIT : het lijkt te werken nu .. eigenlijk alleen maar door het toevoegen van 127.0.0.1 als trusted proxy.. Vaag

RobertMe schreef op vrijdag 24 januari 2020 @ 20:32:
[...]

Mogelijk dat beide containers in een ander netwerk/bridge zitten en potentieel worden geNAT door de host of iets dergelijks?

De home assistant docker werkt via host mode, de traefik docker hangt n zn eigen docker netwerk.

[ Voor 41% gewijzigd door DvD77 op 24-01-2020 20:56 ]

[martinvdm]

DvD77 schreef op vrijdag 24 januari 2020 @ 20:46:
[...]


Si, stond er al in

Ik heb net via hacs even authenticator geinstalleerd, ik zie nu wel externe ip addressen verschijnen van de authenticated devices. Alleen die van mij nog niet
EDIT : het lijkt te werken nu .. eigenlijk alleen maar door het toevoegen van 127.0.0.1 als trusted proxy.. Vaag

[...]


De home assistant docker werkt via host mode, de traefik docker hangt n zn eigen docker netwerk.

volgens mij heb je idd alleen maar dit nodig:

code:

http:
  base_url: !secret http_base_url
  use_x_forwarded_for: true
  trusted_proxies:
    - x.x.x.x/x

[mithras]

Ik zit op een nieuwe DigitalOcean droplet te spelen met Ansible en wil ook Traefik installeren. Ik heb bijv deze guide die eea uitlegt.

Op zich is de installatie vrij simpel, maar geen enkele tutorial geeft handig aan wat best practice is waar je traefik draait en welke user daar bij komt kijken.

1. Een ansible playbook schrijft weg onder /var/www/traefik (best goede keuze) als root:docker. Ben zelf niet zo'n voorstander om containers / bestanden als root te plaatsen
2. Onder ~/traefik en je eigen username, wel lekker makkelijk in bewerken maar ik zou liefst mijn persoonlijke user niet koppelen aan systeem installaties

Dacht zelf eerder om /var/www/traefik te gebruiken en www-data hiervoor in te zetten. Dan kan je ook je andere containers daarnaast op die manier draaien.

Heeft iemand hier nog een best practice voor?

[iGrasmat]

Voor mensen die nog strugglen met overschakelen naar v2.0, deze guide is een paar uur geleden online gekomen en kan hopelijk wat dingen ophelderen.

[Hmmbob]

iGrasmat schreef op zaterdag 22 februari 2020 @ 06:13:
Voor mensen die nog strugglen met overschakelen naar v2.0, deze guide is een paar uur geleden online gekomen en kan hopelijk wat dingen ophelderen.

Top, ik heb dit weekend weer wat te doen

[lolgast]

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

[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 ]

[H143]

ik heb al een paar maand nu traefik 2.0 draaien en werkt perfect.
nu wil ik graag nog ook mijn synology toevoegen met name de photostation

ik kan hem intern bereiken via 192.168.1.110/photo

code:

http:
  routers:
    photo:
      entryPoints:
        - https
      service: service-photo
      rule: Host("photo.mijnsite.nl")
      tls: {}

  services:
    service-photo:
      loadBalancer:
        servers:
          - url: http://192.168.1.110/photo
        passHostHeader: true
        passTLSCert: true

alleen om nu photo station te benaderen moet ik gaan naar photo.mijnsite.nl/photo kan ik dit ook aanpassen naar photo.mijnsite.nl?

[lolgast]

@H143 Volgens mij is de functie ‘AddPrefix’ daarvoor

[ Voor 9% gewijzigd door lolgast op 28-02-2020 21:06 ]

[Phontana]

Ik heb deze week ook Traefik opgezet als vervanging van JWilder's nginx-proxy. Toen het concept van Traefik me eenmaal duidelijk was, was het best gemakkelijk om alles om te zetten. Nu heb ik echter nog een probleem waar ik niet uit kom. Ik heb Pihole in mijn netwerk draaien met de volgende config:

code:

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.pihole.rule=HostRegexp(`pihole.home.lan`, `{catchall:.*}`)"
  - "traefik.http.routers.pihole.priority=1"
  - "traefik.http.routers.pihole.entrypoints=http"
  - "traefik.http.services.pihole.loadbalancer.server.port=80"

Op mijn router heb ik poort 80 en 443 open staan omdat ik ook een aantal containers heb die ik extern wil kunnen benaderen. Dit werkt allemaal goed i.c.m. Let's Encrypt certificaten, maar ik kwam er ook achter dat als ik mijn server benader op mijn publieke IP dat ik dan op de Pihole web pagina terechtkom wat ik niet wil van buitenaf. Ik vermoed dat het met de catchall in de rule-regex te maken heeft, maar als ik die weghaal dan kan ik intern ook niet meer bij Pihole op poort 80. Eigenlijk zou ik het liefste willen dat ik het verkeer naar Pihole op poort 80 intern wel kan doorlussen, maar vanaf mijn publieke IP niet.

[lolgast]

@Phontana je zou met ipwhitelisting kunnen werken en alleen in je interne subnets/ip adressen toegang geven. Niet de perfecte oplossing denk ik, maar het werkt wel.
https://docs.traefik.io/middlewares/ipwhitelist/

[Hmmbob]

Is de eigenlijke optie niet om die catch-all simpelweg naar iets anders te laten verwijzen? Bijvoorbeeld een webserver of een statische pagina?

[Phontana]

Hmmbob schreef op zaterdag 14 maart 2020 @ 18:54:
Is de eigenlijke optie niet om die catch-all simpelweg naar iets anders te laten verwijzen? Bijvoorbeeld een webserver of een statische pagina?

Zoiets was ik inderdaad wel al tegen gekomen. De web poort van Pihole is aan te passen, bijv. als je de container met net=host runt en daardoor poort 80 niet kunt publishen op een andere poort van de host. Ik kan het zo snel niet terugvinden, maar ik had wel al een oplossing gezien waarmee je een andere 'lege' pagina kunt teruggeven in plaats van de standaard pagina van Pihole. Dit zou ik eens kunnen gaan proberen.

lolgast schreef op zaterdag 14 maart 2020 @ 18:36:
@Phontana je zou met ipwhitelisting kunnen werken en alleen in je interne subnets/ip adressen toegang geven. Niet de perfecte oplossing denk ik, maar het werkt wel.
https://docs.traefik.io/middlewares/ipwhitelist/

Dat is eigenlijk wel waar ik naar op zoek was, alleen toegang geven binnen mijn interne netwerk. Ook hier zal ik eens mee gaan stoeien. Bedankt!

Edit: @lolgast ik heb een middleware aangemaakt die als IP range mijn lokale netwerk bevat, en dit doet precies wat ik wil. Er wordt nu een 403 response gegeven als je van buitenaf binnenkomt.

[ Voor 8% gewijzigd door Phontana op 14-03-2020 19:35 ]

[lolgast]

Top, mooi dat het werkt

[stefve1]

Ik heb afgelopen weekend ook de overstap gemaakt naar V2. Nu werkt bijna alles zoals het zou moeten, alleen zit ik nog met het volgende.

Ik heb twee domeinnamen die ik gebruik in Traefik (Via Cloudflare). Nu zou ik graag van beide domeinnamen een wildcard willen hebben. Voor de installatie heb ik de tutorial van martinvdm gevolgd. Daarin doet hij het volgende:

[code]
http:
routers:
certs:
entryPoints:
- http
- https
service: service-blank
rule: Host("about:blank")
tls:
certResolver: letsencrypt
domains:
- main: "*.yoursite.com"
sans:
- yoursite.com
services:
service-blank:
loadBalancer:
servers:
- url: "https://about.blank"
[/code]

Wat is nu de beste manier om ervoor te zorgen dat hij twee wildcards maakt, en dat Traefik het juiste wildcard neemt?
Ik heb al vanalles proberen aan te passen in dit bestand, maar het lukt mij alleen door de volledige domeinnaam bij in de SANs lijst te zetten.

Reeds opgelost. Moest gewoon een extra "main" block toevoegen en wat geduld hebben

[ Voor 4% gewijzigd door stefve1 op 16-03-2020 15:04 ]

[Jazco2nd]

Heeft iemand Traefik werkend icm een gratis freedns (afraid.freedns.org) subdomain?
Ik heb hier wel een guide gevonden die het ondersteund maar dat is voor Traefik 1.x:
https://www.smarthomebegi...th_Apps_as_Subdirectories

[B2]

Ik ben ook bezig de overstap te maken van traefik 1.7 naar 2.2.
Waar ik voorheen redelijk eenvoudig een certificaat per applicatie kon maken (of via docker, of via een toml file) lukt het met 2.2 niet helemaal zoals ik wil. Wildcard certificaat lukt, een domain certificaat, met daarin een aantal aliassen lukt, maar dat is niet wat ik voor ogen heb.

Met 2.2 gebruik ik ook voor het eerst DNSChallenge via de transip api. Moet ik dan bij Transip de entries al in dns hebben staan, of kan traefik dat voor mij doen?

Ik heb nu de volgende configuratie, maar dat geeft dus een certificaat voor het hele domein (volgens mij moet ik dat niet doen, want dan lekt het certificaat informatie welke aliassen er allemaal zijn en is er een dubbel certificaat (traefik letsencrypt + bij transip) voor het domein.

code:

http:
  routers:
    certs:
      entryPoints:
        - http
        - https
      service: service-blank
      rule: Host("about:blank")
      tls:
        certResolver: letsencrypt
        domains:
          - main: "xxx.xx"
            sans:
              - a.xxx.xx
              - b.xxx.xx
              - c.xxx.xx
              - d.xxx.xx

  services:
    service-blank:
      loadBalancer:
        servers:
          - url: "https://about.blank"

Het liefst zou ik ook niet de benodigde certificaten in bovenstaande file op willen moeten noemen, maar dat traefik dit automatisch ziet via docker. Is dit mogelijk?

[JBS]

Traefik gebruik ik om diverse docker containers via eigen subdomeinen met SSL bereikbaar te maken. Dat werkt voor alle containers waarvoor ik dat graag wil, op één na: https://github.com/linuxserver/docker-code-server

Docker compose:

code:

  code-server:
    image: linuxserver/code-server
    container_name: code-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PASSWORD=xxx
    volumes:
      - ./code-server:/config 
      - ./:/home/ 
    ports:
      - 9876:8443
    restart: unless-stopped

Voor alle containers maak ik bij TransIP een subdomein aan en een toml bestand in de rules map van Traefik, zo ook voor deze container:

code:

[frontends]
  [frontends.code]
  backend = "code"
    [frontends.code.routes.code]
    rule = "Host:code.domein.nl"
  passHostHeader = true
  passTLSCert = true
  priority = 10
  entrypoints = ["https"]
[backends]
  [backends.code]
    [backends.code.servers.server1]
    url = "http://192.168.178.24:9876"
    weight = 1

Al m'n toml bestanden in de rules map zien er hetzelfde uit, behalve:

• Overal waar nu 'code' staat, staat in de andere rule bestanden de betreffende subdomein-naam.
• URL verwijst uiteraard steeds naar de juiste locatie.

Wat er nu gebeurt in geval van deze docker container: De docker container is bereikbaar via het subdomein code.domein.nl, maar in de browser zie ik deze doorgezet worden naar het interne IP adres (http://192.168.178.24:987). Dat werkt dus enkel thuis en niet zoals het voor de andere subdomeinen met achterliggende docker containers werkt.

Iemand een idee of zelfde ervaring?

(Mogelijk zijn m'n toml bestanden in de rules niet feilloos of kunnen ze beter, maar het werkt voor pakweg 15 docker containers met bijbehorende subdomeinen, behalve deze.)

[Matis]

Een aantal weken geleden ben ik in aanraking gekomen met Traefik. Dat lijkt toch een stuk flexibeler en beter onderhouden te zijn dan HAProxy op pfSense.
Dat laatste gebruik ik nu om extern verkeer te routeren naar de diverse (web)servers binnen mijn thuisnetwerk. Dat werkt allemaal aardig, maar het vergt zoveel (handmatig) aanpassen en de configuratie file van HAProxy is (mede omdat het gegenereerd wordt) een draak.

Op dit moment heb stuur ik verkeer van poort 80 op het WAN-adres (via NAT) door naar de server binnen mijn thuisnetwerk. Op deze server heb ik nu Traefik geconfigureerd en alles werkt prima.
Op dit moment sta ik op het punt om ook poort 443 en daarmee TLS te gaan doorsturen naar de server.

Ik heb het domeinnaam van mijn WAN-adres geregistreerd bij TransIP. Echter kom ik niet helemaal uit de documentatie hoe ik deze binnen de config-file van Traefik moet configureren. Ik gebruik de YAML notatie.

Traefik zelf draait binnen een docker-compose omgeving. Waarnaast ik ook een whoami-container heb draaien om alles mee te testen.

YAML:

version: '3'

services:
  reverse-proxy:
    image: traefik:v2.1
    container_name: traefik
    network_mode: host
    volumes:
      # So that Traefik can listen to the Docker events
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik.yml:/etc/traefik/traefik.yml
      - ./config:/traefik/config

  whoami:
    # A container that exposes an API to show its IP address
    image: containous/whoami
    labels:
      - "traefik.http.routers.whoami.rule=Host(`whoami.docker.localhost`)"

In de "statische" configuratie staat nu het volgende

YAML:

entryPoints:
  web:
   address: ":80"
  websecure:
    address: ":443"

providers:
  docker: {}
  file:
    directory: /traefik/config
    watch: true

api:
  insecure: true
  dashboard: true
  debug: true

En als laatste de config van de router voor whoami

YAML:

## Dynamic configuration
http:
  routers:
    whoami-router:
      rule: "Host(`whoami.localhost`, `whoami.domeinnaam.nl`)"
      service: whoami-traefik@docker

Zoals eerder aangegeven, kan ik prima vanuit buiten op whoami.domeinnaam.nl en intern via whoami.localhost op de whoami-container komen. Ik zie dan ook alle bijbehorende IP-adressen en headers.

Nu wil ik het ook graag gaan configureren voor HTTPS / TLS. Ik heb in dit topic een deel van de configuratie van lolgast in "[Traefik - Proxy/Loadbalancer] Ervaringen & Discussie" geprobeerd om te knutselen naar mijn configuratie, maar ik krijg het niet voor elkaar.

Ik heb het idee dat de configuratie nog op versie 1.x van Traefik berust.

Ik heb het volgende gedaan:
In de CP van TransIP heb ik een whitelist "Key Pairs" aangemaakt met als label traefik. Natuurlijk heb ik ook mijn externe IP-adres toegevoegd aan de whitelist

Nu probeer ik de informatie in https://docs.traefik.io/https/acme/#providers en https://go-acme.github.io/lego/dns/transip/ te mappen naar de zojuist verkregen "Key Pairs".

Ik snap echter niet hoe ik dit in Traefk moet invullen / configureren.

Wie kan mij de juiste kant op duwen?

[lolgast]

@Matis Waarschijnlijk moet je je docker-compose aanpassen. Die van mij ziet er zo uit

YAML:

version: '3'

services:
  traefik:
    container_name: traefik
    image: traefik
    restart: always
    ports:
      - 80:80
      - 443:443
    networks:
      - traefik
    environment:
      - TRANSIP_ACCOUNT_NAME=USERNAME
      - TRANSIP_PRIVATE_KEY_PATH=.privkey
    volumes:
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./logfile.log:/etc/traefik/logfile.log
      - ./acme.json:/acme.json
      - ./rules:/rules:ro
      - ./.htpasswd:/.htpasswd:ro
      - ./.privkey:/.privkey:ro
      - /var/run/docker.sock:/var/run/docker.sock

In diezelfde directory staat het bestand .privkey, daarin staat de privatekey van Transip.

code:

-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC5oLrMp6lcCPao
gZoy4i4rM5QKGsR1BJW7TNTYnc5qpwOO0lkKkoJP7Z+3h0pHBRdjoxvd4zAp+NFe
AwcwL6Yn9ch2ljyBVtyiYhHd1GwJn0JcyQVZQxmwUUisIE0EgzXGaAxymsakKaag
80yxlHkDoj3XlfdmJb5FfGQno0vUd5znMbfs2ei+v/UP/t1b2zjc2S/XWPXnPFNX
LIbL34w7W47HoFI1TGNf/DRlrREe7mFvoDaZ0HZuG1D5DrR4CHEK7+3gF2r8qk0o
4QTRcNHRZQKBgFuen2mgeunqOtlB3g1iaOYxxqDY1ODJL8IlnG4TsmkFwfroonUm
YVzrLVD9AgMBAAECggEAYtTVwBLgU/UdxpfCTqcn5659emfIA3mecuu0Q2S5uwUT
Gt6Zs8xPf1jH+cIZZPir/EuikZ/dS+uDJWe9UwV7lLkCs0jIDCEANaC7XH01zGWz
wozwwRa9vad5ZtOHzghCAFHzlq0bZ9oZMoZ3ZfDkAXBHNtpMr2EXDg3tkUEbJZJl
G2nTBreyxxp0gLlzzlljZQcXSdMU7wXNshBMydDOwfZZxkX0SQOw/JMj1aJr2tdJ
t3yPxEsao4s7ivQLqjQ0DINxg6tYU99ASuPB5W2we/1UT2IWOCCIYYoPryIiQWWb
bhAFEAozXj/9qH9NYgtFIOX95u0LObhIEK6TwXbyYQKBgQDpI2LVhq4R7ERhfzFn
ASEqop7NfGEh0lU0y2iq57hN4/B7UDf81RBhDy5zs2hoJA2r6mRaccnAfUWGKigl
3n/VIwHQwXOzeHGL855P+qQk0c16sG4lXuV53oa3R3k6DXIA/26XcSrNg+gGcwgW
OoiSDTjOz43v6Xn3IYi1ahCTuQKBgQDL1Kk8iLUKF7XTU+S8nmbAHFvC2SXMnjlU
/5eTOKDJLDh5Ke2DI1nEQRlXztDjQzACQSjFi/548tp6fYh4xEkfX+lBsyDaFeNP
ZDs7uCYapBBirbB5Gchjj3CPW2Vf0Z07AKiiS41V0nDShKUpgxtawWLtX9O4Nnvf
4QTRcNHRZQKBgFuen2mgeunqOtlB3g1iaOYxxqDY1ODJL8IlnG4TsmkFwfroonUm
X8TjjW1tCrdgZP23JgymvsrTXXs9nQjbi8sb7cu3Kpv+GklQnQd7TWR22tR7X13q
VC43iCOgwABTZlkECNcVDygizV0zeZsat68F6SxFHteInnjDQfFhVFBpAoGANlGo
/BnObS8eZH/x8BYiecXU6lsmCJ6N1sn6YeBwcMwZDKkQw6bTEErs7wqNflL0Y1Vs
ASEqop7NfGEh0lU0y2iq57hN4/B7UDf81RBhDy5zs2hoJA2r6mRaccnAfUWGKigl
yIJr2tgm+uMghKyMyKXKsEmeSXQzlNkJiKsRL0UCgYB1TgaemfrdmjGckX4H+EoN
73tH3iQjaq+4TcisjaDX/qs5s1/MiyYfgr97OJceSa4GoyOwMr3pTxPhaki62TbO
ZQplX7KgfyTwL2QQmwdCWZzo2WLzmCIYYw/Sz/2XoFvTPQljEzB0v7Ha6i2HRaMt
Vz4ZBQUM4iFcVHHmFiAPOA==
-----END PRIVATE KEY-----

^{voor de oplettende mens, ja klopt hij is aangepast en er staan dubbele regels in}

In mijn traefik.yml staat vervolgens dit

YAML:

certificatesResolvers:
  letsencrypt:
    acme:
      email: [e-mail]
      storage: acme.json
      dnsChallenge:
        provider: transip
        delayBeforeCheck: 0

[lolgast]

Ten eerste: modje, excuses voor de dubbel post. Ik ben echter van mening dat bovenstaande post als reactie 0,0 met onderstaande te maken heeft. En er is alweer wat tijd overheen gegaan

Versie 2.2.0 is inmiddels al even uit. Voor mij een hele fijne toevoeging, redirection

YAML:

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

Deze functie zat ook in 1.x en was verwijderd bij 2.0. Waardoor je voor élke service moest instellen dat http verkeer geredirect moest worden naar https. Via bovenstaande werkt het weer gewoon op globaal niveau.

Ook is er nu trouwens ondersteuning voor UDP. Daar ga ik nu mee spelen. Hopelijk een mooie manier om pihole te loadbalancen

[ Voor 4% gewijzigd door lolgast op 06-04-2020 10:53 ]

[mithras]

lolgast schreef op maandag 6 april 2020 @ 10:52:
Versie 2.2.0 is inmiddels al even uit. Voor mij een hele fijne toevoeging, redirection

YAML:

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

Deze functie zat ook in 1.x en was verwijderd bij 2.0. Waardoor je voor élke service moest instellen dat http verkeer geredirect moest worden naar https. Via bovenstaande werkt het weer gewoon op globaal niveau.

Ook is er nu trouwens ondersteuning voor UDP. Daar ga ik nu mee spelen. Hopelijk een mooie manier om pihole te loadbalancen

Ja zeker weer hele fijne update naar 2.2! Op dit moment deploy ik alle sites geautomatiseerd via Ansible, dus daar was het niet zo'n punt om een dubbele config op te nemen om een redirect uit te voeren. Wel blij dat het nu wat schoner kan worden opgelost.

Voor mij ben ik vooral heel benieuwd naar de UDP routering. Ik heb openvpn achter Traefik hangen met een TCP router op :443 omdat dit verkeer bijna altijd wordt toegestaan. Een openvpn client kan met meerdere remotes werken, dus als je dan eerst :1194/udp hebt staan en daarna :443/tcp heb je eigenlijk best of both worlds

[RobertMe]

lolgast schreef op maandag 6 april 2020 @ 10:52:
Ook is er nu trouwens ondersteuning voor UDP. Daar ga ik nu mee spelen. Hopelijk een mooie manier om pihole te loadbalancen

Die snap ik niet. DNS is toch al load balanced in principe. Gewoon meerdere DNS servers opgeven en gaan met die banaan. Enige voordeel wat Traefik kan geven is als je echt vaak/dynamisch nieuwe Pi-Hole instances start, maar waarom zou je dat doen? Als in: bij een PC etc duurt het potentieel even voordat die ziet dat DNS server niet bereikbaar is, terwijl Traefik meteen kan zien dat de service (/het backend) weg is en dus niet meer daarnaar proxied. Maar lijkt mij juist dat het aantal DNS servers (/Pi-Hole instanties) redelijk fixt is en dat maar eens in de X maanden/jaren of zo veranderd. En juist het introduceren van een Single Point of Failure door Traefik ervoor te zetten lijkt mij dan nadeliger.

[JBS]

JBS schreef op woensdag 1 april 2020 @ 18:07:
Traefik gebruik ik om diverse docker containers via eigen subdomeinen met SSL bereikbaar te maken. Dat werkt voor alle containers waarvoor ik dat graag wil, op één na: https://github.com/linuxserver/docker-code-server

Docker compose:

code:

  code-server:
    image: linuxserver/code-server
    container_name: code-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PASSWORD=xxx
    volumes:
      - ./code-server:/config 
      - ./:/home/ 
    ports:
      - 9876:8443
    restart: unless-stopped

Voor alle containers maak ik bij TransIP een subdomein aan en een toml bestand in de rules map van Traefik, zo ook voor deze container:

code:

[frontends]
  [frontends.code]
  backend = "code"
    [frontends.code.routes.code]
    rule = "Host:code.domein.nl"
  passHostHeader = true
  passTLSCert = true
  priority = 10
  entrypoints = ["https"]
[backends]
  [backends.code]
    [backends.code.servers.server1]
    url = "http://192.168.178.24:9876"
    weight = 1

Al m'n toml bestanden in de rules map zien er hetzelfde uit, behalve:

• Overal waar nu 'code' staat, staat in de andere rule bestanden de betreffende subdomein-naam.
• URL verwijst uiteraard steeds naar de juiste locatie.

Wat er nu gebeurt in geval van deze docker container: De docker container is bereikbaar via het subdomein code.domein.nl, maar in de browser zie ik deze doorgezet worden naar het interne IP adres (http://192.168.178.24:987). Dat werkt dus enkel thuis en niet zoals het voor de andere subdomeinen met achterliggende docker containers werkt.

Iemand een idee of zelfde ervaring?

(Mogelijk zijn m'n toml bestanden in de rules niet feilloos of kunnen ze beter, maar het werkt voor pakweg 15 docker containers met bijbehorende subdomeinen, behalve deze.)

Eigenlijk een wat rare en ongebruikelijke vraag misschien, maar toch: Zou er iemand deze docker container https://github.com/linuxserver/docker-code-server eens willen starten en testen of deze via Traefik bereikbaar is? Aangezien ik exact dezelfde werkwijze hanteer bij mijn overige docker containers waarbij het wel probleemloos werkt, en de mensen achter linuxserver geen van allen Traefik gebruiken, weet ik even niet meer waar het te zoeken.

Mocht er overigens iemand een andere container voor VS Code succesvol hebben draaien, dan is dat ook een prima overweging natuurlijk.

[lolgast]

@RobertMe Met als nadeel dat ik nu moet zoeken met welke pihole instance mijn vrouw is verbonden als er iets geblokkeerd wordt Via Traefik als weighted LB zou ik altijd kunnen sturen naar de primary tenzij die down is. Bij een update bijvoorbeeld.

Maar ik moet ook nog gaan testen om voor sommige bestanden van de tweede pihole dezelfde bestanden als die van de primary te gebruiken, maar dan in read-only. Had een dag toch maar 36 uur ofzo

---

@JBS Waarom verwijzen naar je dockerhost ip? Als je alle containers die je via Traefik beschikbaar wilt stellen in hetzelfde docker network als Traefik hangt kun je ze op containernaam verbinden. Dat zou dan dus worden code-server:8443. En gezien de poort zal hij moeten connecten naar het https protocol, ipv http

[ Voor 26% gewijzigd door lolgast op 07-04-2020 12:10 ]

[JBS]

@lolgast Dat mijn Traefik config op sommige vlakken beter kan, geloof ik meteen
Helaas zorgt je suggestie er niet voor dat mijn linuxserver/code-server container via Traefik bereikbaar wordt. 'Iets' is er kennelijk anders dan mijn overige dockers, aangezien de gebruikte werkwijze bij alle overige containers wel werkt.

Ben daarom inmiddels benieuwd of deze container überhaupt wel overweg kan met een reverse proxy als Traefik of dat er wellicht in de container zelf een aanpassing benodigd is. Bereikbaar via http://IPADRESNUC:9876 is ie namelijk wel gewoon.
Vandaar de voorzichtige vraag of iemand dit eens zou willen testen in zijn omgeving.

[ Voor 6% gewijzigd door JBS op 07-04-2020 13:25 ]

[lolgast]

@JBS
Ik heb de container zojuist even gestart, werkt gewoon achter Traefik. Uiteraard Ik heb net als in jouw situatie verbonden naar http://dockerhostip:9876

Enige opvallende dat het héél misschien kan zijn is dat je bij backends bent begonnen bij server1. Default is server0 de eerste. Geen idee of Traefik hier over struikelt. Zelf ben ik al tijden over naar v2 dus kan de v1 config ook niet echt met mijn kant vergelijken

[Anoniem: 427499]

Hmmm ik heb server-code werkend i.c.m. docker compose 2.2 en traefik 2.1.8. Ik gebruik cloudflare als tussenpersoon.

code:

########################### test compose code-server
version: "2.2"

########################### NETWORKS
networks:
    download_internal:
        external:
            name: download_internal
    traefik_proxy:
        external:
            name: traefik_proxy  
services:  
  code-server:
    image: linuxserver/code-server
    container_name: code-server
    hostname: code-server
    restart: unless-stopped
    networks:
      - download_internal
      - traefik_proxy
    ports:
        - "8443:8443"
    volumes:
        - "${USERDIR}/data/code-server:/config"
    environment:
        - PUID=${PUID}
        - PGID=${PGID}
        - TZ=${TZ}  
    labels:
      - traefik.enable=true
      - traefik.http.routers.code-server.rule=Host(`server-code.${DOMAINNAME}`)
      - traefik.http.routers.code-server.entrypoints=https
      - traefik.http.routers.code-server.tls=true
      - traefik.http.services.code-server.loadbalancer.server.port=8443
      - traefik.http.services.code-server.loadbalancer.server.scheme=http
      - traefik.docker.network=traefik_proxy
      - traefik.http.routers.code-server.tls.certresolver=cloudflare
      - traefik.http.middlewares.code-server.headers.sslredirect=true
    mem_limit: 100M
    mem_reservation: 100M
    cpus: 1

edit: Het valt met op de JBS url = "http://192.168.178.24:9876" gebruikt terwijl Traefik met de interne poort kan praten. In principe zou ik de portforwarding weg kunnen laten wat ik bij meer services heb.

[ Voor 6% gewijzigd door Anoniem: 427499 op 07-04-2020 13:45 ]

[JBS]

@lolgast @Anoniem: 427499 Thanks voor jullie moeite!

Het issue zat 'm inderdaad in het stukje rondom backends in het rule bestand. Zoals aangeven zijn die rule bestanden voor al m'n containers (succesvol) hetzelfde, maar ik vond er eentje die afweek, met name in het backens deel. Die inhoud heb ik nu gebruikt voor de code-server container wat direct een werkende situatie oplevert: Bereikbaar via Traefik.

YAML:

[frontends]
  [frontends.code]
    backend="code"
    entryPoints = ["http", "https"]
    passHostHeader = true
    priority = 20
    [frontends.code.routes.docker_host]
      rule="Host:code.domein.nl"
 [backends]
   [backends.code]
     [backends.code.servers.host]
       url = "http://192.168.178.24:9876"
       weight = 1

Los van 't feit dat deze container nu ook werkt, ga ik me eens wat meer verdiepen waarom het nu werkt, en wat de inhoud van die rule bestanden nou eigenlijk precies zegt. Want erg fijn dat het werkt, maar precies snappen waarom doe ik het nog niet. Zo gebruik ik bijvoorbeeld '9876:8443' omdat de Unifi controller al op 8443 zit, maar mogelijk kan ik dat ook ondervangen door te werken met meerdere networks.

[ Voor 7% gewijzigd door JBS op 09-04-2020 13:42 ]

[lolgast]

@JBS Misschien je tijd steken in de migratie naar v2.2.0 (of v2 überhaupt) Door die migratie ben je genoodzaakt enorm veel te lezen, de opzet is compleet veranderd. Dan ben je én bij de tijd vwb ondersteuning/hulp én je snapt hoe het werkt (hopelijk )

[JBS]

lolgast schreef op donderdag 9 april 2020 @ 13:44:
@JBS Misschien je tijd steken in de migratie naar v2.2.0 (of v2 überhaupt) Door die migratie ben je genoodzaakt enorm veel te lezen, de opzet is compleet veranderd. Dan ben je én bij de tijd vwb ondersteuning/hulp én je snapt hoe het werkt (hopelijk )

Goede suggestie
Tijd is wat schaars, dus ik ben wat huiverig. Is het mogelijk v1.x en v2.x naast elkaar te draaien? Zo kan ik v1.x laten draaien voor externe (ongewijzigde) bereikbaarheid van Home Assistant ('onmisbaar', ook voor Google Assistent) en kan ik op m'n gemakje met v2.x aan de slag.

[lolgast]

Lastig, want beide hebben poort 80 en 443 nodig uiteraard. Wat ik heb gedaan is een VPS server gestart (bij Vultr, die zijn lekker goedkoop ). Daar heb ik mijn Docker containers ook gestart samen met Traefik 2.0. Vervolgens per container de migratie naar v2.0 gemaakt. Door gebruik te maken van andere subdomeinen kon ik lekker testen zonder dat mijn productieomgeving werd geraakt.

Thuis testen in een VM met aanpassing van je lokale hosts kan natuurlijk ook, dan kun je alleen geen certificaten laten aanvragen door Traefik. Maar daarvan staat een configvoorbeeld van mij in een reactie hier als het goed is

[Anoniem: 427499]

Migratie naar v2.x was voor mij een ramp. Je kunt met de converter tool (https://docs.traefik.io/migration/v1-to-v2/) je config omgooien, maar dit werkte uiteraard niet.
Ik heb btw enkel poort 443 openstaan.

[lolgast]

@Anoniem: 427499 Ik ben lui, ik gebruik poort 80 voor de auto-redirect naar 443 Scheelt typen van https://

[ Voor 18% gewijzigd door lolgast op 09-04-2020 14:21 ]

[Anoniem: 427499]

lolgast schreef op donderdag 9 april 2020 @ 14:21:
@Anoniem: 427499 Ik ben lui, ik gebruik poort 80 voor de auto-redirect naar 443 Scheelt typen van https://

Snap ik maar daar gebruik ik onderstaande labels voor
Zal wss ook wel weer in de algemene config kunnen

code:

      - traefik.http.middlewares.ombi.headers.sslredirect=true
      - traefik.http.middlewares.ombi.headers.sslforcehost=true

Scheelt dan weer een openstaande poort aan de buitenkant

[ Voor 5% gewijzigd door Anoniem: 427499 op 09-04-2020 14:26 ]

[lolgast]

Dat kan zeker:
https://docs.traefik.io/routing/entrypoints/#middlewares

[Jazco2nd]

Ik begin me in te lezen in Traefik om het te gebruiken voor mijn thuisserver (Seafile, Firefox Sync en Piwigo zijn de enige services die buitenshuis bereikbaar moeten worden).

Het is vrij ingewikkeld, maar juist een paar basic zaken worden niet duidelijk omdat elk artikel hierover gelijk in de "HOE?" vraag duikt, hoe je het op moet zetten. Ik wil eerst begrijpen wat er precies nodig is en wat er gebeurd.

• Ik heb een domeinnaam aangeschaft, voorbeeld.com.
• Hier heb ik een CNAME dns record voor ingesteld zodat het verwijst naar mijn Mikrotik router's Dynamic DNS service (ingebouwd in de router). Die ziet er namelijk zo uit 343f3304b06.sn.mynetname.net.
• Nu wil ik dat de 3 services bereikbaar zijn via:

- seafile.voorbeeld.com
- firefoxsync.voorbeeld.com
- piwigo.voorbeeld.com

1)
Wat ik even mis, is of ik deze subdomeinen bij mijn domein provider eerst moet aanmaken (3x een CNAME instellen)? Zo ja, ik kan daarbij niet instellen dat deze ook naar 343f3304b06.sn.mynetname.net moeten. Dus hoe weet Traefik straks dat juist seafile.voorbeeld.com werd gevraagd en niet voorbeeld.com?
Ik snap dat ik in Docker een subdomein aan een (interne) poort kan koppelen, maar het gaat mij dus om te begrijpen hoe de stap hiervoor werkt.

2)
Als ik helemaal geen subdomeinen instel bij mijn domein provider, worden ze dan toch verwerkt wanneer ik naar seafile.voorbeeld.com ga en 'herkent' door Traefik?

Ik las ook dat je met een wildcard kan werken, maar dat is voor die 3 subdomeinen die ik nodig heb wat overkill.

[RobertMe]

Jazco2nd schreef op dinsdag 14 april 2020 @ 17:55:
Ik begin me in te lezen in Traefik om het te gebruiken voor mijn thuisserver (Seafile, Firefox Sync en Piwigo zijn de enige services die buitenshuis bereikbaar moeten worden).

Het is vrij ingewikkeld, maar juist een paar basic zaken worden niet duidelijk omdat elk artikel hierover gelijk in de "HOE?" vraag duikt, hoe je het op moet zetten. Ik wil eerst begrijpen wat er precies nodig is en wat er gebeurd.

• Ik heb een domeinnaam aangeschaft, voorbeeld.com.
• Hier heb ik een CNAME dns record voor ingesteld zodat het verwijst naar mijn Mikrotik router's Dynamic DNS service (ingebouwd in de router). Die ziet er namelijk zo uit 343f3304b06.sn.mynetname.net.
• Nu wil ik dat de 3 services bereikbaar zijn via:

- seafile.voorbeeld.com
- firefoxsync.voorbeeld.com
- piwigo.voorbeeld.com

1)
Wat ik even mis, is of ik deze subdomeinen bij mijn domein provider eerst moet aanmaken (3x een CNAME instellen)? Zo ja, ik kan daarbij niet instellen dat deze ook naar 343f3304b06.sn.mynetname.net moeten. Dus hoe weet Traefik straks dat juist seafile.voorbeeld.com werd gevraagd en niet voorbeeld.com?
Ik snap dat ik in Docker een subdomein aan een (interne) poort kan koppelen, maar het gaat mij dus om te begrijpen hoe de stap hiervoor werkt.

2)
Als ik helemaal geen subdomeinen instel bij mijn domein provider, worden ze dan toch verwerkt wanneer ik naar seafile.voorbeeld.com ga en 'herkent' door Traefik?

Ik las ook dat je met een wildcard kan werken, maar dat is voor die 3 subdomeinen die ik nodig heb wat overkill.

Als je in DNS een CNAME instelt zal de DNS server het IP adres achter de CNAME terug geven. Dus als seafile.voorbeeld.com een CNAME is naar 343f3304b06.sn.mynetname.net en 343f3304b06.sn.mynetname.net verwijst naar 1.1.1.1 dan zal seafile.voorbeeld.com dus ook verwijzen naar 1.1.1.1. Wat Traefik doet staat echter volledig los van je DNS. De browser stuurt bij elke request een Host header mee. En als je naar seafile.voorbeeld.com browst zal de browser dus Host: seafile.voorbeeld.com meesturen. En als je in Traefik dan een Host(`seafile.voorbeeld.com`) http regel aanmaakt match die gewoon. Traefik zal die 343f3304b06.sn.mynetname.net dus helemaal niet zien.

En wildcards is ook "dubbel" in je vraag. Je kunt perfect een *.voorbeeld.com CNAME record aanmaken zonder dat dat enig issue oplevert m.b.t. de Traefik configuratie. Waar jij dan waarschijnlijk ook op doelt is de DNS challenge voor Lets encrypt. Deze ondersteund het genereren van wildcard certificaten, maar is iets moeilijker op te zetten.
Wat echter wel een voordeel is van een wildcard certificaat is dat Lets encrypt je volledige domeinen niet kent en dus ook niet kan publiceren. Zo was er laatst een bug in Lets encrypt waardoor er problemen waren met nieuw gegenereerde certificaten. Lets encrypt heeft toen een lijst gepubliceerd met alle getroffen domeinnamen. Gevolg is dus ook dat bv mijn "security through obscurity" v.w.b. "je moet domeinnaam weten om (bv) Home Assistant te openen" compromised is. Want dat was een van mijn domeinnamen die op die lijst stonden. Als je dus een wildcard certificaat gebruikt met *.voorbeeld.com dan lekt alleen de voorbeeld.com en niet ook seafile.voorbeeld.com.

[Jazco2nd]

RobertMe schreef op dinsdag 14 april 2020 @ 18:10:
[...]

Als je in DNS een CNAME instelt zal de DNS server het IP adres achter de CNAME terug geven. Dus als seafile.voorbeeld.com een CNAME is naar 343f3304b06.sn.mynetname.net en 343f3304b06.sn.mynetname.net verwijst naar 1.1.1.1 dan zal seafile.voorbeeld.com dus ook verwijzen naar 1.1.1.1. Wat Traefik doet staat echter volledig los van je DNS. De browser stuurt bij elke request een Host header mee. En als je naar seafile.voorbeeld.com browst zal de browser dus Host: seafile.voorbeeld.com meesturen. En als je in Traefik dan een Host(`seafile.voorbeeld.com`) http regel aanmaakt match die gewoon. Traefik zal die 343f3304b06.sn.mynetname.net dus helemaal niet zien.

Dit is precies het stukje wat voor mij nog niet duidelijk was, thanks!

Ik vraag me af of Traefik niet overkill is voor mij want je hebt gelijk: het gaat mij alleen om Let's Encrypt, zodat de 3 services via https bereikbaar zijn en via een makkelijk subdomein.

Een setup met Nginx is wellicht wat simpeler en eenvoudiger.

Resteert alleen nog: gaat het werken als ik sub.mijnvoorbeeld.com gebruik? Ik neem aan dat dit eerst 'resolved' moet worden via DNS (naar een IP adres). Dat gaat toch niet werken als ik slechts voor mijnvoorbeeld.com een CNAME heb ingesteld en niet voor sub.minvoorbeeld.com?
Ik meen nu paar keer gelezen te hebben dat het toch niet nodig zou zijn. Maar ik kan me dat niet voorstellen.

[RobertMe]

Jazco2nd schreef op dinsdag 14 april 2020 @ 18:23:
[...]


Dit is precies het stukje wat voor mij nog niet duidelijk was, thanks!

Ik vraag me af of Traefik niet overkill is voor mij want je hebt gelijk: het gaat mij alleen om Let's Encrypt, zodat de 3 services via https bereikbaar zijn en via een makkelijk subdomein.

Een setup met Nginx is wellicht wat simpeler en eenvoudiger.

Bij Nginx moet je juist alles zelf doen? Zelf de proxies definiëren, certbot installeren, Nginx gebruik laten maken van de gegenereerde certificaten, na renewel door certbot Nginx de nieuwe certificaten laten reloaden. Traefik doet dat allemaal automatisch voor je.

Resteert alleen nog: gaat het werken als ik sub.mijnvoorbeeld.com gebruik? Ik neem aan dat dit eerst 'resolved' moet worden via DNS (naar een IP adres). Dat gaat toch niet werken als ik slechts voor mijnvoorbeeld.com een CNAME heb ingesteld en niet voor sub.minvoorbeeld.com?
Ik meen nu paar keer gelezen te hebben dat het toch niet nodig zou zijn. Maar ik kan me dat niet voorstellen.

Daarom moet je een wildcard record aanmaken. Dus * als subdomein.

[Jazco2nd]

RobertMe schreef op dinsdag 14 april 2020 @ 18:31:
[...]

Bij Nginx moet je juist alles zelf doen? Zelf de proxies definiëren, certbot installeren, Nginx gebruik laten maken van de gegenereerde certificaten, na renewel door certbot Nginx de nieuwe certificaten laten reloaden. Traefik doet dat allemaal automatisch voor je.

[...]

Daarom moet je een wildcard record aanmaken. Dus * als subdomein.

Ja je moet wel alles zelf doen maar er zijn eenvoudige voorbeelden voor te vinden. Ik zie net dat hier onderaan een vrij compleet docker-compose.yml voor wordt gegeven. Deze begrijp ik Kwestie van mijn andere 2 services (Firefox Sync en Piwigo) toevoegen met de environment variables toegevoegd en gaan.
Traefikv2 lees ik (ook in dit topic) dat mensen daar best veel tijd aan kwijt zijn om het voor elkaar te krijgen. Een goede guide voor v2 heb ik nog niet gevonden.

Het is mij wel duidelijk dat Nginx de "oude, traditionele" oplossing is en Traefik veel uit handen moet halen, maar er is nog niet veel info over v2 beschikbaar voor beginners.

[RobertMe]

Jazco2nd schreef op dinsdag 14 april 2020 @ 18:48:
Traefikv2 lees ik (ook in dit topic) dat mensen daar best veel tijd aan kwijt zijn om het voor elkaar te krijgen. Een goede guide voor v2 heb ik nog niet gevonden.

Traefik 2 is/was niet perse moeilijk. Alleen, het was voor 99% anders ten opzichte van 1, en het ontbreken van een "redirect alles naar https" gaf ook nogal wat kopzorgen, maar dat is in 2.2 opgelost middels een nieuwe feature.

[JBS]

RobertMe schreef op dinsdag 14 april 2020 @ 18:59:
[...]

Traefik 2 is/was niet perse moeilijk. Alleen, het was voor 99% anders ten opzichte van 1, en het ontbreken van een "redirect alles naar https" gaf ook nogal wat kopzorgen, maar dat is in 2.2 opgelost middels een nieuwe feature.

@lubbertkramer wees me op deze guide waarin het opzetten van v2 verrassend simpel uiteen gezet is. Is dit dan enkel de minimale basis wat jou betreft? Dit lijkt namelijk voldoende voor de combinatie Traefik, docker compose en bestaande subdomeinen met een DNS record naar je eigen IP adres.

Hiermee durf ik de overstap naar 2.x wel aan namelijk

[lubbertkramer]

JBS schreef op dinsdag 14 april 2020 @ 19:34:
[...]
@lubbertkramer wees me op deze guide waarin het opzetten van v2 verrassend simpel uiteen gezet is. Is dit dan enkel de minimale basis wat jou betreft? Dit lijkt namelijk voldoende voor de combinatie Traefik, docker compose en bestaande subdomeinen met een DNS record naar je eigen IP adres.

Hiermee durf ik de overstap naar 2.x wel aan namelijk

Was in 10 minuten gedaan, TraefikV1 even down gebracht en TraefikV2 was gelijk up and working. Labels veranderen per docker (en / of status van watch veranderen). Probleem waar ik nu nog mee zit is dat ik een aantal rules in TraefikV1 heb voor forwards buiten mijn docker omgeving en voor dockers die in host draaien. Nog even kijken hoe ik rules weer werkend kan krijgen onder TraefikV2 en dan kan V1 uit, voor nu eerst even terug op V1

[Matis]

lolgast schreef op maandag 6 april 2020 @ 10:52:
Ten eerste: modje, excuses voor de dubbel post. Ik ben echter van mening dat bovenstaande post als reactie 0,0 met onderstaande te maken heeft. En er is alweer wat tijd overheen gegaan

Versie 2.2.0 is inmiddels al even uit. Voor mij een hele fijne toevoeging, redirection

YAML:

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

Deze functie zat ook in 1.x en was verwijderd bij 2.0. Waardoor je voor élke service moest instellen dat http verkeer geredirect moest worden naar https. Via bovenstaande werkt het weer gewoon op globaal niveau.

Ook is er nu trouwens ondersteuning voor UDP. Daar ga ik nu mee spelen. Hopelijk een mooie manier om pihole te loadbalancen

Ik stoei al sinds de release van V2.2 met deze feature. Ik krijg het op de een of andere manier niet voor elkaar om default alles te redirecten naar 443.

Ik heb de volgende traefik.yml:

code:

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          permanent: true

  websecure:
    address: :443
    http:
      tls:
        certResolver: letsencrypt
        domains:
          - main: "*.tld1.nl"
            sans:
              - tld1.nl
          - main: "*.tld2.nl"
            sans:
              - tld2.nl

Ik kan prima via http en https verbinden met mijn whoami container. Ik zie dan ook de X-Forwarded-Port: op 80 en 443 respectievelijk staan. Zowel middels de browser als via curl.

Echter automatische redirect lijkt niet te werken. Alleen wanneer in whoami.yml expliciet de tls staat genoemd, wordt ik middels een 301 geredirect

code:

http:
  routers:
    whoami-router:
      rule: "Host(`whoami.localhost`, `whoami.tld1.nl`)"
      service: whoami-traefik@docker
      tls:
        certResolver: letsencrypt

Wat doe ik verkeerd, of waar heb ik de documentatie verkeerd geïnterpreteerd

Voor de volledigheid

traefik          | time="2020-04-17T07:33:05Z" level=info msg="Traefik version 2.2.0 built on 2020-03-25T17:32:57Z"

[ Voor 3% gewijzigd door Matis op 17-04-2020 09:35 ]

[lolgast]

Je moet TLS definiëren voor je https router inderdaad. Als je ergers anders al een certresolver hebt voor je domains voldoet dit echter ook

code:

http:
  routers:
    hass:
      entryPoints:
        - https
      service: service-hass
      rule: Host("hass.domeinnaam.nl")
      tls: {}

[Matis]

lolgast schreef op vrijdag 17 april 2020 @ 09:35:
Je moet TLS definiëren voor je https router inderdaad. Als je ergers anders al een certresolver hebt voor je domains voldoet dit echter ook

code:

http:
  routers:
    hass:
      entryPoints:
        - https
      service: service-hass
      rule: Host("hass.domeinnaam.nl")
      tls: {}

Bedankt voor je reactie. Uit de documentatie kon ik niet opmaken dat het toevoegen van een tls-entry in de dynamic config ook noodzakelijk was om "automatisch" te redirecten naar https.

Ik heb inderdaad al een (standaard) certresolver gedefinieerd. Dus ik kan toe met de {}.

[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.

[lolgast]

@Matis Ik kan een heel verhaal typen, maar heb je dit al gelezen?

https://docs.traefik.io/providers/docker/#port-detection

[Matis]

lolgast schreef op woensdag 22 april 2020 @ 13:10:
@Matis Ik kan een heel verhaal typen, maar heb je dit al gelezen?

https://docs.traefik.io/providers/docker/#port-detection

Ja, dat heb ik. Zodoende wist ik ook dat Traefik automatisch de eerste (laagste) poort selecteert die exposed wordt vanuit de container.

Ik ben ook aan het stoeien geweest om een label in het format

- traefik.http.services.my-service.loadbalancer.server.port=80

te fabriceren voor de web-gitlab@docker Service.

Echter weet ik niet wat ik in de plaats van my-service uit het voorbeeld moet typen zodat Traefik snapt dat ik alleen de poort die automatisch geselecteerd wordt in de web-gitlab@docker Service wil overschrijven.

Mijn GitLab docker-compose file ziet er zo uit

code:

version: '3'
services:

    web:
      image: gitlab/gitlab-ce:12.9.2-ce.0
      restart: always
      container_name: gitlab
      environment:
        GITLAB_OMNIBUS_CONFIG: |
          external_url 'https://gitlab.internal.nl'
          # Add any other gitlab.rb configuration here, each on its own line
      volumes:
        - ./config:/etc/gitlab
        - ./logs:/var/log/gitlab
        - ./data:/var/opt/gitlab
# Daar wil ik dus het volgende aan toevoegen
      labels:
        - traefik.http.services.my-service.loadbalancer.server.port=80

Maar als ik dan de GitLab container en de Traefik container herstart, staat er nog steeds doodleuk http://172.21.0.2:22 als Server URL.

[lxz]

oeps, ik had niet verder terug gelezen. Negeer onderstaande



dat 172-adres bij Server URL wordt door docker intern gebruikt. Daar zul je (bijna) nooit een adres uit een andere range terugvinden.

Ik zou beginnen met het toevoegen van zoiets aan je compose-file, om de werking een beetje te snappen:
[code=yaml]
ports:
- 8880:80
[/code]

dan kun je vervolgens de port 80 die in de container gebruikt wordt, benaderen door naar bijv. 192.168.1.2:8880 (of welk ander intern ip-adres je dan ook gebruikt) te gaan.

Om gebruik te maken van traefik zul je vervolgens nog wat meer labels moeten zetten, bijvoorbeeld zoiets:
[code]
labels:
- traefik.enable=true
- traefik.http.routers.gitlab.rule=Host(`gitlab.domein.bla`)
- traefik.http.routers.gitlab.service=gitlab
- traefik.http.routers.gitlab.entrypoints=websecure
- traefik.http.services.gitlab.loadbalancer.server.port=80
[/code]

[ Voor 11% gewijzigd door lxz op 22-04-2020 13:51 ]

[lolgast]

@Matis Ah wacht even. Je wilt labels gebruiken icm met een los bestand? Waarom? Maar laat ik een oplossing voorstellen.

Je kunt je Gitlab container toevoegen aan het netwerk van je Traefik container. Je zult dus moeten opzoeken hoe je dat netwerk heet. Zal wel iets van 'traefik_bridge' zijn.

Als ze in hetzelfde netwerk zitten kun je ze namelijk op dnsnaam laten verbinden. Dan zou je dynamische configuratie er zo uit kunnen zien

YAML:

http:
  routers:
    test-https:
      rule: Host("gitlab.domein.bla")
      entryPoints:
        - https
      service: web-gitlab
      tls: {}

  services:
    web-gitlab:
      loadBalancer:
        servers:
          - url: http://gitlab

Kun je de docker labels over de schutting gooien. En als je geen dynamische configuratie wilt maar labels, zie dan de opmerking boven mij over labels. Je mist er nogal wat

[Matis]

lolgast schreef op woensdag 22 april 2020 @ 13:52:
@Matis Ah wacht even. Je wilt labels gebruiken icm met een los bestand? Waarom? Maar laat ik een oplossing voorstellen.

Dat is inderdaad wat ik wil. Sorry als dat op voorhand niet helemaal duidelijk was. De reden is eigenlijk dat ik in mijn docker-compose.yml bestanden geen traefik labels wil opnemen, omdat ik deze zo generiek mogelijk wil opzetten. Ik wil deze, als het ware, onafhankelijk maken van een (eventuele) reverse proxy.

Je kunt je Gitlab container toevoegen aan het netwerk van je Traefik container. Je zult dus moeten opzoeken hoe je dat netwerk heet. Zal wel iets van 'traefik_bridge' zijn.

Als ze in hetzelfde netwerk zitten kun je ze namelijk op dnsnaam laten verbinden. Dan zou je dynamische configuratie er zo uit kunnen zien

YAML:

http:
  routers:
    test-https:
      rule: Host("gitlab.domein.bla")
      entryPoints:
        - https
      service: web-gitlab
      tls: {}

  services:
    web-gitlab:
      loadBalancer:
        servers:
          - url: http://gitlab

Kun je de docker labels over de schutting gooien. En als je geen dynamische configuratie wilt maar labels, zie dan de opmerking boven mij over labels. Je mist er nogal wat

Ik wil, als het even kan, alles binnen de dynamische configuratie van traefik houden. Zodat ik niet mijn originele docker-compose.yml bestanden van allerhande (web)services moet aanpassen als ik besluit naar een andere reverse-proxy of stand-alone oplossing te gaan. Hetzelfde als traefik morgen met versie 3 komt, welke een compleet andere interface / labels heeft. Dan hoef ik niet al de docker-compose files af, maar kan ik de configuratie bij traefik houden zodat versie en bijbehorende configuratie altijd blijven werken.

Ik heb zelf ooit een python-service geschreven welke automatisch alle docker-containers op basis van hun naam en IP-adres in de hosts file van de host machine zetten. Mogelijk kan ik op die manier bij de gitlab container komen op basis van zijn local domeinnaam.

Dat ga ik eerst proberen

[ Voor 7% gewijzigd door Matis op 22-04-2020 14:54 ]

[lolgast]

@Matis Waarom een script schrijven als die functie in Docker zit?!

Nogmaals. Je moet zorgen dat je gitlab in hetzelfde dockernetwerk komt als je traefik container. Dan is hij op containernaam benaderbaar voor traefik en kun je dus de naam toevoegen aan je configuratie. Zoals ik heb voorgedaan

[Matis]

lolgast schreef op woensdag 22 april 2020 @ 14:57:
@Matis Waarom een script schrijven als die functie in Docker zit?!

Ik heb die service al draaien op mijn machine, maar ik denk dat we langs elkaar heen praten. Laat ik het hieronder uitleggen.

Nogmaals. Je moet zorgen dat je gitlab in hetzelfde dockernetwerk komt als je traefik container. Dan is hij op containernaam benaderbaar voor traefik en kun je dus de naam toevoegen aan je configuratie. Zoals ik heb voorgedaan

Mijn traefik container draait met network_mode: host Er is echter wel een traefik_default netwerk:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
508b6cbce4a2        bridge              bridge              local
94d7fc85f54d        gitlab_default      bridge              local
feb2ce70def6        host                host                local
fa0d899bad1f        none                null                local
ba5f46ed404b        traefik_default     bridge              local

Zoals eerder aangegeven wil ik proberen de configuratie van traefik zoveel mogelijk gescheiden te houden van de configuratie van de andere containers en vice versa. Daarom streef ik er naar geen treafik-specifieke configuratie in de docker-compose van GitLab op te nemen.

Laat me nog maar even in mijn eigen sop gaarkoken, waarschijnlijk kom ik aan het einde van de dag daar met hangende pootjes van terug