Future of the traefik-pages

[Adito5393]

Hey Jack,

Congrats on the new website! I just notice your infrastructure commits https://github.com/RealOrangeOne/infrastructure/commit/73f165c521d04b84cb187b7594b2e3025dc71bef & https://github.com/RealOrangeOne/infrastructure/commit/4c8d5ffe44f3b5feb98c33aeb96911cae5990805. Does this mean you are not actively maintaining this project? Do you think it does not worth the effort to support Traefik v2.9?

[RealOrangeOne]

I won't be using the project as actively, but I'm still planning on supporting any other contributions.

I would really like to add support for 2.9, I think it would be really useful. I don't know how much effort that would take, but something has clearly changed. I'd also be interested in seeing how viable it is to make this just act as a traefik source, rather than serving the files itself - instead deferring that to something like nginx.

[Adito5393]

That's a really great idea to bridge the Traefik API to some other file server engine.

I have been experimenting with CaddyServer & go language (in general). Maybe I will give it a go at creating a caddy module for this goal.

Would you be willing to give some feedback on the design phase (verifying my understanding of the Traefik via the HTTP provider), before I start coding?

Feel free to close the issue if you want.

[RealOrangeOne]

A caddy module which Traefik can talk to sounds useful, but is definitely completely separate to traefik-pages.

[stefanvanherwijnen]

I came across https://github.com/lucaslorentz/caddy-docker-proxy today. If you are comfortable with dropping Traefik entirely, give it a try. It replaces both Traefik and TraefikPages and its easier to configure. I haven't used Caddy before so it took a while to figure things out, but this docker-compose.yaml should get you started:

version: "3.7"
services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:ci-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    environment:
      - CADDY_INGRESS_NETWORKS=web
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./sites:/srv
      - ./data:/data
    labels:
      caddy.email: ${EMAIL}
      # Enable for local development
      # caddy.local_certs:
      # Statically served webstites
      caddy_1: www.somevuewebsite.com
      caddy_1.handle.root: "* /srv/www.somevuewebsite.com"
      caddy_1.handle.file_server:
      caddy_1.handle.try_files: "{path}.html {path} /index.html"
      caddy_2: anotherexample.com
      caddy_2.file_server.root: /srv/anotherexample.com
    networks:
      - web

  whoami:
    image: traefik/whoami
    labels:
      caddy: whoami.com
      caddy.reverse_proxy: "{{upstreams 80}}"
    networks:
      - web

networks:
  web:
    external: true

.env

EMAIL=email@example.com

I just migrated my statically hosted websites and as a bonus, this also fixes https://github.com/RealOrangeOne/traefik-pages/issues/6.

[Adito5393]

Thanks @stefanvanherwijnen for offering an alternative. However, I can't see how this caddy module is able to scan and automatically serve new subdomain websites as traefik-pages does without requiring changes to the docker labels whenever I want to deploy a new website. Is this scenario supported?

I want to be able to deploy a new website simply by transferring the HTML content to a new directory on the server. My use case is deploying versions of a docs website for PR review.

[stefanvanherwijnen]

Unfortunately that isn't supported but should be possible with a caddy module which scans a directory and updates the Caddyfile accordingly. But at least you can easily host your static site behind a reverse proxy (with just caddy instead of traefik + caddy).

[RealOrangeOne]

The file serving component of traefik-pages was always the one I was least happy with, mostly because there's so much scope for customization. Handing that off to some other process would be great, especially if it let projects define some customizations (eg #6 ).

Outsourcing that to caddy through its load API could solve that problem. Perhaps even with dynamic config to avoid an extra daemon entirely.

Anyway, quit nerd sniping, those are much larger project ideas than just traefik-pages.