Traefik configuration via compose labels is bad

Traefik is great. It is an awesome application proxy, but there are some parts that are not great. Configuration is one of them. Obviously there are different tastes for all kinds of stuff, but sometimes it seems that some tastes are just objectively bad. Let's get started: I don't understand why anybody thought it would be a good idea, to make Traefik configurable via docker compose labels. Why? I understand the convenience of having the docker compose config colocated with Traefik config, but convenience has limits and this should have been a limit. If you ever encounter a problem online with Traefik for which you need to grasp some context about the problem in advance you are met with the following problem: Some people use docker compose labels, some YAML, some TOML. There is also some other people with Kubernetes, but you get the idea. Who thought this would be a good idea? Why would you need so many different language to describe your infrastructure?

I think it should have been one language. YAML? I am not the biggest fan, but I would be okay with it. I use it for all my Traefik config, and I am somewhat happy with it. Clamping Traefik config into compose-labels feels like Regex being used for mission-critical tasks. Regex is a huge universe for itself with a lot of context to consider. Bugs are more easily overlooked if they are baked into another language's source code, which is why they should be avoided. Even in a tightly guarded context, for example, when validating an email, the specifications of an email-address are pretty clear after all, there are STILL sites, which have bad validation regexes and over-block users.

Here is a list of regex related outages:

If regexes are continued to be used in the way they are, in my opinion, by too many people, these outages will continue. The engineers that caused the outages maybe made a mistake, maybe it wasn't caught by QA, maybe there were some external factors that drove them to be not as careful as they have been, but that's how software engineering works. Humans make mistakes, and engineers are human, after all. If the tools you work with only work perfect in a perfect world, they shouldn't be used. There will always be something that is not optimal, after all. So we shouldn't make our lives harder than they need to be: Avoid regex at all costs. Future you and future me will thank you. But: If you are using regex to transform data from format A to B while developing, let's say a list of cities or something, and you let's say want to convert it to valid JSON: absolutely use Regex for that if you want to. But don't introduce a regex into your codebase if you can avoid it.

But let's get back to the topic. Take a look of at traefik configuration via labels:

YAML

labels:
  - "traefik.http.routers.router1.service=service1"
  - "traefik.http.routers.router1.middlewares=secured"
  - "traefik.http.routers.router1.rule=Host(`mydomain`)"
  - "traefik.http.middlewares.secured.chain.middlewares=https-only,known-ips,auth-users"
  - "traefik.http.middlewares.auth-users.basicauth.users=test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/"
  - "traefik.http.middlewares.https-only.redirectscheme.scheme=https"
  - "traefik.http.middlewares.known-ips.ipallowlist.sourceRange=192.168.1.7,127.0.0.1/32"
  - "traefik.http.services.service1.loadbalancer.server.port=80"

Parsing this configuration is harder than it needs to be. Now look at this configuration:

YAML

# ...
http:
  routers:
    router1:
      service: service1
      middlewares:
        - secured
      rule: "Host(`mydomain`)"

  middlewares:
    secured:
      chain:
        middlewares:
          - https-only
          - known-ips
          - auth-users

    auth-users:
      basicAuth:
        users:
          - "test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/"

    https-only:
      redirectScheme:
        scheme: https

    known-ips:
      ipAllowList:
        sourceRange:
          - "192.168.1.7"
          - "127.0.0.1/32"

  services:
    service1:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:80"

For me this is a very clear case: The second example is way clearer and easier to read.