How to register 2 services (from 2 providers) in the same load balancer?

Traefik Traefik v2
,
1

I'm using the Docker provider to discover an HTTP service in a container. I'm also running the same container on my Docker host and want to include it in the same load balancer.

To include the local Docker host however, I had to use the File provider.

Thus, I end up with 2 routers that both declare the same rules to be activated. One router will send to web@file and the other to web@docker. However, it only picks one and if the target in that router is down, the request is failed.

I don't see any way to include both containers under the same load balancer. How is this supposed to be solved?

# traefik.yml
http:
    routers:
        web:
            rule: Host(`web.localhost`)
            tls: true
            service: web
    services:
        web:
            loadBalancer:
                healthCheck:
                    path: /api/ping
                servers:
                    - url: "http://host.docker.internal:8081"
    
# docker-compose.yml
labels:
    traefik.http.routers.web.rule: Host(`web.localhost`)
    traefik.http.routers.web.service: web
    traefik.http.routers.web.tls: "true"
    traefik.http.services.web.loadBalancer.server.port: 80
    traefik.http.services.web.loadBalancer.healthCheck.path: /api/ping
2

Why are you addressing them the same? Is there any way you can differentiate requests between the two, a specific header ,method , path or query ?

3

I'm not sure to fully understand but if you want loadbalancing I believe you don't need any label on your docker container and you just need to add a second server in your toml file. After all, you need only one router and one service with 2 servers in the loadbalancing.

4

If you had multiple servers for the file provider additional -url lines would add them and load balance.
If you wanted to add more services to the docker provider then scaling that service would add more and likewise load balance.

What you are doing is configuring two different routers with the exact same rule and expecting what? to happen.

5

Sorry for replying so late :frowning:

The reason why I set it up like this is, one of the services is provided by Docker and must be discovered through Docker labels, so the correct IP+Port of the container is used. Otherwise, I have to reconfigure this manually every time I start up my Docker Compose setup.

The other service is the same application, but running on my host, in a debugger. I can access this service through host.docker.internal statically from my compose setup.

I want to be able to stop the container and seemlessly take over the requests in the instance that I'm debugging.

I assumed, if you specify the same routing options for two routers, they essentially become the same router and load would be balanced between all services that match the routing rules. I can see that that isn't the case.

6

Hi @oliversalzburg

I have a couple of ideas, but I want to try them out before pitching them.

1 Like
7

I hate to bother, but if you could share those ideas, I'd really appreciate it. My attempts weren't successful at all.

8

@cakiwi I'm gonna try my luck one more time with a ping, then I'll just assume it's not going to work

9

Hi @oliversalzburg

Really sorry about that.

What you have should work if you add a priority to the router in the file provider that is lower than your docker one. If you set it to 1 it would be considered after ever other rule.

I went into a roue of looking into weighted round robin, but that falls apart quickly when the the container is stopped as the service disappears.

1 Like
10

Thanks a lot. :slight_smile: I actually hadn't looked at priorities as an option. I also wasn't able to immediately resolve my issue using them, as my complete setup is more complicated and I'm now seeing (understandable) conflicts with other routers.

I will have to work those out before I can ultimately assess if it works as expected.

11

It works flawlessly right now. Thanks a lot.

I want to add that part of my problems were related to two routers unintenionally sharing paths. The inability to negate rules for a router made fixing this more complicated than anticipated.

12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.