0

I have two apps running on marathon.
I want web.myblog.com to route to App 1, and web.myblog.com/app to route to app2.

With the below config, all traffic is going to app 1.

App 1  
traefik.frontend.rule=HostRegexp:{subdomain:[a-z]+}.myblog.com

App 2  
traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/app

I tried using negative matching to exclude /app routing for app 1, but it is my understanding that negative lookahead isn't fully supported in golang and by result also not in traefik.

I also tried specifying a path prefix for app 1 like so traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/ but this has no effect.

When I modify the rule for App 1 to point to Host:test.myblog.com all traffic goes to app 2 correctly, From that I conclude that the routing config to App 2 is correct, it is just being ignored because App 1 supersedes it since it also satisfies the route.

This issue is discussing this exact use case:
https://github.com/containous/traefik/issues/419#issuecomment-223843103

But it looks like a config without pathPrefix takes precedence over a config with pathPrefix, maybe this type of config is simply not supported on the marathon backend ?

It's not clear to me from this documentation:
https://github.com/fclaeys/traefik/blob/master/docs/basics.md.

Looking for an answer that will help me understand whether this use case is supported at all on the marathon backend, or an example working config for it.

Using Traefik v1.5.1

Timo Reimann
  • 9,359
  • 2
  • 28
  • 25
Willem D'Haeseleer
  • 19,661
  • 9
  • 66
  • 99
  • It surprises me that "traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/" didn't work for you. As you wrote in your own answer, Traefik does longest path matching. Thus, any request with an `/app` prefix should reach app 2 while any request missing that prefix should reach app 1. If that doesn't work, there might be a bug (or I'm remembering the behavior incorrectly). – Timo Reimann Apr 01 '18 at 08:44
  • I just edited your post as it used the `app` host in the initial paragraph but `myblog` later. Hope my fix was correct, if not let me know. – Timo Reimann Apr 01 '18 at 08:46
  • It's the actual syntactic lenth of the rule. Rule 1 uses a regex for part of the rule so it's longer in total. – Willem D'Haeseleer Apr 01 '18 at 17:57
  • I was referring to the updated rule you mentioned in the paragraph starting with "I also tried specifying a path prefix for app 1 like so [...]". With that, the difference between the rules for app 1 and app 2 seems to boil down to the path value. – Timo Reimann Apr 01 '18 at 21:05

2 Answers2

0

If multiple rules match traefic will use the length of the rule to determine which rule is most specific instead of the actual specificity. You can override this artificial priority by using

traefik.frontend.priority=1000

More info: https://github.com/containous/traefik/issues/1663

Willem D'Haeseleer
  • 19,661
  • 9
  • 66
  • 99
0

If I adjust the rule for app 1 to

traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/

per one of your attempts, and stick with

traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/app

on app 2, the routing behavior seems to be as expected: Requests with the web.myblog.com host and an /app path go to app 2 exclusively and deterministically (because Traefik employs longest-path matching). If I modify the request to use the root path / (or any path other than /app as they will all hold the matching root path prefix), traffic is forwarded to app 1.

I tested against Marathon 1.3.10.

Timo Reimann
  • 9,359
  • 2
  • 28
  • 25
  • you aren't using a regex for the first route. The regex caused the rule to be longer and takes precedence as a result. Your second rule is 3 characters longer and that's why it's working, not related to the PathPrefix. – Willem D'Haeseleer Apr 02 '18 at 23:55
  • That's right. I was responding to this statement from your SO question (**emphasis** by me): _I also tried specifying a path prefix for app 1 like so traefik.frontend.rule=Host:web.myblog.com;PathPrefix:/ **but this has no effect**_. I was trying to demonstrate that it did make a difference for me compared to the original regex/no-regex rule mix. – Timo Reimann Apr 03 '18 at 08:37